5 Modeling Orchestration Plans

This chapter describes how to model orchestration plans in an Oracle Communications Order and Service Management (OSM) solution.

Orchestration Plan Overview

An orchestration plan includes the order items, order components, and dependencies. An order-specific orchestration plan is generated for each order that requires orchestration.

The orchestration plan for an order specifies the following:

• How order items are grouped into order components for processing

• The dependencies between the order components

In the OSM Order Management web client, you can view graphical representations of an order's orchestration plan and dependencies. You can use this information as you model orders to validate that order decomposition and orchestration plan generation is functioning as intended. The graphical representation shows exactly how an order is fulfilled.

The Order Management web client provides a graphical representation of the orchestration plan in two views:

• Orchestration plan decomposition

• Orchestration plan order item dependencies

Figure 5-1 shows three orchestration stages, represented in three columns:

• Determine the fulfillment function

• Determine the fulfillment system

• Determine the processing granularity

Note:

You can model any number of orchestration stages.

At each orchestration stage, the graph shows the order components created by that stage. The final column on the right shows the order components that are run as part of the orchestration plan. Each component includes a name, which is based on the orchestration stages. Components also list their included order items.

The inset in Figure 5-1 shows details for three executable order components, as displayed in the orchestration plan decomposition.

Figure 5-1 Decomposition Tree

Description of "Figure 5-1 Decomposition Tree"

Figure 5-2 shows the orchestration plan displayed in the Order Management web client dependency graph. The dependency graph shows the executable order components which are the components shown in the final stage of the decomposition display. In this case, executable components are based on three orchestration stages corresponding to fulfillment function, fulfillment system, and processing granularity. The different colors represent fulfillment functions, such as InitiateBilling or FulfillBilling. The inset shows a detailed view of two order components. Even though the two fulfillment functions are targeted to the same system (BRM-VOIP), processing granularity rules defined for this order require that they take place as two separate actions.

Figure 5-2 Dependency Graph

Description of "Figure 5-2 Dependency Graph"

Both of these representations are useful at design time and when debugging orchestration plans. For example, you can use the dependency graph to confirm that an order goes to all of the correct systems in the correct order. Use the decomposition tree to verify that decomposition happens as expected at a particular stage and that the order was decomposed into the correct components, each containing the correct order items.

Modeling an Orchestration Plan

To model how orchestration plans are generated, you model several OSM entities in Oracle Communications Design Studio.

• Orchestration processes. An orchestration process specifies which orchestration sequence to use for the order.

• Orchestration sequences. The orchestration sequence specifies the fulfillment mode (for example, Deliver or Qualify), the orchestration stages, and selects the customer order line item node-sets that OSM uses in orchestration.

• Order item specification. The order item specification includes the order item properties that are used for decomposition, including how to retrieve order items from order line items. Order item properties define data that is used for decomposition; for example, the fulfillment pattern.

• Order components. Order components specify how to organize order items in the decomposition process.

• Orchestration stages. Orchestration stages specify the order components to assign order items to.

Figure 5-3 shows a generalized process flow for orchestration.

Figure 5-3 Orchestration Process

Description of "Figure 5-3 Orchestration Process"

The following process flow shows how OSM uses the orchestration entities to create orchestration plans.

1. After receiving and validating an incoming customer order, OSM creates the order according to the order specification chosen by the recognition rule. At this point, the following has been accomplished:

   • The order has been populated with the creation task data.

   • OSM has used the order item specification to identify order items from the order line items in the incoming customer order.

2. The order specification includes a default process. For an orchestration order, the order specifies an orchestration process. (If no orchestration is required, you should define a non-orchestration OSM process. See "Modeling Processes and Tasks" for more information.)

3. The orchestration process specifies an orchestration sequence.

4. The orchestration sequence specifies the following:

   • The order item specification to use for the order. The order item specification defines the order item properties that are used for decomposition and for displaying the order item in the Order Management web client. See OSM Concepts for more information.

   • The order item selector that identifies the customer order line item node-sets to use as order items.

   • The fulfillment mode that the order requires; for example, Deliver or Cancel.

   • The orchestration stages that produce the order components. For example, the orchestration stages might be:

     • Produce function order components. This stage organizes order items into order components based on the fulfillment functions required for each order item. Fulfillment functions are the activities that must be performed to process the item, such as billing, shipping, provisioning, and so on.

     • Produce target system order components. This stage organizes order items into order components based on the target fulfillment systems required to perform the fulfillment functions. For example, this step might determine that certain items need to be fulfilled by a billing system called BRM_Residential and others by a BRM_Wholesale system.

     • Produce granularity order components. This stage organizes order items that need to be processed together into order components. For example, you might need to fulfill billing requirements for mobile and fixed services. You can use different order components to process the billing requirements for those services separately.

5. Each orchestration stage produces a set of order components.

6. Based on the default orchestration process, and the orchestration sequence and stages that are defined, OSM can start the process of assigning order items to order components. The first step is to find the fulfillment pattern used by each order item.

   Each order item belongs to a product specification. A product specification is a group of related products that share common attributes. For example, the products Broadband Light, Broadband Medium, and Broadband Ultimate would all belong to the ServiceBroadBand product specification. OSM maps the product specification to a fulfillment pattern.

   The fulfillment pattern manages the first stage of orchestration. It assigns order items to function order components in the first stage of orchestration. It also specifies the dependencies between the function order components. For example, the fulfillment pattern might specify to process function order components in this order:

   1. ProvisioningFunction

   2. BillingFunction

   3. CollectionsFunction

   The fulfillment pattern also specifies the fulfillment mode that the order items can be used for. See "About Mapping Order Items to Fulfillment Patterns" for more information.

   Provisioning must occur before billing, which must occur before marketing, customer updates (SyncCustomer), and collections.

   Figure 5-4 Dependency Relationships for Order Item Dependency

   
   Description of "Figure 5-4 Dependency Relationships for Order Item Dependency"

