W-14922493 : Salesforce setup guide updates

accelerators-home/modules/ROOT/nav.adoc

@@ -9,6 +9,7 @@
 * xref:shared-assets.adoc[Shared Assets]
 * xref:common-services.adoc[Common Services]
 * xref:cim-overview.adoc[Cloud Information Model]
+* xref:ubp-considerations.adoc[Anypoint pricing model considerations]
 ** xref:cim-subject-areas.adoc[CIM Subject Areas]
 *** xref:cim-finance.adoc[Finance]
 *** xref:cim-fulfill.adoc[Fulfill]

accelerators-home/modules/ROOT/pages/ubp-considerations.adoc

@@ -0,0 +1,94 @@
+# Considerations for Usage-Based Pricing and Accelerator Assets
+
+The solutions developed for use cases supported by MuleSoft Accelerators were designed following the https://blogs.mulesoft.com/learn-apis/api-led-connectivity/[API-led connectivity] approach, which promotes a clean separation of application, process, and system integration layers while enabling a high level of reusability - particularly with System APIs. While this powerful approach remains valid today, and is highly recommended for organizations of all sizes to enable future growth while minimizing maintenance costs, there are some considerations that need to be taken into account for customers who have subscribed to the new usage pricing and packaging model.
+
+## The new pricing model
+
+As it pertains to the accelerators, applications deployed to CloudHub 1.0, CloudHub 2.0, or Anypoint Runtime Fabric will no longer be measured in terms of vCores when it comes to pricing. Instead, runtime pricing will be based on a combination of the following metrics:
+
+1. _Mule flow_: A flow within a deployed and running Mule app that contains a Mule event source or APIKit route handler.
+2. _Mule message_: The data associated with the Mule event as it passes through one or more Mule flows in an application.
+3. _Data throughput_: All of the network I/O bytes produced by the Mule Runtime server hosting a Mule application.
+
+### Individual metrics
+
+The following sections provide a brief description of each metric and how it contributes towards monthly subscription costs. For more complete details on these metrics, including those used for other products, refer to the https://docs.mulesoft.com/general/pricing-metrics[Usage and Pricing Metrics] guide.
+
+#### Mule flows
+
+A _Mule flow_ is a sequence of message processors grouped within a `<flow>` element in a Mule flow file. Mule flows typically consist of an event source, such as an Anypoint MQ subscriber or HTTP listener, and processors that act upon the _Mule message_ produced by that event source. More complex flows are typically broken up into sub-flows, which also include a sequence of processors grouped within a `<sub-flow>` element but cannot include an event source. When sub-flows are referenced from top-level flows, the sub-flow contents are therefore included in-line to create a single monolithic flow at runtime. All APIkit route handlers - whether they are scaffolded from an API specification or explicitly mapped by hand - are considered top-level flows for pricing purposes.
+
+#### Mule messages
+
+A _Mule message_ is the data (payload and attributes) associated with a Mule event, which passes through one or more Mule flows in an application. This includes event sources such as incoming requests handled by an HTTP Listener (including those routed by APIkit), messages received from Anypoint MQ or VM Queues, file changed events, etc. All event messages processed count towards usage for pricing purposes. Additional messages or payloads created during processing do not count as event messages and therefore do not affect usage amounts.
+
+#### Data throughput
+
+Simply put, data throughput includes all network traffic that flows in or out of the instance or container hosting the Mule application. This includes business processes, such as publishing a message to MQ or making HTTP requests to downstream APIs, as well as health checks, external log forwarding, monitoring metrics transfer, etc. All data transfer in or out is taken into consideration for pricing purposes.
+
+### Metrics and pricing summary
+
+To summarize how the above metrics contribute towards usage costs in the new model, consider the following:
+
+1. The more endpoints (combination of resources and HTTP methods) an API specification contains, the more flows will be generated by the scaffolder. Each generated flow counts against the subscription allocation.
+2. Sub-flows do not count towards usage costs as they do not contain event sources (flows without event sources also do not count but sub-flows are lighter-weight).
+3. Health check requests (implemented in Mule applications) count towards both flow and message allocations.
+4. Each "hop" (API to API request) included in the execution of a request counts towards both message and data throughput allocations.
+5. Excessive use of logging processors (especially JSONLogger) and application-specific metrics collection count towards the data throughput allocation.
+
+## Accelerator assets and the new pricing model
+
+A consistent driving factor behind the design and implementation of use cases supported by the MuleSoft Accelerators has always been to keep the assets and corresponding solutions a simple as possible while still providing a solid, functional, and maintainable architecture for customers to build upon. We have achieved this through a few key principles when it comes to solution design:
+
+. Follow the API-led connectivity approach but create APIs only where necessary to support clean integration with external applications and systems.
+. Keep exception handling clean and simple, allowing for straightforward extension and customization. 
+. Avoid the use of heavy logging, monitoring, or exception handling frameworks.
+. Leverage a reusable canonical data model within the business process layer to simplify communication between layers.
+. Use messaging only where it was deemed necessary to support high-volume deployments.
+. Use inlined sub-flows instead top-level flows wherever possible.
+
+That said, the solutions were originally designed around a pricing model based on vCores. Since the intention of the accelerators has always been to provide customers with a starting point for implementing their own solutions, there are some aspects of the solutions that are not necessarily cost-effective when it comes to the new pricing and packaging model. These are discussed in more detail below.
+
+## Reducing runtime costs with accelerator assets
+
+As mentioned above, the assets developed for the MuleSoft Accelerators were intended to be flexible and extensible, supporting not just the use cases we have defined but other use cases needed by customers to support their business. For customers on the new pricing and packaging model, or who do not otherwise require such flexibility, there are a few ways that costs can be reduced without significantly sacrificing functionality.
+
+### Reducing the number Mule flows
+
+Given the signficance of Mule flows in the new model, reducing the number of flows can have a dramatic effect on cost reduction overall. The following are some specific steps you can take to reduce the number of flows in accelerator applications.
+
+#### Remove unused APIkit handlers
+
+Some of our API specifications - particularly System APIs - have been deliberately designed to support a wider range of use cases than what was strictly required to implement our own. This means that APIkit would have scaffolded flows you may not require for your own use cases. These can simply be removed from the main router flow file (usually the one named `*-api.xml`). There is no need to go through the trouble of changing the API specification and rescaffolding, since you would still have to edit the file manually to remove them anyway.
+
+#### Remove API health checks
+
+The `get:/ping` endpoint was provided for customers who may not have API Manager included in their subscription but still want a way to periodically evaluate the health status of deployed APIs. If not required, the handlers for these endpoints may be removed from the main APIkit flow file. Message and throughput costs may also be reduced by removing the checks for downstream dependencies (see below).
+
+#### Generalize event sources
+
+While we do not condone creating monolithic flows that listen to generic events, there is some cost-reduction that can be gained by combining finer-grained event sources into more granular events. For example, while we already created more general events for publishing Party (Individual, Household, etc.) and Party Role (Customer, Supplier, etc.) updates, the two update queues could be combined into one - bound to both Exchanges - and consumed by a single handler. A similar approach could be taken for VMQueue subscribers, SFTP listeners, etc.
+
+#### Reducing the number of APIs overall
+
+* Where back-end systems have a modern, well-designed API (e.g., Salesforce), and there is no need to perform extensive mapping between a canonical model and the back-end model, consider making calls directly to the system from the Process layer instead of through a System API only; this can also help reduce the number of message flows.
+* When providing similar functionality to external applications via Experience APIs, look for opportunities to provide a single Experience API to support multiple channels, rather than one Experience API per channel. For example, multiple Salesforce Experience APIs could be combined into one or two APIs, reducing the number of handlers overall.
+
+### Reducing the number of Mule messages
+
+Mule messages are produced every time an event is received from an event source - including incoming API requests. One way to reduce the number of messages consumed is to reduce the number of API to API calls (e.g., Experience to Process, or Process to System) made during the course of handling a top level event. While the accelerator solution designs already avoid making unnecessary hops (e.g., Experience directly to System when no intermediate transformation, validation, or aggregation is required), there are a few ways this can be optimized further:
+
+* As described above, consider making calls to back-end systems directly from Process APIs where a well-defined interface exists.
+* For health checks, remove the flows that also check the health of downstream systems when the `checkDependencies` flag is set.
+* Replace the use of VMQueue or Anypoint MQ messaging if asynchronous processing is not truly required. These patterns were often provided with the expectation that customers may want to use them in high-volume deployments, which may not be the case for some customers.
+
+### Reducing data throughput
+
+As mentioned above, accelerator solutions already avoid unnecessary network traffic by reducing the number of hops and by not making use of any external logging, monitoring, or exception handling frameworks. A number of the cost reduction steps described above also apply to reducing data throughput. For your own deployments, be sure to take data throughput into account when considering the addition of any custom frameworks for logging, exception handling, etc.
+
+## See Also
+_
+https://docs.mulesoft.com/general/pricing[Anypoint Platform Pricing]
+https://docs.mulesoft.com/general/pricing-metrics[Usage and Pricing Metrics]
+https://docs.mulesoft.com/general/usage-reports[Viewing Usage Reports]
+https://blogs.mulesoft.com/learn-apis/api-led-connectivity/[API-led connectivity]

