There are multiple types of modeling schemes you can use when configuring cartridges for orders that use orchestration. You can use:
A top-down modeling method (a product-oriented approach) where you configure services using one or more fulfillment patterns as the basis for the configuration.
A bottom-up modeling method (a topology-centric approach), where you first model services in Design Studio (with no associated fulfillment patterns). Use this method when products and their associated attributes are unknown early in the configuration cycle. You can reconcile the services with the fulfillment patterns (mapped from conceptual model products or OSM product specifications from the master data source) as they become available.
The procedure below outlines the basic best practice steps to configure an OSM cartridge in Design Studio.
To create a cartridge for orders that use orchestration
Create an OSM cartridge project.
The OSM cartridge project is your working area for the OSM configuration. When you create a new cartridge project, Design Studio displays the new cartridge project in the Studio Projects view of the Design perspective. In addition to the newly-generated entity, the project contains entities for an order and for the data schema (which becomes part of the Design Studio Data Dictionary). See "Working with OSM Cartridge Projects" for more information.
Model the incoming orders.
To recognize the source of in-bound orders and interpret the order's structure, OSM uses an ordered list of recognition rules. Additionally, you must determine how to select order items on the incoming order, what data you need from the order item to fulfill the order item, and what control data from the order item you need to help create the orchestration plan.
To model incoming orders
Define recognition rules.
Recognition rules help determine the order type and source of the incoming order and what validations and transformations, if any, are required. When you define recognition rules, you configure XQuery expressions for the recognition and validation rules, specify the data structure of the incoming customer order message, and map the incoming order to a specific order type. See "Working with Recognition Rules" for more information.
Define order item specifications.
For each type of order that you receive from your order capture systems, you must configure one order item specification to identify the properties that help determine how to fulfill those items. See "Working with Order Items" for more information.
Model the decomposition.
To ensure that OSM can properly direct order items on incoming orders to the appropriate downstream processes, you configure multiple order components and rules to enable OSM to sort the order items at increasingly greater levels of detail. This process is called decomposition.
To model the decomposition of an order
Define the order components.
Order components represent interactions with local fulfillment systems, and contain all of the data needed by the downstream system subprocesses to complete the fulfillment task. Defining order components is an iterative process. At this step, you identify (at minimum) the top level order components (those that represent your fulfillment functions) that you'll reference when you create orchestration stages. If (at this point in the design time) information about your systems is in place, you can also create the order components that represent systems.
See "Working with Order Components" for more information.
Define the orchestration process.
Orchestration processes are dynamically generated at run time, based on process data that you configure in Design Studio. Orchestration processes enable OSM to fulfill incoming customer orders using fulfillment systems required to complete the order. See "Working with Orchestration Processes" for more information.
Define the stages.
Orchestration stages are the logical steps OSM must take to ensure that the order items on an incoming order are sent to the proper systems in a sequence that honors any dependencies among the order items. See "Working with Orchestration Stages" for more information.
Define the orchestration sequence.
Orchestration sequences describe how OSM organizes the order items on incoming orders into hierarchies to be sent to external systems. Orchestration sequences include information about how to locate the order items on an incoming order and the set of orchestration stages through which the sequence transitions. See "Working with Orchestration Sequences" for more information.
Define decomposition rules.
Decomposition rules specify the conditions in which OSM decomposes one or more order components into another order component. OSM evaluates every order item in the source order component against the conditions that you define for the decomposition rule. If an order item passes all specified conditions, OSM includes the order item in the target order component. See "Working with Decomposition Rules" for more information.
Define which order components are executable.
Executable order components contain all of the order items necessary to execute an instance of the subprocess task associated with the order component. See "Order Component Specification Editor Details Tab" for more information about associating a process with an order component and specifying which order components are executable.
Define the fulfillment patterns.
You use fulfillment patterns to describe the structure of a group of related products in your product catalog. The structure describes the characteristics that define the data collected during order capture. See "Working with Fulfillment Patterns" for more information.
When configuring fulfillment patterns, you:
Define the order component transitions.
Transitions specify the logical sequence between order components within a single fulfillment pattern, or between order components associated with different fulfillment patterns. Transitions describe a decomposition from a source order component to a target order component. See "Fulfillment Pattern Editor Orchestration Plan Tab" for more information.
Define order item dependencies among order components.
When OSM receives a customer order from an external system, it determines all dependencies that exist among the order items on the order. You must define the order item dependencies among the order components in one fulfillment pattern and among those in multiple fulfillment patterns. See "Working with Order Items" for more information about creating order item dependencies. See "Fulfillment Pattern Editor Orchestration Plan Tab" for information about keying the dependency on order item properties other than the order item name.
You can also define dependencies between order items within a set of order components that are not based on fulfillment patterns. See "Working with Orchestration Dependencies" for more information.
Create (or import) products and map to fulfillment patterns.
Conceptual model products and OSM product specifications define a type or class of products (for example, DSL). New products should be created in the conceptual model and mapped to conceptual model fulfillment patterns. These conceptual model fulfillment patterns are then realized into OSM fulfillment patterns.
Products and product specifications include dynamic attributes (characteristics) for a specific type of product. In Design Studio, you can connect to a web service to import conceptual model products (for example, from a CRM system or a product master catalog) and their attributes, then map the products to existing fulfillment patterns. See "Importing Products" for more information. See "About Products" for information about creating new products in Design Studio.
(Optional) Model fulfillment states.
You use fulfillment states to provide an aggregated status of orders and order items. Fulfillment state functionality maps the statuses received from external systems into normalized statuses for the order components, order items, and the order itself.
When configuring fulfillment states, you:
Define external fulfillment states for order components
Create a list of values for the order component that matches the statuses returned by the external systems or automations. An external fulfillment state is available on the order component where it is defined and on any order component that extends that order component. See "Order Component Specification Editor External Fulfillment States Tab" for more information.
Create and configure fulfillment state maps.
Create one or more lists of values for the common fulfillment states and create mappings to translate external fulfillment states into mapped fulfillment states. See "About Fulfillment State Maps" for more information.
Create and configure order item fulfillment state composition rule sets and order fulfillment state composition rule sets.
Create the composition rule sets to determine the fulfillment state of an order or order item from the fulfillment state of its child items. Composition rule sets are based on the order item and order hierarchy, and compose fulfillment states into composite fulfillment states that reflect the state of entire order items or orders. See "About Order Item Fulfillment State Composition Rule Sets" and "About Order Fulfillment State Composition Rule Sets" for more information.
(Optional) Model order item transformation.
The order transformation manager provides you with the ability to transform order items. For example, you can use order transformation manager to transform customer-focused order items (what the customer bought) to service-focused order items (the services that equate to what the customer bought). It enables you to set up guidelines for order transformation that do not need to be changed due to product changes. The easiest way to implement order item transformation is to use the functionality provided in design patterns and then customize it for your needs.
When configuring order item transformation, you:
Run the Model Project's Common Model Base Data design pattern.
This provides you with the conceptual model entities that will help you to model your transformation.
Create an order item specification to contain the transformed order items.
See "Working with Order Items" for more information.
Run the OSM Calculate Service Order design pattern and configure the transformation sequence.
This creates a transformation sequence that is pre-configured with four stages. After running the design pattern, ensure that the configuration of the transformation sequence meets your needs. See "Working with Transformation Sequences" for more information.
Configure the conceptual model services appropriate to your situation.
In the conceptual model you configure entities to model the domains and services that you are provisioning. See "Working with Conceptual Models" for more information.
Create a transformation manager.
Create a transformation manager to map your transformation sequence to the service domains within your provider function. See "Working with Transformation Managers" for more information.
Model the data for your transformation.
Use order item parameter bindings to map data from the conceptual model entity to the order item. The Order Item Parameter Binding design pattern is available to assist with this. See "Working with Order Item Parameter Bindings" for more information.
Use mapping rules to map the data from the original order items to the transformed order items. See "Working with Mapping Rules" for more information.
Test configurations and orders in Design Studio.
When you've completed modeling, you can test the model and review the configuration. To test a cartridge, you submit the order to an OSM environment and monitor the results in a web user interface. See "Deploying Cartridge Projects with Optimize Deploy" and "Packaging and Deploying OSM Cartridges" for more information.
Deploy the cartridge.
You package the cartridge with the entities, libraries, and resources that you want to include in the cartridge file. Then, you connect to the Design Studio environment to deploy your cartridges. See "Packaging and Deploying OSM Cartridges" for more information.