7. After assigning order items to function components, OSM further decomposes the order into target system order components and granularity order components, following the specifications defined in the orchestration stages. See "About the Decomposition of Function to Target System Components" and "About the Decomposition of Target System to Granularity Components" for more information.

8. While decomposing the order, OSM finds dependencies between order components and generates an orchestration plan. Dependencies determine the order in which order components can be processed.

9. After generating the orchestration plan, OSM runs it. Each executable order component runs a process. Each process includes the tasks that fulfill the order requirements.

Order components are usually modeled by extending order component specifications in Design Studio. For example, you can create a base order component for all function types and extend it for individual function types such as billing or collections.

About Component Names and Component IDs

Each order component has an order component name and an order component ID. (This component ID is stored in the order template in ControlData/Functions/OrderComponentName/componentKey). The component name is specified at design time. The component ID is generated for each instance of the order component at run time.

The component name is the name of the order component specification; for example, BillingFunction or BillingSystem. By default, the component ID is a concatenation of the names of the order components in the orchestration stages. For example, if the component names are modeled as:

• BillingFunction

• BillingSystem

• Bundle

The component IDs generated at run time are:

• BillingFunction

• BillingFunction.BillingSystem

• BillingFunction.BillingSystem.Bundle

You can use customized order component IDs when assigning order items to order components. See "About the Decomposition of Target System to Granularity Components" for more information. For more information about creating valid data keys, see, "Modeling Valid Data Keys."

About Order Items

Prior to generating an orchestration plan, OSM processes each customer order line item in the incoming customer order and turns it into an order item. The order item properties define the data that is included from these order items using XQuery expressions.

Order items are individual products, services, and offers that need to be fulfilled as part of an order. Each item includes the action required to implement it: Add, Suspend, Delete, and so on. For example, a new order might add a wireless router; the order item created in OSM is Add Wireless Router.

When you model order items, you do not model every possible order item. Instead, you create an order item specification, which defines:

• The data that each order item can include

• The structure of the data; for example, the hierarchy between order items

• Data needed for orchestration

There must be one order item specification for each type of order received from the order-source system. When you model an order item specification, you can configure the following:

• Order item properties. Order item properties represent the data that is included in order items. See OSM Concepts for more information.

• Orchestration conditions. Use orchestration conditions to customize how order items are added to order components. For example, you can use the region order item property to assign order items to different target system order components. See "About the Decomposition of Function to Target System Components" for an example of how orchestration components are used.

• Order item hierarchies. You use order item hierarchies to model how parent and child items are identified. For example, you can use line IDs and parent line IDs. See "Modeling Order Item Hierarchies" for more information.

• Order template. This data is the order item control data, which is used by OSM when generating an orchestration plan. You can also assign behaviors to order items. See OSM Concepts for more information.

• Order item dependencies. Use order item dependencies to create inter-order dependences. See "About Inter-Order Dependencies" for more information.

• Permissions. Use permissions to allow specific roles access to order item search queries in the Order Management web client and to specify if the query returns summary data or detailed data. See "Modeling Roles and Setting Permissions" for more information.

Most order items properties must be created in Design Studio and associated with corresponding customer order element values using XQuery expressions (see "About Order Item Specification Order Item Property XQuery Expressions"). However, in some cases the order item property is not provided in the customer order. In this case, you must use an XQuery expression to derive the missing property value from the existing customer order element values.

Example 5-1 shows an order line item. This order line item adds a Commercial Fixed Service order item. In the following example, notice that the items in bold correspond to the order item properties. However, there are order item properties, such as productSpec and region, that are not in the order line item. Instead, you specify to create those order item properties by using XQuery expressions in the order item specification.

Example 5-1 Order Line Item in an Incoming Customer Order

<im:salesOrderLine>
   <im:lineId>4</im:lineId>
   <im:parentLineReference>
      <im:parentLineId>3</im:parentLineId>
      <im:hierarchyName>default</im:hierarchyName>
   </im:parentLineReference>
   <im:rootParentLineId>2</im:rootParentLineId>
   <im:promotionalSalesOrderLineReference>1
</im:promotionalSalesOrderLineReference>
   <im:serviceId>552131313131</im:serviceId>
   <im:requestedDeliveryDate>2001-12-31T12:00:00</im:requestedDeliveryDate>
   <im:serviceActionCode>Add</im:serviceActionCode>
   <im:serviceAddress>
      <im:locationType>Street</im:locationType>
      <im:nameLocation>OLoughlin</im:nameLocation>
      <im:number>48</im:number>
      <im:city>Toronto</im:city>
   </im:serviceAddress>
   <im:itemReference>
      <im:name>Commercial Fixed Service</im:name>
      <im:typeCode>PRODUCT</im:typeCode>
      <im:primaryClassificationCode>Fixed Service Plan Class</im:primaryClassificationCode>
   </im:itemReference>
</im:salesOrderLine>

Figure 5-5 shows all of the order items derived from an order, including the order item shown in Example 5-1.

Figure 5-5 All Order Items in an Order

Description of "Figure 5-5 All Order Items in an Order"

In Figure 5-5, notice that order items are hierarchical. For example, the Fixed Service order item shown in Example 5-1 is part of the Fixed Bundle order item. In addition, the Fixed Service order item includes three more order items: Commercial Fixed Service, Fixed Caller ID, and Fixed Call Waiting. When you model orchestration, you ensure that the hierarchy in the incoming customer order is duplicated in the OSM order items. See "Modeling Order Item Hierarchies" for more information.

The order item specification defines the order item properties that are required for generating the orchestration plan and the data to display in the Order Management web client. This typically includes the display name, product specification, line ID, requested delivery date, and so on. By contrast, the order item usually would not include supplementary account and customer details such as the street address or mailbox size. That type of data is defined in the task data for each task in the fulfillment data, and in the creation task data when the order is created.

Caution:

Order item properties do not represent all of the data in an order. For example, they do not define creation task data. That data is captured by transformation rules. Order item properties are a subset of the data and are used for orchestration.

Figure 5-6 shows part of an order input file and how the city field is mapped to the region order item property in Design Studio. In this example, the <city> element in the XML file is used in the order item property expression.