retail/3.1/modules/ROOT/pages/sfdc-customization-guide.adoc

@@ -250,7 +250,7 @@ Instead of adjusting permissions for each field as you go, if you are only makin
 === Additional Notes
 
 * The *Customer Status* picklist values are *Prospect*, *Onboarding*, *Active*, *Inactive*, *Closed*, *Deceased*, *Delinquent*, and *Dormant*.
-* The *External Id Type* picklist values are *SALESFORCE_B2C*, *SALESFORCE_CORE*, *PIM*, *OFBIZ*, *SAP_4HANA*, *MDM*, *SAP_ECC*, *SALESFORCE_MARKETING*, and *ORACLE_EBS*.
+* The *External Id Type* picklist values are *SALESFORCE_B2C*, *SALESFORCE_CORE*, *PIM*, *OFBIZ*, *SAP_4HANA*, *MDM*, *SAP_ECC*, *SALESFORCE_MARKETING*, *POS*, *SALESFORCE_DC*, *SALESFORCE_LM*, and *ORACLE_EBS*.
 * The *Object Type* picklist values are *BillingAddress*, *Customer*, *Email*, *Fax*, *Household*, *Individual*, *MailingAddress*, *MobilePhone*, *Organization*, *Phone*, *Product*, *SalesOrder*, and *ShippingAddress*.
 * The *Status* picklist values are *VALID*, *INVALID*.
 * All `Global_*_Id__c` fields should be visible in layouts (as described above) but made *read-only* to avoid issues with data synchronization. 
@@ -435,4 +435,4 @@ Follow these steps to create the Apex Triggers:
 == See Also 
 
 * xref:prerequisites.adoc[Prerequisites]
-* xref:index.adoc[MuleSoft Accelerator for Retail]
+* xref:index.adoc[MuleSoft Accelerator for Retail]