See "About the Decomposition of Function to Target System Components" for an example of how the region order item property is used in orchestration.

Figure 5-6 Order Line and Definition in Order Item Specification

Description of "Figure 5-6 Order Line and Definition in Order Item Specification"

A single order item specification is used for generating all of the order items that can be created for an order. This ensures a consistent order item structure. Therefore:

• Order item properties should not be product or service specific. The only product information you need to include is the product specification, which is a generic value used for identifying the fulfillment pattern. By not applying order items to a specific product, you can use the order item specifications for multiple products, and you can support new products and services and multiple order entry systems.

• Order item properties should not be specific to any order entry system.

Caution:

When defining order item properties, include only the data required by OSM for orchestration. Performance is impacted by the number and size of order item properties.

The properties you define for your order items will be different from those pictured in Figure 5-6. However, this selection provides a good example of the type of order properties that are commonly configured:

• productSpec: This property retrieves the product specification from the incoming customer order. OSM maps each order item to a fulfillment pattern based on the item's product specification (defined in the order-source system). The fulfillment pattern specifies the order components in the first level of decomposition.

• fulfillmentPattern: This property stores the fulfillment pattern that the order item uses. This value is obtained by mapping the productSpec value in a mapping file. See "About Mapping Order Items to Fulfillment Patterns" for more information.

• lineId: This is the line ID of the order line item in the incoming customer order. Each order line item in the incoming customer order has a unique line ID. This property is used for determining the hierarchy of the order items. You can determine a hierarchy of order items based on the lineID order item property and the parentLineId order item property. For example, an order item with lineId 4 also specifies a parentLineId as 3 which is the lineId of the parent order item. You can use this function to hierarchically relate various types of order line items, such as offers, products, and bundles of products, services, and resources. For example, an order could include a Broadband offer with a High Speed Internet bundle and an Internet Services service bundle. Both bundles would have the Broadband offer as parent. You can also use order item hierarchies to aggregate order item status. See "About the Decomposition of Target System to Granularity Components" for an example of how this property is used.

• lineItemName: This property is the display name used in OSM web clients.

• requestedDeliveryDate: This property is the requested completion date for the order item.

• parentLineId: This property defines the parent of the order line item in the incoming customer order. This property is used for determining the hierarchy of the order items. See "About the Decomposition of Target System to Granularity Components" for an example of how this property is used.

• region: This property is an example of data that can be used to manage decomposition into target system order components. See "About the Decomposition of Function to Target System Components" for more information.

• serviceId: This property is used to display the service ID in the OSM web clients.

• lineItemPayload: This property stores the entire incoming customer order in OSM as an XML file. This property is typically used in a development environment as an aid to modeling.

About Creating Order Items from Customer Order Line Item Node-Sets

To create order items from customer order line items, OSM needs to know what nodes in the incoming customer order include the data to use in order items. OSM creates orchestration control data from these nodes (see OSM Concepts).

Example 5-2 shows the salesOrderLine node-set in an incoming customer order. You can specify these node-sets as order items by creating an XQuery expression in the Orchestration Sequence editor that returns every instance of <salesOrderLine> contained in the customer order (see "About Order Item Specification Order Item Property XQuery Expressions"). These node-sets produce the Broadband Bundle and the Mobile Bundle order items. The elements in these node-sets can then be specified as order item properties in the order item specification.

Example 5-2 The <salesOrderLine> Element in an Incoming Customer Order

<im:salesOrderLine>
   <im:lineId>13</im:lineId>
   <im:promotionalSalesOrderLineReference>1
   </im:promotionalSalesOrderLineReference>
   <im:serviceId></im:serviceId>
   <im:requestedDeliveryDate>2001-12-31T12:00:00</im:requestedDeliveryDate>
   <im:serviceActionCode>Add</im:serviceActionCode>
   <im:itemReference>
      <im:name>Broadband Bundle</im:name>
      <im:typeCode>BUNDLE</im:typeCode>
      <im:specificationGroup></im:specificationGroup>
   </im:itemReference>
</im:salesOrderLine>
<im:salesOrderLine>
   <im:lineId>14</im:lineId>
   <im:promotionalSalesOrderLineReference>2
   </im:promotionalSalesOrderLineReference>
   <im:serviceId></im:serviceId>
   <im:requestedDeliveryDate>2001-12-31T12:00:00</im:requestedDeliveryDate>
   <im:serviceActionCode>Add</im:serviceActionCode>
   <im:itemReference>
      <im:name>Mobile Bundle</im:name>
      <im:typeCode>BUNDLE</im:typeCode>
      <im:specificationGroup></im:specificationGroup>
   </im:itemReference>
</im:salesOrderLine>

About Associated Order Items

Figure 5-7 shows the associated order items, displayed with (assoc) in the orchestration plan.

Figure 5-7 Associated Order Items Displayed in the Order Management Web Client

Description of "Figure 5-7 Associated Order Items Displayed in the Order Management Web Client"

Caution:

Associated order items are not considered as part of the decomposition and dependency calculations when OSM generates an orchestration plan. Therefore, you cannot reference associated order items in decomposition or dependency rules.

You model order item associations in fulfillment patterns. Figure 5-8 shows an order item association modeled for the Bundle order component in the Service.Mobile fulfillment pattern.

Figure 5-8 Order Item Associations in a Fulfillment Pattern

Description of "Figure 5-8 Order Item Associations in a Fulfillment Pattern"

There are three ways to associate order items:

• Fulfillment pattern: This is the default entry. It associates order items by fulfillment pattern, which is the normal orchestration method.

• Matching Order Component ID: This associates order items by matching component ID.

• Property correlation: This associates order items by using order item properties. See "About Associating Order Items Using Property Correlations XQuery Expressions" for more information.

Modeling Order Item Hierarchies

Order items can be organized hierarchically based on the content of the original customer order. You can configure OSM with the following types of order item hierarchies:

• Physical Hierarchy: The hierarchy can include various types of order line items, such as offers, products, and bundles of products or services. For example, an order could include a Broadband-VoIP offer with a High Speed Internet bundle, an Internet Services service bundle, and a Wireless Router product item. OSM maintains the order line item hierarchy from the customer order in the order item hierarchy.

• Composition Hierarchy: You can use composition hierarchies with fulfillment state composition rule sets to determine the parent/child relationship between order items so that OSM can determine aggregate fulfillment states for parent order items. See OSM Concepts for more information.

• Dependency Hierarchy: You can specify a dependency hierarchy that OSM uses to automatically configure dependencies between order items on an order. For more information, see "About Processing Order Items Sequentially".

Figure 5-9 shows a physical order item hierarchy that reflects the structure of the original customer order.

Figure 5-9 Physical Item Hierarchy

Description of "Figure 5-9 Physical Item Hierarchy"

The hierarchy is defined in the <lineID> and <parentLineId> elements. Figure 5-10 shows the first part of Figure 5-9, as it appears in an incoming customer order.

Figure 5-10 Item Hierarchies in an Incoming Customer Order

Description of "Figure 5-10 Item Hierarchies in an Incoming Customer Order"

To define the order item properties that specify the hierarchy, you configure the order item hierarchy in the order item specification using an XQuery expression. See "About Order Item Specification Order Item Hierarchy XQuery Expressions" for more information.

An order item hierarchy is invalid when:

• The hierarchy refers to an non-existent parent or child line ID.

• When the key or parent key XQuery is wrong.

• When the hierarchy specifies a circular relationship. For example, the parent of an order item is itself, or if order item A is the parent of order item B and order item B is also the parent of order item A.

OSM does not apply invalid order item hierarchies, but instead runs the order without any hierarchy.

About Using a Distributed Order Template

The distributed order template is a structure data type that is available only for order item specifications. It improves performance and also has the following benefits:

• Reduces order node conflicts: Without the distributed order template, data elements in the data dictionary that have the same name need to have the same definition (type, description, etc.) regardless of whether they appear in different structures in different places in the data dictionary. With the distributed order template, this is no longer necessary.

• Allows data changes without having to redeploy the entire solution: Without the distributed order template, any changes to the data defined for the order (including order item property updates) requires redeployment of the entire solution. With the distributed order template, if you change order item properties, you need to deploy only the cartridge containing the changed order item.

You decide whether to use the distributed order template by selection the appropriate box in the order item creation wizard or in the Order Item Specification editor in Design Studio. For more information, see Design Studio Modeling OSM Orchestration Help.

If you use a distributed order template, any references you make to order item data in XQuery expressions or automation must include a namespace. References to data in data change notifications and flexible headers do not need to change. For any order item that is not a transformed order item, the namespace will always be the namespace of the order item specification. Following is an example of an XQuery reference to the lineItemID property on the InputOrderItem order item with the namespace http://ex_input.com:

/ControlData/OrderItem[@type='{http://ex_input.com}InputOrderItem']/lineItemID

If you are using the order transformation manager, see "Using the Distributed Order Template with the Order Transformation Manager" for information about the namespace that will be used for transformed order items.

About Mapping Order Items to Fulfillment Patterns

The first orchestration stage assigns order items to function order components, by using fulfillment patterns. You need to model how to map order items to fulfillment patterns and implement the model using an XQuery expression (see "About XQuery Expressions for Mapping Product Specifications and Fulfillment Patterns" for more information).

Each order item in an order must have an order item property that specifies a value that represents a product, service, resource, or action. You map the value of the order item property to a corresponding fulfillment pattern designed to fulfill the order items mapped to them. Fulfillment patterns organize the functions into which order items decompose, any conditions that govern when an order item can be included in a function, and any associated order items that might be included in a function from different fulfillment patterns. Ideally, there ought to be a many-to-one relationship between order items and fulfillment patterns.

The way order items decompose to fulfillment patterns and further into functions depends on what kind of order item it is. For example, at the central order management (COM) level, you might group bundle order items as children of offer order items. The bundle order items would in turn be parents to product order items. Example 5-3 is a possible hierarchy where each product order item maps to either an Service.VoIP or Service.CPE.VoIP fulfillment pattern:

Example 5-3 Sample COM Order Item Hierarchy

1 On Top of the World Broadband-VoIP (OFFER)
     5 High Speed VoIP Service             (Bundle)
          6-VoIP Services                     (Product) ---> Service.VoIP
             7-VoIP PS                          (Product) ---> Service.VoIP
                 20-Value Added Features PS     (Product) ---> Service.VoIP
                 22-VoIP Adaptor PS             (Product) ---> Service.CPE.VoIP
                 25-VoIP Phone PS               (Product) ---> Service.CPE.VoIP
                 26-VoIP Soft Phone PS          (Product) ---> Service.CPE.VoIP
                 27-VoIP Visual Voicemail PS    (Product) ---> Service.VoIP
                 28-VoIP Voicemail PS           (Product) ---> Service.VoIP

Those order items destined to the Service.VoIP fulfillment pattern would decompose to the following functions:

• ProvisionOrderFunction

• InitiateBillingFunction

• SyncCustomerFunction

• FulfillBillingFunction

You can configure conditions where an order item might not be included in a specific function. For example, if a customer decides to move their VoIP service from one residence to another, you could configure a condition on the InitiateBillingFunction that would block the VoIP service order items from being included in the InitiateBillingFunction since the customer is already being billed for the VoIP services.

Sometimes, you need to assign order items to order functions that would not be assigned to the current fulfillment pattern by their product specification. This requirement can occur when an interaction with an external system requires a specific context for an order item.

For example, a billing system might need to process billing-related order items in the context of a bundle, to manage the relationships between balances, discounts, and so on. Billing charges are often order line items, such as an installation service, that are included in the order outside of the service billing bundle hierarchy. However, they might need to be associated with the billing bundle to ensure that the charge is made against the correct service. In that case, you can associate the billing charges with a bundle order component. By contrast, billing order items might be sent to the billing system in the context of a whole order. In that case, you do not need to associate the order items to a bundle, because they are already in context.

About Modeling Product Specifications

New product specifications should be imported (which will create conceptual model products) or created in the conceptual model. If you have an existing configuration, however, you can still use product specifications (formerly called product classes) that were created in OSM.

You can map multiple product specifications to one fulfillment pattern. This enables you to introduce new products in existing product specifications without needing to create new fulfillment patterns or fulfillment flows.

The Design Studio conceptual model functionality helps you model data as part of an end-to-end solution in an application agnostic way. You create conceptual model projects to:

• Define products.

• Define the services that the products represent.

• Define the resources that implement those services.

• Define service domains, such as broadband (ADSL, VDSL, DOCSIS, and Fiber), VoIP, email, Mobile, and so on.

• Define actions and relationships between products, services, and resources

Conceptual model items are not built into OSM cartridges or deployed to the OSM server directly. They are included into OSM by something called realization. Realization refers to converting the abstract entities in the conceptual model into actual instances in the OSM configuration. You can use this conceptual model metadata as part of your OSM run-time solution to help define order item to fulfillment pattern mappings and to give you an representation of what you need to implement in OSM as part of your overall fulfillment solution.

See Design Studio Concepts for more information about conceptual model projects. See "About XQuery Expressions for Mapping Product Specifications and Fulfillment Patterns" for more information about using conceptual model entities to map order items to fulfillment patterns. See "OSM Solution Modeling Overview" for more information about how OSM can be modeled in an end-to-end solution.

Modeling Fulfillment Modes

The fulfillment mode is the overall purpose of the order. For example:

• Deliver a service.

• Qualify a service before delivering it. This ensures that a service can be fulfilled before attempting to fulfill it.

• Cancel an entire order.

Every incoming customer order can specify a fulfillment mode.

OSM can use the fulfillment mode as part of the orchestration process. For example, if OSM receives two identical incoming customer orders with different fulfillment mode order item properties, it generates a different orchestration plan for each order. The two plans include different executable order components with different dependencies among order items.

Fulfillment modes are configured in the following places:

• Fulfillment mode entities: These entities include no data other than a name. They provide the means to assign fulfillment modes to other entities, such as orchestration sequences and fulfillment patterns.

• Orchestration sequences define a single fulfillment mode using an XQuery expression based on a customer order attribute (see "About Order Sequence Fulfillment Mode XQuery Expressions").

• Fulfillment patterns list the fulfillment modes that the associated order items can be used with.

  Figure 5-11 shows the fulfillment modes defined in a fulfillment pattern. Any order item that uses this fulfillment pattern can be processed in either the Cancel or Deliver fulfillment mode.

Figure 5-11 Fulfillment Modes Defined in a Fulfillment Pattern

Description of "Figure 5-11 Fulfillment Modes Defined in a Fulfillment Pattern"

When a fulfillment pattern includes multiple fulfillment modes, you can model a different set of order components and dependencies for each fulfillment mode.

About the Decomposition of Order Items to Function Order Components

The following sections describe the decomposition of order items to function order components.

About Assigning Order Items to Fulfillment Pattern Function Components

The first step in decomposition is to assign order items to function components. To do so, OSM uses the product specification to find the fulfillment pattern that the order item uses. (See "About Mapping Order Items to Fulfillment Patterns" for more information.) The fulfillment pattern defines the order components to add the order item to.

Figure 5-12 shows the function order components selected in the Service.Broadband fulfillment pattern. In this case, order items that use this fulfillment pattern need all of the functions; billing, collections, provisioning, and so on.

Figure 5-12 Function Order Components Selected for a Service Fulfillment Pattern

Description of "Figure 5-12 Function Order Components Selected for a Service Fulfillment Pattern"

Figure 5-13 shows how to use a base specification to define the same function order components as described above. In this case, the base fulfillment pattern selects all of the function order components except provisioning. The service and non-service fulfillment patterns inherit the selections. The service fulfillment pattern adds the provisioning function. The non-service fulfillment pattern does not add it.

Figure 5-13 How to Use a Base Specification to Define Function Components

Description of "Figure 5-13 How to Use a Base Specification to Define Function Components"

About the Function Components Stage

In addition to using the fulfillment pattern to assign order items to function components, you model an orchestration stage, which specifies to create the function order components to create.

About Order Component Control Data

When OSM creates the order items and order components, it produces a set of control data. The control data provides information OSM requires to fulfill the order. OSM uses the control data to track the status of the entire order and to track the status of the individual order items. During fulfillment, order component transactions update this control data with system interaction responses.

Design Studio automatically generates control data for function order components provided that orchestration entities are preconfigured correctly and you use the OracleComms_OSM_CommonDataDictionary model project. If you do not use the OracleComms_OSM_CommonDataDictionary model project, you must manually model order component control data. See "About Modeling Order Component Control Data" in Modeling OSM Orchestration for information on how order component control data is automatically generated or how to manually model it.

See "Modeling OSM Data" for more information on adding function order components to the order control data.

About Fulfillment Pattern Conditions for Including Order Items

You can use conditions to add order items to an order component only when the XQuery for the condition evaluates to true. For example, you might include an order item based on an XQuery that checks the action code (Add or None). This is useful in the case of an update to a service that changes some features while leaving other features unchanged. See "About Order Item Specification Condition XQuery Expressions" for more information.

Summary of Order Item to Function Components Decomposition

To summarize this example, to model the decomposition from a order items to a function component, you model the following:

• The fulfillment pattern order item property so that order items can be mapped to fulfillment pattern function components.

• Any XQuery expressions that evaluate conditions to include or exclude order items.

• The Order control data for orchestration.

• The orchestration stage that produces the function components

About the Decomposition of Function to Target System Components

The following sections describe the decomposition of order items from functional components to target systems.

About Decomposition Rules from Function Components to Target Systems

After the order items have been assigned to function order components, they need to be further decomposed into target system order components. To do so, you use decomposition rules.

A decomposition rule specifies a source order component and a target order component. Figure 5-14 shows a decomposition rule from the billing function component to the billing target system component.

Figure 5-14 Decomposition Rule

Description of "Figure 5-14 Decomposition Rule"

About Decomposition Rule Conditions for Choosing a Target System

You can use decomposition rules to decompose order items from one function component to multiple target system components. Figure 5-15 shows the source and target order components for two decomposition rules:

• Provision to DSL Provisioning System - Region1

• Provision to DSL Provisioning System - Region2

These two decomposition rules decompose the order items in the ProvisioningFunction order component into two target system order components based on Region 1 and Region 2.

Figure 5-15 Source and Target Order Components for Two Decomposition Rules

Description of "Figure 5-15 Source and Target Order Components for Two Decomposition Rules"

Each of the decomposition rules uses decomposition conditions to specify which target system to use for a particular order. The target system is selected if the XQuery expression associated with the condition evaluate to true. In this example, the XQuery expression uses the value of the region order item property to make this evaluation. If the value of region is Toronto, then OSM selects the condition and target system for Region 1. If the value of region is New York, then OSM selects the condition and target system for Region 2. See "About Order Item Specification Condition XQuery Expressions" for more information about creating an XQuery condition expression that can be used for with a decomposition rule.

About the Target Systems Stage

In addition to creating the decomposition rules that define the source and target components, you need to create an orchestration stage that produces the target system order components.

Summary of Configuring Target System Components Decomposition

To summarize, to configure how order items are decomposed from a function order component to a target system order component, you do the following:

• Define an orchestration stage to produce the target system order components.

• Create dependency rules to specify the source order components and target order components.

• If a function order component decomposes order items to more than one target system order component, create decomposition conditions. Decomposition conditions depend on data specific to the order items, so decomposition rules typically use XQuery expressions to retrieve the data that is used for evaluating the condition.

About the Decomposition of Target System to Granularity Components

The following sections describe the decomposition of order items from target system components to granularity components.

About Decomposition Rules from Target System to Granularity Components

After order items have been decomposed into target system order components, the next step is to decompose them into the granularity order components.

Some examples of the granularity requirements are:

• A billing system might require the entire order in the message to calculate discounts.

• A billing system might require separate bundles for mobile billing and fixed billing, to handle different completion times (fixed billing typically has more dependencies and takes longer).

To decompose target system order components items into bundle granularity components you configure the following:

• Create a decomposition rule, which decomposes the target system order component into bundle granularity components.

• Create customized component IDs (stored in the componentKey data element in the control data) that are used to create separate order components for each bundle. See "About Customized Component IDs for Separating Bundled Components" for more information. The componentKey data element is used as the data key for the order component. (See "About Order Data Position and Order Data Keys" for information about the use of data keys in OSM.)

About Customized Component IDs for Separating Bundled Components

You create the customized order component by editing the bundle order component specification.

You need to configure a decomposition rule and a bundle granularity order component specification to make sure that order items for a fixed service and a broadband service are decomposed into separate bundle granularity components, based on their customized component IDs. The customized component IDs result in separate instances of bundle order components, with separate component keys. This allows OSM to process the order components for the fixed service and the broadband service separately. If you do not create customized component IDs, the order items are processed together in the same order component.

This customization also ensures that the component ID is the same for order items within the same granularity (for example, a bundle) but not for order items at a higher granularity.

In addition, you may want to group order items into custom component IDs based on order item requested delivery date. For example, you might want an order component to process all order items with a requested delivery date that falls within the first two days of when an order start, and another order component for the next two days. You can further combine these grouping by requested delivery date within order item hierarchy groupings.

See "About Component Specification Custom Component ID XQuery Expressions" for more information about configuring custom order component hierarchies using XQuery.

About the Granularity Components Stage

In addition to creating the decomposition rules that define the source and target components, you need to create an orchestration stage that produces the granularity order components.

Summary of Configuring Granularity Components Decomposition

To summarize, to model the decomposition from a target system order component to a bundle order component, you model the following:

• The decomposition rule, which decomposes the target system order component into bundle granularity components

• The orchestration stage that produces the bundle order component

• The order item hierarchy that the XQuery ancestors function uses in the order item specification

• The XQuery for the customized order component in the bundle order component specification

About Dependencies

An orchestration plan is based on two main factors: decomposition, which derives the order components, and dependencies, which dictate when the order components are allowed to run. OSM calculates order item decomposition first before calculating dependencies.

Dependencies are relationships in which a condition related to one order item must be satisfied before another item can be processed successfully. For example, a piece of equipment must be shipped to a location before the action to install it at that location can be taken.

You typically create dependencies between order items in the same order (intra-order dependencies). You can model the following types of intra-order dependencies using fulfillment patterns:

• Order Item dependency: A dependency that requires the completion of one type of fulfillment function for an order item before starting another type of fulfillment function for the same order item within a single fulfillment pattern. For example, for a single order item included in a VoIP.Service fulfillment pattern, you can specify that the provision function order component must process an order item before the bill function order component can begin processing the same order item.

• Fulfillment pattern dependency: A dependency that requires the completion of a fulfillment function for an order item in a fulfillment pattern before starting a fulfillment function for another order item in a different fulfillment pattern. For example, for a single order item included in a VoIP.Service fulfillment pattern, you can specify that the provision function order component can only process an order item after the provision function order component on the BroadBand.Service fulfillment pattern has completed.

• Order item property dependency: A dependency that requires the completion of one order item before starting another order item based on order item properties.

• Order item hierarchy dependency: You can configure an order item hierarchy that automatically creates dependencies between predecessor and successor order items based on order item properties so that order items run sequentially. The successor order item can only begin after the predecessor order item completes. For example, order item A would have to complete all functions within its fulfillment pattern before order item B could begin processing its functions within its own fulfillment pattern. The fulfillment patterns could be identical or different, but they would have to be run separately for each order item with the parent child relationship.

For more information, see "About Intra-Order Dependencies".

You can also create dependencies between order items in different orders (Inter-order dependencies). For example, the order items in a follow-on order for VoIP provisioning might depend on the execution of the order items in the original order for DSL provisioning. See "About Inter-Order Dependencies" for more information.

You can model dependencies in two ways in Design Studio:

• As order item dependencies. These dependencies are modeled as part of fulfillment patterns. Most dependencies are modeled in this manner.

• As orchestration dependencies. These dependencies are modeled outside of fulfillment patterns. While not as common as those modeled in fulfillment patterns, orchestration dependencies are useful in specific circumstances; for example, if you need to define a generic dependency or want to model one without having to modify a fulfillment pattern.

Figure 5-16 shows order items displayed in the Order Management web client. In this example, the billing order items for a fixed service can start immediately because they have no dependencies. The billing order items for high-speed Internet must wait until the provisioning order items have completed.

Figure 5-16 Dependencies Displayed in the Order Management Web Client

Description of "Figure 5-16 Dependencies Displayed in the Order Management Web Client"

About Intra-Order Dependencies

A dependency requires two order components: the waiting order item and the blocking order item. The blocking order item is the order item that must complete before the waiting order item is started.

Dependencies can be based on several different factors, including:

• Completion status. For example, the blocking order item must be complete before the waiting order item can start or you can specify to start billing only after provisioning has completed.

• Actual and relative date and time. For example, you may want an order component that contains order items for an installation to start two days after the completion of the order component that contains the order items for shipping the equipment.

• Data change. For example, you can specify that shipping must wait until a specified order item property in the blocking order item has a specified value.

Order items can have combinations of dependencies. For example, an order item for an installation can depend on a combination of a completion status dependency (item successfully shipped) and date dependency (wait two days after shipment to schedule installation).

Note:

You can manage dependencies during amendment processing; for example, when you submit a revision order. See "Modeling Changes to Orders" for more information.

Although dependencies exist logically between order items, they are managed by order components. In other words, if any item in a component has a dependency, the component as a whole cannot be started until the dependency is resolved. In the Order Management web client, order items include dependency IDs to indicate items whose dependencies are managed together. See OSM Order Management Web Client User's Guide for more information.

Modeling an Order Item Dependency

The simplest form of dependency is an order item dependency, configured in a fulfillment pattern. This type of dependency is based on function order components; for example, the billing order component cannot start until the provisioning function has completed.

Figure 5-17 shows a dependency relationships. Note the two layers of dependency: billing is dependent on provisioning, and everything else is dependent on billing.

Figure 5-17 Dependency Relationships for Order Item Dependency

Description of "Figure 5-17 Dependency Relationships for Order Item Dependency"

In addition to defining the function order components, you need to define the conditions that govern the dependency. The default condition is to wait until the final task associated with the order item has completed. Figure 5-18 shows a wait condition defined in Design Studio. In this case, the waiting order item must wait until the blocking order item task has reached the Completed state. See "About Order Item Dependency Wait Conditions" for more information.

Figure 5-18 Wait Condition in Design Studio

Description of "Figure 5-18 Wait Condition in Design Studio"

About Order Item Dependency Wait Conditions

Dependency wait conditions specify the condition that the blocking order item must be in before the waiting order item can start. For example, the default wait condition is to start the waiting order item when the last task associated with the blocking order item reaches the Completed state.

You specify wait conditions in fulfillment patterns and orchestration dependencies. You can set different wait conditions for each dependency. The wait conditions can be:

• The task state of the final task associated with the blocking order item

• A change in the data for a specified field. See "About Order Item Dependency Wait Conditions Based on Data Changes" for more information.

• A specified duration after the task state or data change condition has been met. You can specify a value in months, weeks, days, hours, or minutes, or you can specify an XQuery expression to determine the delay (see "About Wait Delay Duration XQuery Expressions"­). For example, you can specify to start the waiting order item two days after the blocking order item has completed.

• A specific date and time based on the result of an XQuery expression (see "About Wait Delay Date and Time XQuery Expressions"). For example, you can specify to start the To Component order component on a date specified in an order item property.

The orchestration dependency wait condition options are identical.

About Order Item Dependency Wait Conditions Based on Data Changes

You can base a dependency on a change to data. The data must be included in an order item property, and it must be in the task data of the task associated with the blocking order item.

To configure the dependency, you define the following:

• The order item property that is evaluated. Any change to the data in the order item property triggers an evaluation of the data to determine if it matches the conditions required for the dependency.

• An XQuery expression that evaluates the data retrieved from the blocking order item. The expression returns true or false; if true, the dependency has been met.

Figure 5-19 shows a data change dependency in Design Studio.

Figure 5-19 Data Change Dependency in Design Studio

Description of "Figure 5-19 Data Change Dependency in Design Studio"

In Figure 5-19:

• The Order Item field specifies the order item specification to use.

• The order item property that the dependency is based on is milestone.

  The Relative Path field (not used in this example) is an optional field you can use to specify a child data element in the order item properties.

• The XQuery expression evaluates the data in the milestone property to determine if the dependency has been met. See "About Order Data Change Wait Condition XQuery Expressions" for more information.

Modeling a Fulfillment Pattern Dependency

You can define dependencies across different order items by basing the dependency on the fulfillment patterns of the order items. For example, you can create a dependency that specifies to provision fixed services only after broadband services have been provisioned.

Figure 5-20 shows a dependency based on fulfillment pattern. In this example, the dependency requires that fixed services be provisioned before broadband services. To configure this type of dependency, you edit the fulfillment pattern of the waiting order item. In the fulfillment pattern, you provide a list of waiting and blocking order components.

Figure 5-20 Dependency Based on Fulfillment Pattern

Description of "Figure 5-20 Dependency Based on Fulfillment Pattern"

Figure 5-21 shows the dependency relationships shown in Figure 5-20. Note that fixed provisioning is the blocker for broadband provisioning and for fixed billing.

Figure 5-21 Dependency Relationships for Fulfillment Pattern Dependency

Description of "Figure 5-21 Dependency Relationships for Fulfillment Pattern Dependency"

Modeling an Order Item Property Correlation Dependency

Using properties correlation is the most flexible way to configure dependencies. You use this method to create a dependency on two different order items that share the same order item property. As with other dependencies, you specify a blocking component (the From Component field) and a waiting component (the To Component field), but you also enter an XQuery expression to select the order item property that order items in the To Component field must share with order items in the From Component field (see "About Order Item Dependency Property Correlation XQuery Expressions" for more information).

About Inferred Dependencies

OSM is able to create dependencies at run time by inferring dependencies. For example, you might create this series of dependencies:

Provisioning - Billing - Marketing

If the order item has no billing function, there is an inferred dependency between Provisioning and Marketing, even though you have not modeled that dependency. Provisioning must complete before Marketing can start.

Inferred dependencies mean that whenever A is dependent on B and B is dependent on C, A is dependent on C. This avoids the need to model every dependency that might be possible.

Figure 5-22 shows a sample dependency configuration. Figure 5-23 shows the run-time view of the same configuration when there is no billing function. In this case, the Order Management web client shows dependencies from provisioning to marketing, synchronize customer, and collections.

Figure 5-22 Dependency Relationship

Description of "Figure 5-22 Dependency Relationship"

Figure 5-23 Inferred Dependencies at Run Time

Description of "Figure 5-23 Inferred Dependencies at Run Time"

Inferred dependencies are supported within a fulfillment pattern, but they are not supported across fulfillment patterns. For example, OSM does not infer a dependency from ProvisioningFunction(Service.Fixed) to BillingFunction(Service.Broadband). You must specifically model that dependency.

About Modeling Orchestration Dependencies

You use orchestration dependencies to create dependencies between order components that are not based on fulfillment patterns. For example, if you need to define a generic dependency or want to model one without having to modify a fulfillment pattern, you can use an orchestration dependency specification.

As with dependencies defined in fulfillment patterns, you can specify wait conditions and the type of order item dependency (for example, order item, fulfillment pattern, and property correlation).

About Processing Order Items Sequentially

You can enable order items to process sequentially at run-time by setting an order item dependency hierarchy in the order item specification editor Order Item Hierarchies tab. When you model order items to run sequentially, avoid creating circular dependencies by ensuring that you do not include order items with a predecessor successor relationship into the same order component.

For example, you can ensure that only one order item processes at a time by configuring the orchestration granularity for a component to process only one order item at a time. Or you could also set the granularity for a component to process only a bundle of order items at a time. For example, between a bundle for VoIP and another bundle for Broadband. If parameters designating the successor predecessor relationship always establish a relationship between order items across two different bundles, then you avoid circular dependencies in this way as well.

Figure 5-24 shows how order items can be configured to process sequentially based on two order item properties defined in an order item specification order item hierarchy. You can use any order item property, so long as you can use the properties to establish the predecessor and successor relationship.

Figure 5-24 Order Item Processing Sequence

Description of "Figure 5-24 Order Item Processing Sequence"

See "Modeling Order Item Hierarchies" for more information about modeling order item hierarchies.

About Inter-Order Dependencies

An inter-order dependency is a dependency between order items in different orders. You typically configure this type of dependency to manage changes to an order when that order has passed the PONR and cannot be amended. However, you can also use inter-order dependencies for other purposes, such as managing fulfillment functions on different systems, load balancing, and so on.

When using inter-order dependencies, the blocking order is the base order, and the waiting order is a follow-on order. A typical scenario is:

1. A customer has ordered a broadband service.

2. The next day, while the order is still in-flight but past the PONR, the customer requests a change to the service bandwidth.

3. Because a revision to the base order cannot be submitted, the customer service representative creates a follow-on order.

4. The follow-on order is submitted to OSM; however, it does not begin processing until the base order has completed.

You typically model inter-order dependencies between a base order that has reached its point of no return (PoNR) (where a revision order is no longer possible) and a follow-on order (see "Modeling a Point of No Return" for more information). A follow on order does not trigger amendment processing on the original base order, but does have a dependency on one or more order items on the base order through the an inter-order dependency. You configure the inter-order dependency on the follow-on order so that it can check that the blocking order items on the base order have completed so that the waiting order items on the follow-on order can start processing.

Here are some important points to know about inter-order dependencies:

• Inter-order dependencies are based on order items. After the base order completes the blocking order item, the follow-on order can start, even though the base order is still in-flight.

• Inter-order dependencies are sometimes used to manage technical dependencies when a specific fulfillment requirement cannot be handled by a revision. However, they can also be based on business reasons, when it is simpler or more efficient to use a follow-on order than to model revisions.

• A follow-on order does not perform amendment processing on the base order. A follow-on order can be used to add, modify, or cancel services, similar to any order. The key feature is that a follow-on order has a dependency on another order.

You must model the inter-order dependencies into both the base order and the follow-on order.

• The follow-on order must be able to find the base order and be able to recognize if the blocking order item has completed.

• The base order must contain a reference to allow the follow-on order to find it.

To configure an inter-order dependency, you use the Order Item Dependencies tab. The configuration typically consists of the name of the dependency and its XQuery or data instance (see "About Order Item Inter-Order Dependency XQuery Expressions" for more information about inter order item XQuery expressions).

You can create inter-order dependencies that involve order item hierarchies. For example, you can specify that the blocking order item include all of the order items in its hierarchy. To do so, you select the child completion dependency when specifying an order item hierarchy (see Figure 5-25). For more information about order item hierarchies, see "Modeling Order Item Hierarchies").

Figure 5-25 Use for Child Completion Dependency Selected in Design Studio

Description of "Figure 5-25 Use for Child Completion Dependency Selected in Design Studio"

About Modeling Orchestration Dependencies

Figure 5-26 shows an orchestration dependency in Design Studio.

Figure 5-26 Orchestration Dependency in Design Studio

Description of "Figure 5-26 Orchestration Dependency in Design Studio"

Using Task States to Manage Orchestration Dependencies

You can use task states when defining orchestration dependencies. For example, you can specify to wait until a task has reached a specified state before an order component can be processed.