1 OSM Solution Modeling Overview

General Solution Data Modeling Principles

Modeling an OSM solution involves creating orders that contain the data involved in fulfilling actions such as add, change, delete, modify, move, and so on, on a product, service, or resource. In general, when you begin to model an OSM solution, you must understand the following data modeling principles:

• You must identify where the data you define comes from. For example, most data is defined in the CRM system in response to a request from a customer, but other data may be generated by downstream fulfillment systems that OSM interacts with.

• You must identify which system is the primary owner of each data structure or element. This principle is especially important in change order management and fallout management scenarios, where OSM must update data to modify or correct the fulfillment of an order.

  For example, if the SRM system that interacts with OSM SOM provides faulty network resource data that generates an error in the activation system that OSM TOM interacts with, then the SRM system must correct the faulty network resource data. Although it may be possible to correct the problem directly in the OSM TOM task that communicates with the activation system, this does not resolve the root problem, which originated in the SRM system. Allowing OSM TOM to correct the problem also causes the network resource data to be inconsistent between OSM TOM and the activation system, and between OSM SOM and the SRM system.

• You must understand how the data is propagated throughout OSM systems and service fulfillment systems. Although OSM should not add, change, or modify data owned by a fulfillment system, OSM does sort, route, format, and send the data so that other fulfillment systems can consume the data in the format they require.

  The solution that the OSM solution is a part of may contain an integration layer that determines a canonical format for data and provides standard interfaces to which OSM must conform. For example, Oracle Application Integration Architecture (Oracle AIA) integrates Oracle applications, such as OSM, Siebel Customer Relationship Management (Siebel CRM), and Oracle Communications Billing and Revenue Management (BRM), and also provides a standard format for message exchanges.

  When an OSM solution is not part of a solution with an integration layer OSM must conform to the data requirements and interfaces of each external fulfillment system.

Use these principles to clearly understand how order data is kept in OSM systems, and how data is communicated at the interactions between OSM systems and other fulfillment systems for every fulfillment action performed by the OSM solution.

See "Modeling OSM Data" for more information about modeling data in OSM solutions.

Performance Considerations

When modeling a solution, you should always keep solution performance in mind. The following factors have an impact on performance:

• Number of tasks in a process.

• Number of concurrently executing automation plug-in instances.

• Number, size, and depth of data elements in the order.

• Order view sizes and complexity.

• Number of order line items and complexity in an incoming order.

• Degree of XSLT and XQuery transformation.

• Complexity of the generated orchestration plan.

• Average number of revision orders per base order.

If you have not taken these factors into consideration when modeling your solution, and the results of system performance testing are unsatisfactory, you may have to change the solution modeling. For information about other system performance considerations, see OSM System Administrator's Guide and OSM Installation Guide.

Modeling COM Order and Order Recognition Requirements

You need to determine what kinds of orders to model in OSM, what order life-cycle states and state transitions the orders have, what user roles (workgroups) have permissions to perform tasks in fulfilling the orders, and what data should be visible to each user role (workgroup).

For example, you model customer orders for new orders, whether an in-progress order can be revised, and fallout orders that are triggered when customer orders or revision orders fail. You enable various order life-cycle states for each order, such as Not Started, In Progress, Canceling, Amending, and so on, and what transitions are possible from state to state. You must determine what personnel or systems have permissions to perform order state transitions and other functions and tasks involved in fulfilling orders.

You must also specify whether you want the order to use an orchestration or not. Oracle recommends using orchestration for most solutions. Use non-orchestration processes only when the order management requirements are simple, well understood, and relatively static.

You can model a single target order type that can process any type of incoming sales order, or you can model multiple order types based on product domain groupings. For example, you can create one order type for broadband, another for mobile, a third for cable, and so on. Using multiple order types, however, makes it difficult to bundle services and is also costly to maintain. Oracle recommends using one standard order type that accepts all incoming orders, and using other order types for only very specific uses, such as a fallout management order type that can extract information about failed orders.

If you create multiple order types, you also need to create corresponding order recognition rules that match incoming orders to the target order. Consider the following approaches when modeling order recognition rules:

• If you have different order source systems, each having its own order format, you can create multiple order recognition rules that point to the same target order. The order recognition rules transform the incoming order data into the target order data format.

• If you have multiple target orders based on domain groupings, you must create a separate order recognition rule for each target order type.

• If you have one OSM instance operating in more than one role (for example, if the same system is operating in both the SOM and the TOM role) you need to configure an order recognition rule that points to a corresponding target order for each role.

• If you have one order source system and one OSM instance operating in only one role, then you need only one order recognition rule that points to one target order.

You must determine what corresponding order recognition rules you need to model in OSM to recognize, validate, prioritize, and transform order data from sales orders into a matching OSM target order. You must map incoming order data to the data defined in the creation task of the target order.

See the following sections for more information:

• Modeling Orders and Permissions

• Modeling Order Life-Cycle Policies

• Modeling Order Recognition

COM Data Modeling Considerations

Answer the following questions to determine what corresponding order data you need to model on the sales order and the target order in OSM COM:

• What data is required to complete an order?

• What data do the tasks require? For example, if service provisioning requires the customer's location, then the order needs to include the customer's location.

• What data does the customer account require?

• What data is not required on the customer order, but is required by the service order that is derived from the customer order?

• What data do the tasks require when the order is created?

• Does the incoming order include all of the data needed for the order? If not, you can use data providers in your tasks to get the data from some other source.

• Which data on the order contain order item information that represents the offers, bundles, and products on the order?

• What order item parameters represent the name of the order item?

• If the order items are hierarchical, what data elements specify the parent and child relationship between each order item?

• If the order items must be delivered at different times and dates, what data element contains the requested delivery date?

• What data element specifies the action that must be performed on the order item during the fulfillment process (such as add, change, and so on)?

• What data element specifies the overall action of the order, such as deliver, cancel or technical service qualification (TSQ)?

• What data is required on the sales order for the billing system?

See the following sections for more information:

• Modeling Order Data

• Modeling Orders and Permissions

• Modeling Behaviors

Modeling COM Orchestration Order Items and Binding Conceptual Model Parameters

You must determine what order data to model as order items (see "COM Data Modeling Considerations") and what product specification the order items belong. You typically map order items to product specification by defining an order item property that OSM then uses to map the order item to specific fulfillment patterns, and so on.

You can also use Design Studio order item parameter bindings to map conceptual model entities their parameters to OSM order item specifications. This enables you to have strongly typed parameters that you do not need to model within order item specifications. You map conceptual model entities and their parameters to OSM order item specifications mainly to validate incoming order items and their parameters and/or transform the order items and their data from one type to another (for example, from products to CFSs).

In the OSM COM context, you map conceptual model products and data parameters to the COM order item specification for the incoming sales order and accompanying products, bundles, and offers. For example, Figure 1-1, "Sample Conceptual Model" defines the broadband service offer and several child product offerings such as broadband, bandwidth, firewall, email, and so on. OSM validates all order items against the corresponding conceptual model entities and their parameters. If you have configured the order transformation manager, OSM also transforms the products into CFSs (see "Modeling COM Order Transformation Manager" for more information).

If you do not need order item parameter bindings for validation or transformation, you must model parameters in the order item specification. You can designate an order item property to contain these parameters (typically name-value pairs) and designate the structure as XML Type in the Order editor Order Template tab, Properties tab, Order Data subtab for the selected data element. For example, order items at the COM level relating to billing information, such as promotional offers or recurrent charging information, may not need validation because the sales catalog is separately synchronized between the CRM and billing systems. In this scenario, OSM is only required send the order items on the sales order directly to the billing system. However, all other order items that must go to OSM in the SOM role would typically require both validation and transformation using the conceptual model.

Validating data against the conceptual model is important because this ensures the data is consistent across the entire OSS and BSS solution (OSM in COM, SOM, and TOM roles, the activation system, the SRM system, and so on).

See "Modeling Orchestration Plans" for more information.

Modeling COM Orchestration Order Item Decomposition

You need to decide what orchestration stages OSM should evaluate when decomposing order items into order components. These order components typically designate functions, systems, and granularity options.

Based on the previous sections, you should already have some knowledge of what the order you are creating contains. Use that knowledge to answer the following questions:

• What systems does OSM communicate with?

• What order items does each system require?

• What are the business functions that each system must perform on the order items?

• How should OSM deliver data for the functions to process? Does the function operate on the whole order, or does the function require a separate interaction per order item bundle or per order item?

Based on the answers you provide to these questions, you can begin to model order item decomposition stages.

Figure 1-2 shows a sample order capture and orchestration process. The process captures orders with an order recognition rule that maps the order and order data to a target order and creation task data elements. This order then begins an orchestration process that triggers an orchestration sequence. The sequence specifies which order node contains the order items, which order parameter defines the fulfillment mode for the order, and the stages in which the order items can be evaluated. The orchestration process determines which order components the order items should decompose to. In Figure 1-2, OSM sequentially evaluates:

• A stage that decomposes order items into order components that define functions.

• A stage that decomposes order items into order components that define systems.

• A stage that decomposes order items into order components that define granularity.

Figure 1-2 Sample Order Capture and Orchestration Process

You must determine what high-level tasks are involved in fulfilling customer orders at the OSM COM level. You can define orchestration order components that correspond to the functions performed by these tasks that you can then add to the function stage (see Figure 1-2). See "About the OSM Solution Modeling Process" for a sample list of OSM COM related tasks that can be modeled as function order components.

You must determine what kinds of BSS fulfillment systems you have at the OSM COM level. You can define orchestration order components that correspond to these systems. You can add these system order components to the system stage. As illustrated in Figure 1-1, "Sample Conceptual Model", the systems that normally interact with OSM COM include

• One or more billing systems: The billing systems manage the initial and recurring charges applied to the order.

• One or more OSM SOM systems: The OSM SOM system at the OSS level interacts with inventory systems. The inventory system designs and assigns services with their corresponding network resources.

OSM COM may need to communicate with different systems based on the location where the service is requested for.

You must also determine what kind of order granularity you need when fulfilling each function order components. Does the orchestration plan need to generate a separate function for each bundle destined for a particular system? Or, can the whole order be sent as one function to one system? You can define orchestration order components that correspond to the different levels of granularity you want to define. You can then add the order component to the granularity stage (see Figure 1-2).

For example, a customer might request an offer that includes the following order items:

BroadBand Service (Offer)
    BroadBand (Bundle)
        Promotion (Product)
        Bandwidth (Product)
        Router (Product)
        Firewall (Product)
    Email (Product)

The broadband service offer is parent to the broadband bundle order item and an email product order item. The broadband bundle is itself parent to promotion, bandwidth, router, and firewall product order items. It may be that you want the billing related functions to run separately for each child order item of the broadband service offer (the broadband bundle order item with all its children order items and the email product order item). Or you may want each billing function to run separately for each product order item in the order (email, promotion, router, bandwidth, and firewall). Finally, you could also send the entire offer with all bundles and products contained within it.

For each of these options, you need to create an order component that OSM can use to decompose the order items to. The order components can represent whole order granularity, bundle granularity, or product order item granularity, and so on. At this point, you are only defining the order components that OSM can use to decompose order items to. You configure the actual decomposition behaviors and conditions with other Design Studio orchestration entities such as fulfillment patterns and orchestration decomposition rules.

See "Modeling Orchestration Plans" for more information.

Modeling COM Orchestration Fulfillment Patterns and Fulfillment Modes

You must determine what fulfillment patterns each order item should decompose to and what action you want to specify on the overall order. You model the actions (such as deliver, technical service qualification, or cancel) as fulfillment modes. Each fulfillment pattern can have more than one fulfillment mode. When an order item decomposes to a fulfillment pattern, the fulfillment pattern generates a different orchestration plan based on the action defined on the order. The action corresponds to the fulfillment mode associated to the fulfillment pattern.

OSM fulfillment patterns define (among other things) the first stage of order item decomposition. In fulfillment patterns, you can specify order item decomposition conditions for whether a specific order item decomposes to an order component. Typically fulfillment patterns contain all order components that specify functions.

In a conceptual model project, you map conceptual model product specifications which define offers, bundles, and products to conceptual model fulfillment patterns. OSM fulfillment patterns realize these conceptual model fulfillment patterns. When you build an OSM cartridge, OSM generates a sample XML file. The sample XML file contains the product-to-fulfillment pattern mappings. You can reference those mappings using an order item property from the OSM order item specification. The order item property defines XQuery logic that determines how each order item decomposes to a fulfillment pattern.

For example, an order might contain the following order items:

• Five decompose to a broaband fulfillment pattern.

• Four decompose to a VoIP fulfillment pattern.

• One decomposes to an Email fulfillment pattern.

At run-time, OSM evaluates the function decomposition stage first which contains the function order component. This evaluation determines whether order items decompose to each function order component based on the conditions (if any exist) specified in the fulfillment pattern.

OSM next evaluates how order items decompose to the system and granularity order components in the system and granularity stages using on orchestration decomposition rules. These decomposition rules define how order items decompose from function order components to system order component, and from function order components to granularity order components. All order decomposition rules relating to system order components in the system decomposition stage are evaluated. Then those order decomposition rules relating to the granularity order components in the granularity stage are evaluated.

After OSM evaluates each stage for each order item in the fulfillment patterns they are associated with, OSM generates run-time order components. These run time order components are the sum of the order components that each order item decomposes to. For example, order item A can decomposed to functionA-systemA-granularityA. This sequence of order components constitutes a single run-time order component.

However, consider a scenario where the order items in an order decompose to more than one fulfillment pattern. If fulfillment pattern A generates the same run-time order component as fulfillment pattern B, then OSM generates only one run-time order component. This run-time order component processes the order items from both fulfillment pattern A and B.

some decomposition sequences of the three different fulfillment patterns end up being identical, then only one run-time order component is created that runs a process for all order items.

Figure 1-3 shows a order item decomposition run-time sequence with the BroadBand order item bundle.

The first stage of order item decomposition uses the broadband fulfillment pattern which defines decomposition rules for each function order component. The second stage uses decomposition rules from each function to each system order component. The third stage uses decomposition rules from each system to each granularity order component. OSM generates the resulting run-time order components based on this sequence. Each unique decomposition flow generates a new executable order component.

Figure 1-3 Sample Run-Time Order Item Decomposition Sequence

Those generated in Figure 1-3 are:

• SyncCustomer/BillingSystemResidential/OrderGranularity

• InitiateBilling/BillingSystemResidential/OrderGranularity

• Provisioning/OSMSOMSystem/OrderGranularity

• FulfillBilling/BillingSystemResidential/BundleGranularity

In this scenario, the decomposition rules to the billing system business component and offer granularity component rejects all order items. The rejection is based on a condition that specifies that only order items from business customers can be included. All order billing related components are directed to the billing system residential as opposed to the billing system business order component.

In addition, the VoIP bundle order items and all its child order items decompose to another fulfillment pattern not represented in Figure 1-3. It is important to note that an orchestration plan that contains multiple fulfillment patterns may generate identical run-time order components if some of the functions, systems, and granularity component decomposition flows are the same. For example, the broadband internet and VoIP fulfillment patterns may each specify the same SyncCustomer and InitiateBilling functions with the same systems and granularity components. In such a case, OSM generates only one run-time component to which the order items from each fulfillment pattern decomposes to. However, it may be that separate provisioning and billing components are required for each fulfillment pattern. For example, you may want a separate provisioning component for the broadband order items. When the provisioning component completes, the billing component runs. The billing system then begins charging for broadband service immediately. The VoIP related order items might decompose to separate provisioning and billing order components that only start when the provisioning component for broadband completes. This decomposition pattern may be appropriate based on the fact that the VoIP related order items functionally depend on the broadband order items and also take much longer to fulfill than the broadband order items. In this scenario, the CSP does not need to wait for the VoIP order items to fulfill before beginning to charge for the broadband service.

Similar decomposition scenarios may be important when considering the date when the customer wants a particular service fulfilled. For example, a customer may request an IPTV and VoIP bundle that are normally fulfilled within the same provisioning and billing functions. But because the customer requests a start date for the IPTV service that is much later than the one specified for the VoIP service, then these two order item bundles must decompose to separate provisioning and billing order components.

See the following sections for more information:

• Modeling Orchestration Plans

• Modeling Order Scheduling

Modeling COM Order Transformation Manager

You should determine whether you want to use the order transformation manager (OTM) with the calculate service order (CSO) conceptual model provider function. OTM with CSO transforms products, bundles, and offer order items and actions into CFS order items and actions. The run-time order component creates and sends a service order to OSM SOM or some other provisioning system. The OTM functionality provides a way to decouple the commercial layer from the service layer.

Figure 1-4 shows a sample run-time order transformation with the design-time conceptual model entity associations. This example has the following run-time flow that incorporates design time data from conceptual model entities:

1. OTM triggers either when the orchestration process begins to design an orchestration plan or from within the process associated with the provision function in a transformation task. OTM can process data elements for product entities in the conceptual model. OTM can process data elements only if order parameter bindings are created. The order parameter bindings are between product data in the conceptual model and an order item property in the order item specification. The order item property must be designated as a dynamic parameter that defines a data structure.

   OTM can only process conceptual model product entity data elements on the order if order parameter bindings (conceptual model association A) have been created between conceptual model product data and an order item specification order item property designated as a data structure definition dynamic parameter.

2. OSM sends the input product order items to OTM. In order for OSM to do this, the conceptual model CSO provider function must be associated with the provision function order component at design-time (conceptual model association B).

3. OTM sends the order data to a transformation sequence. In order for OTM to map to the appropriate transformation sequence, OTM must also be associated with the conceptual model CSO provider function and a conceptual model domain (conceptual model association C). The domain is a repository of all the conceptual model products possible for the order item. In this case, the domain is the BB Email Domain for broadband and Email products. Other domains could be VoIP, mobile, cable and so on.

4. The transformation sequence goes through a series of stages. The stages use mapping rules to map the input order item data to output order item data. The stages also define whether the data is primary (which creates a new order item) or auxiliary (which augments the data on a new order item). The mapping rules must also be associated with the same CSO provider function and domain as OTM (conceptual model association C). For example:

   • Primary Stage: Transforms product order items and actions into transformed order items and actions. At the primary stage, product order items create new transformed customer service-facing order items. In this example, the primary product specification is BB_PS which maps to the BB Internet Access customer-facing service specification.

   • Child Stage: Transforms all child order items and actions and any of their child order items and actions, and so on, into data that augments the order items created in the primary stage. In this example, the child order items of BB_PS are BB_Bandwidth, Firewall, and Router.

   • Sibling Stage: Transforms all sibling order items and actions into data that augments the order items created in the primary stage. In this example, a sibling order item of BB_PS is Email.

   • Ancestor Stage: Transforms all ancestor order items and actions and any of their ancestor order items and actions, and so on, into data that augments the order items created in the primary stage. In this example, the ancestor order item of BB_PS is BB_Email_PS.

   Figure 1-4 Sample Run-Time Order Transformation with Conceptual Model Associations

   
   

5. The transformation sequence includes the resulting order items into the provision function order component. The provisioning function order component runs a process that creates and sends a service order to OSM SOM. The service order includes the transformed service order items. The product order items are not required in the service order because all necessary data contained in the product order items are now consolidated into the service order item.

See the following sections for more information:

• Modeling the Order Transformation Manager

• Modeling OTM With Calculate Service Order

• Modeling OTM Without Calculate Service Order

Modeling COM Orchestration Dependencies

You need to determine what dependencies exist between executable order components. These dependencies are called orchestration dependencies. You typically define all orchestration dependencies using fulfillment patterns for function order components. However, you can also specify dependencies between other order components using orchestration dependency rules. In addition, you can specify when order components can start based on dates provided by customers for when they want a service to begin.

For example, the tasks specified in "About the OSM Solution Modeling Process" for OSM COM may need to be fulfilled in the following order (see Figure 1-5):

1. The Sync Customer and Initiate Billing function that are shared between both fulfillment patterns occur sequentially. Order items from both broadband and VoIP fulfillment patterns decomposed into identical order components. All order items in the Sync Customer function must complete before the Initiate Billing Function can continue.

2. The Initiate Billing function must complete before the Provision Function can start processing the broadband order items and the second Provision Function can start processing the VoIP order items. In addition, the second provision function must wait until the first provision function completes because VoIP is functionally dependent on broadband and because the VoIP service takes longer to fulfill than the broadband service.

3. The Fulfill Billing function for the broadband order items starts after the Provision function for the broadband order items completes.

4. The Fulfill Billing function for the VoIP order items starts after the Provision function for the VoIP order items completes.

Figure 1-5 Example Dependency Between Fulfillment Pattern Order Items

Having separate Provision functions means that OSM COM sends multiple service orders to OSM SOM. Other factors can also impact order component creation and dependencies such as the requested delivery date for each service.

See the following sections for more information:

• Modeling Orchestration Plans

• Modeling Order Scheduling

Modeling COM Processes and Tasks

What process flow of sequential or parallel manual and automated tasks are required when interacting with target systems for each functional component.

For example, each function may have a few automated tasks that perform different functions, such as sending messages to an external system, receiving back and processing a response from external systems, or manipulating data received from previously completed tasks. There may also be manual tasks where an operator is required to input data directly into the Order Management Task web client. The manual tasks may also make use of behaviors that effect how the data is organized, displayed, or retrieved in the OSM Task web client and in the Order Management web client.

Figure 1-6 shows an OSM process that includes a subprocess with an automated task and automation plug-in sender. An order level notification updates the status of order items then notifies the CRM of the status change. The automated task then transitions to another task that sends a service order to the OSM SOM system. The server order includes all the order items required to design and assign the products and services that the customer has requested.

Figure 1-6 Example Task Processing

See the following sections for more information:

• Modeling Processes and Tasks

• Modeling Behaviors

• Modeling Data for Tasks

Modeling COM Fallout Scenarios

You must determine:

• What fallout management scenarios can be anticipated.

• How fallout scenarios can be detected.

• How relevant parties or systems can be notified of problems.

• What recovery processes can be implemented.

For example, you should anticipate fallout around network connectivity from time to time. External systems may fail to return responses or fail to accept messages. In such cases you can configure automated tasks to transition to fallout a execution mode. Failed messages generated by automation plug-ins can revert to an error queue. You can also configure jeopardy notifications when messages are taking too long to return. The jeopardy notification can generate warning messages to fallout personnel so they can manual investigate the problem on the external fulfillment system or in OSM.

See the following sections for more information:

• Modeling Fallout

• Modeling Behaviors

• Modeling Processes and Tasks

• Modeling Jeopardy and Notifications

Modeling COM Fulfillment States

You must determine what kind of order and order item fulfillment states you need to configure. Fulfillment states track the overall status of an order and each order item based on status messages received from external systems. You also need to consider what notification messages you want to send to interested parties or systems as the order progresses.

For example, Figure 1-7 shows external fulfillment state change messages from the billing system and the OSM SOM system returning to the OSM COM system.

The hierarchical structure of the order defined in the order item specification is as follows:

BroadBandOrder (target order)
    BroadBand Service (Bundle)
        Promotion (Product)
        BroadBand (Product)
        Bandwidth (Product)
        Firewall (Product)
        Email (Product)

1. The billing function is a generic order component, but could represent any of the billing functions listed in "About the OSM Solution Modeling Process" for OSM COM. After the billing function sends a message to the billing system, the billing system sends three status messages back to OSM COM as the billing system processes the Promotion, Broadband, and Email order item. Two of the external fulfillment state messages, billing begin and billing in progress, map to the OSM COM in progress billing fulfillment state. The billing system sends these messages to confirm that it has received the message from OSM with the order items and then to confirm that it has begun to process the messages. When the billing system finished processing all order items, it sends the billing end external fulfillment state that maps to the complete billing fulfillment state.

2. The provision function has a similar exchange of messages with the OSM SOM system for the broadband, bandwidth, firewall, and email order items.

   Figure 1-7 Example Fulfillment States

   
   

3. When the order items first begin processing in the billing function component, Rule 1 evaluates to true when the billing system sends the billing begin and billing in progress external fulfillment state messages that map to the In Progress Billing fulfillment state for the billing order component. This causes the order items included in the billing function component to have a composite fulfillment state of in progress.

4. When the billing system completes and sends the billing end message which maps to the Complete Billing fulfillment state for the function component, the Broadband and Email order items continue processing in the provision function order component while the Promotion order component does not. Promotion did not decompose to the provision function and is therefore fully complete. Rule 1 still evaluates to true for BroadBand and Email, but Rule 1 evaluates to false for Promotion. Rule 2 evaluates to true for Promotion, causing its order item composite fulfillment state to move to Complete.

5. When Rule 1 and Rule 2 make any change to the state in an order item, they also evaluate the parent order item, which is the BroadBand Service bundle order item. Although Promotion is now complete, the BroadBand Service remains in the In Progress state until the other child order items complete.

6. When the remaining order items complete in the provision function, Rule 1 evaluates to false and Rule 2 evaluates to true for the order component. Rule 2 then changes the composite order item fulfillment states for all remaining order items to complete. Because of this change, the parent BroadBand Service order item also changes to complete because all its child order items are now complete.

7. Because of this change in BroadBand Service, which is a root level order item, the order fulfillment state Rule 3 evaluates to false because there are no longer any in progress order items at the root level. Rule 4 evaluates to true because all order items at the root level are now complete.

8. An order data change notification triggers whenever an order or order item composite fulfillment state changes that sends messages to the CRM to report the changes.

Figure 1-7 shows only in progress and complete billing states at both the order item and the order level. Many other external order fulfillment states, order item fulfillment states, and order states are possible, such as failure states, cancelation states, and so on. Each of these would also have a corresponding order item fulfillment state composition rule and order fulfillment state composition rule.

See the following sections for more information:

• Modeling Fulfillment States and Processing States

• Modeling Jeopardy and Notifications

Modeling COM Processing States

Processing states are similar to fulfillment states in that you can configure automated tasks to trigger order component order item processing states based on messages received from external fulfillment systems. The main difference is that the order component order item processing states come from a predefined list that OSM provides. OSM automatically aggregates order component order item processing states across all order components processing the order item into a single order item processing state that is visible in the Order Management web client. OSM also propagates child order item processing states to parent order items. The only work necessary to model processing states is to map incoming status message from external fulfillment systems to order component order item processing states. You can even map the same message to both order component order item processing states and to external fulfillment states.

For example, the following shows how the Email product is successfully processed in two order components, but the third order components returns a failure order component order item processing state, causing the Email product to display the Partially Failed order item processing state, which in turn caused the parent and grandparent order items (Brilliant Broadband and Broadband Service) to also display the Partially Failed order item processing state.

Brilliant Broadband (Offer) ----- Partially Failed
    BroadBand Service (Bundle) -- Partially Failed
        Promotion (Product) ----- Completed
        BroadBand (Product)------ Completed
        Bandwidth (Product)------ Completed
        Firewall (Product) ------ Completed
        Email (Product) --------- Partially Failed  ---- OCOI1 - Completed
                                                    ---- OCOI2 - Completed
                                                    ---- OCOI3 - Failed

The Order Management web client tracks Normal, Warning, and Failure counts of order item processing states (see Figure 1-8).

Figure 1-8 Order Item Processing States in the Order Management Web Client

See the following sections for more information:

• Modeling Fulfillment States and Processing States

• Modeling Jeopardy and Notifications

Modeling Change Order Management for COM

You need to determine if you want to enable change order management, and if you do, what change order management scenarios you want to support.

Do you need a point of no return where the order cannot be changed? For example, you can configure a point of no return that is tied to the provisioning function that generates a service order to be enforced whenever that order component receives a fulfillment state update of Complete (assuming you have configured the order component with such a fulfillment state update). You can also tie a point of no return directly to the any order life-cycle policy transition to the Amending state, such as the Submit Amendment transition from the In Progress state to the Amending state.

If a revision order arrives, what behavior do you want each tasks to exhibit? Do you want the task to undo, redo, or undo then redo? For example, do you want to configure the automated task responsible for sending the service order to OSM in the SOM role to trigger an automation plug-in that sends a revision order to OSM SOM that undoes the previously sent service order whether it is complete or still in progress? Or do you want the task to redo the previously sent service order as a revision order and allow SOM to perform change order management functions?

See the following sections for more information:

• Modeling Changes to Orders

• Modeling Processes and Tasks

Cartridge Management Considerations for COM

What kinds of cartridge management scenarios you want to plan for in advance, such as the impact of upgrading cartridge functionality, how such upgrades impact run-time orders, how best to structure cartridges to minimize the impact of such changes, and so on.

See "Managing OSM Solution Cartridges" for more information.

Modeling SOM Order and Order Recognition Requirements

You must determine what kind of orders you need to model in OSM SOM, what order life-cycle states and state transitions the orders have, and who has permissions to do various tasks in fulfilling the order.

At this point, it is important to understand that the SOM order is a child of the COM parent order and must report back to the COM order component that generated the service order. In the example provided in "Modeling COM Orchestration Fulfillment Patterns and Fulfillment Modes", the order component that generated the service order to SOM is a task that is part of a process triggered by the Provisioning/OSMSOMSystem/OrderGranularity run-time order component. Any notification from OSM SOM relating to the service order would return back to this task.

Depending on how you have modeled your COM solution, OSM SOM may receive more than one service order. For example, you may want to configure OSM COM to send a separate service order to fulfill the broadband internet CFS. When that service order completes, OSM COM may send a second service order with a VoIP CFS.

You may want to create separate target orders for each CFS or one generic target order that receives all service orders. In the SOM context, OSM does not generally need separate target orders because most of the work is accomplished within the SRM system that OSM SOM communicates with and any dependencies between CFSs are enforced in OSM COM.

Likewise, if you have only one target order at the SOM level, then you need only one order recognition rule that maps incoming service orders to this target order.

See the following sections for more information:

• Modeling Orders and Permissions

• Modeling Order Life-Cycle Policies

• Modeling Order Recognition

SOM Data Modeling Considerations

Answer the following questions to determine what corresponding order data you need to model on the OSM order to capture the incoming order data:

• What data is required to complete an order?

• What data do the tasks require? For example, what data is required on each interaction with the SRM system? What format to OSM TOM require for the technical order that OSM SOM sends?

• What data is not required on the service order, but is required by the technical order that is derived from the customer order?

• Does the incoming order include all of the data needed for the order? If not, you can use data providers in your tasks to get the data from some other source. Typically SOM is only responsible for passing on CFSs created in COM to the SRM system. However, it is possible that other data may be required that does not come from the SRM system.

• Which nodes on the service order contain order item information that represents the CFSs on the order?

• What order item parameters represent the name of the CFS order item?

• If the order items are hierarchical and what data elements specify the parent child relationship between each order item? Typically service orders do not require a hierarchy.

• If the order items must be delivered at different times and dates, what data element contains the requested delivery date?

• What data element specifies the action that must be performed on the CFS order item during the fulfillment process? For example, add, change, delete, move, and so on.

• What data element specifies the overall purpose of the order, such as deliver, cancel or technical service qualification (TSQ)?

See the following sections for more information:

• Modeling Order Data

• Modeling Orders and Permissions

• Modeling Behaviors

Modeling SOM Orchestration Order Items and Bindings Conceptual Model Parameters

You must determine what nodes in the incoming order you want to designate as order items containing CFSs. What data in the order items you want to use for specific orchestration functions, such as the actions you want OSM to perform on those order items, the requested delivery date when the order item actions need to occur, what CFS the order item represents that OSM then uses to map the order item to specific fulfillment patterns, and so on.

You can also use order item parameter bindings to bind conceptual model CFSs and the parameters defined for them to a OSM SOM order item specifications. This allows you to have strongly typed parameters that you don't need to model within order item specifications. For example, Figure 1-1, "Sample Conceptual Model" defines the Broadband Internet Access CFS and the Email CFS. You can use order item parameter bindings to map these conceptual model product entities to order item specifications by configuring an order item for the order item recognition and an order item parameter as a dynamic parameter where the parameters are stored.

Order item parameter bindings in OSM SOM are important for validating the incoming CFSs generated from OSM COM, however OTM is not required in the OSM SOM role because the SRM system is typically responsible for transforming CFSs into RFSs, resources, and actions. OSM SOM sends the CFSs to the SRM system and receives back the actions on the resources. OSM SOM does not need order item parameter bindings on these actions because OSM TOM is responsible for validating these actions.

See "Modeling Orchestration Plans" for more information.

Modeling SOM Orchestration Order Item Decomposition

You need to decide what orchestration stages you want OSM to evaluate when decomposing CFS order items into order components. These order components typically designate functions, systems, and granularity.

Based on the previous sections, you should already have some knowledge of what the service order you are creating contains. Using this knowledge, you can provide answers to the following questions:

• What are the systems that OSM must communicate with? For example, OSM SOM typically communicates with an SRM system and OSM in the TOM role.

• What order items do each system require? For example, the SRM system requires CFS information and OSM in the TOM role requires technical actions.

• What are the business functions that each system must perform on these order items? For example, sending the CFSs to the SRM system, requesting the actions from the SRM system, and building the technical order that contains the actions for the OSM TOM system.

• How should OSM deliver this data for the functions to process? Does the function operate on the whole order, or does the function require a separate interaction per order item bundle on the order, or per order item?

Based on the answers you provide to these questions, can you begin to model order item decomposition stages.

Figure 1-1, "Sample Conceptual Model" defines the Broadband Internet Access CFS and the Email CFS. You can decompose these order items into function, system, and granularity order components in the same way you do in the COM (see "Modeling COM Orchestration Order Item Decomposition").

You must determine what high level tasks are involved in fulfilling customer orders at the OSM SOM level. You can define orchestration order components that correspond to the functions performed by these tasks that you can then add to the function stage (see Figure 1-2). See "About the OSM Solution Modeling Process" for a sample list of OSM SOM related tasks that can be modeled as function order components.

You must determine what kinds of OSS fulfillment systems you have at the OSM SOM level. You can define orchestration order components that correspond to these systems that you can then add to the system stage. As illustrated in Figure 1-1, "Sample Conceptual Model", the systems that normally interact with OSM SOM include one or more SRM systems that interact with inventory systems to design and assign services with their corresponding network resources.

You must also determine what kind of order granularity you need when fulfilling each function order components. At the SOM level, OSM typically passes on every CFS order items to the SRM system because CFSs are typically not hierarchically ordered. However, this all depends on how you model the overall solution.

For each of these options, you need to create an order component that OSM can use to decompose the order items to, such as whole order granularity, bundle granularity, or product order item granularity, and so on. At this point, you are only defining the order components that OSM can use to decompose order items to during order decomposition. You configure the actual decomposition behaviors and conditions with other Design Studio orchestration entities such as fulfillment patterns and orchestration decomposition rules.

See "Modeling Orchestration Plans" for more information.

Modeling SOM Orchestration Fulfillment Patterns and Fulfillment Modes

You must determine what fulfillment patterns each order item should decompose to and what action you want to specify on the overall order that you can model as fulfillment modes for the order, such as deliver, technical service qualification, or cancel.

In a conceptual model project, you map conceptual model CFSs to conceptual model fulfillment patterns. These conceptual model fulfillment patterns are realized by OSM SOM fulfillment patterns. When you build an OSM cartridge, OSM generates a sample XML file that contains all these CFS to fulfillment pattern mappings that you can reference using an OSM SOM order item specification order item property that defines XQuery logic that determines how each order item decomposes to what fulfillment pattern during run-time.

For example, OSM SOM may have a Broadband Internet Access CFS order item and the Email CFS order item that maps to a conceptual model fulfillment patter that is realized by an OSM SOM fulfillment pattern that specifies a function to send these CFSs to the SRM system so that the SRM system can perform the design and assign functionality. You can also create another function that requests the actions that must be included in a technical order, and a third function that creates, sends the technical order to OSM TOM, and a fourth function that completes the service order.

At run-time, OSM evaluates the function, system, and granularity stages in a similar way to OSM in the COM role (see "Modeling COM Orchestration Fulfillment Patterns and Fulfillment Modes"). The function, systems, and granularity stages might generate the following run-time order components:

• DesigningServiceFunction/SRMsystem/OrderGranularity

• PlanDeliveryFunction/SRMsystem/OrderGranularity

• CreateTechnicalOrderFunction/OSMTOMsystem/OrderGranularity

• CompleteFunction/SRMsystem/OrderGranularity

Modeling SOM Orchestration Dependencies

You must determine what dependencies exist between executable order components. These dependencies are called orchestration dependencies. You typically define all orchestration dependencies using fulfillment patterns for function order components, but you can also specify dependencies between system order components using orchestration dependency rules. In addition, you can specify when order components can start based on dates provided by customers for when they want a service to begin.

For example, the tasks specified in "About the OSM Solution Modeling Process" for OSM SOM may require that each function operate in the sequence specified in Figure 1-9.

Figure 1-9 Example Dependency Between Fulfillment Pattern Order Items

Because there is typically only one fulfillment pattern at in OSM SOM for fulfilling service orders, each component can run one after the other.

See the following sections for more information:

• Modeling Orchestration Plans

• Modeling Order Scheduling

Modeling SOM Processes and Tasks

You must determine what process flow of sequential or parallel manual and automated tasks are required when interacting with target systems for each functional component.

Tasks in OSM SOM typically involve sending the CFS order items required by the SRM system and receiving back the action from the SRM system. For example, the design service function would start a process that triggers an automated tasks with an automation plug-in sender instance that send builds and sends a message containing the CFS information to the SRM system in the format required by the SRM system API. When the SRM system completes, it sends a response back to OSM SOM that OSM SOM correlates back to the automated task to an automation plug-in automator that is waiting for a response message. The automation plug-in automator reviews the response message and determines that the SRM system completed its tasks successfully and then transitions the automated task to the completed state which also completes the DesigningServiceFunction/SRMsystem/OrderGranularity order component.

Each run-time order components with associated processes and tasks would perform similar exchanges.

See the following sections for more information:

• Modeling Processes and Tasks

• Modeling Behaviors

• Modeling Data for Tasks

Modeling SOM Fallout Scenarios

What fallout management scenarios can be anticipated, determine how they can be detected, how relevant parties or systems can be notified of the problem, and what recovery processes can be implemented.

For example, in addition to possible communication issues, you may anticipate the possibility that fallout may occur because OSM COM sends faulty or incomplete CFS information to OSM SOM, or the SRM system has somehow provided incorrect data to OSM SOM that may cause a fallout to occur in OSM TOM. You must carefully analyze when such issues can occur and develop fallout strategies to recover from such fallouts scenarios. In some cases, manual intervention may be required while in other cases, you may be able to model automatic fallout recovery capabilities.

See the following sections for more information:

• Modeling Fallout

• Modeling Behaviors

• Modeling Processes and Tasks

• Modeling Jeopardy and Notifications

Modeling SOM Fulfillment States

What kind of order and order item fulfillment states you need to configure to track the overall status of an order and each order item based on status messages received from external systems. You also need to consider what notification messages you want to send to interested parties or systems as the order progresses.

For example, you can map messages from the SRM system and the OSM TOM system returning as these systems process messages sent by various order components to external fulfillment state in the OSM SOM system. These external fulfillment states can represent the result of various interactions between OSM SOM and these systems on each CFS order item that OSM SOM then aggregates into order item and order-level fulfillment states based on order and order item fulfillment sate composition rule sets.

See the following sections for more information:

• Modeling Fulfillment States and Processing States

• Modeling Jeopardy and Notifications

Modeling SOM Processing States

You can track the state of order items by mapping responses from the SRM system and OSM TOM to order item processing states. You must decide what messages correspond to which predefine order component order item processing state that OSM provides. OSM then aggregates these order component order item processing states for each order item into an overall order item processing state. You may decide to use warning and failure order item processing states to trigger jeopardy notifications from OSM SOM to OSM COM or from OSM SOM to a fallout personnel. In many cases, you can also use the same messages from external systems to trigger external fulfillment state changes.

See the following sections for more information:

• Modeling Fulfillment States and Processing States

• Modeling Jeopardy and Notifications

Modeling Change Order Management for SOM

You need to determine if you want to enable change order management, and if you do, what change order management scenarios you want OSM SOM to support.

You must consider change order management based on end-to-end scenarios that span OSM COM, SOM, and TOM. For example, if you enable OSM COM to send a revision order through to OSM SOM from the OSM COM provision function then you must decide what compensation OSM SOM must undertake to implement the changes in the revision order. For example, you might consider some of the following question:

• Is there a point of no return where you do not want OSM SOM to accept any new revision orders from the OSM COM provision function? For example, you may want to configure a point of no return that is associated with when the SRM system completes its design and assign functions based on an external fulfillment state change. This would effectively mean that OSM TOM should not receive revision orders from OSM SOM stemming from changes coming from OSM COM service orders. Or you may decide that there should not be any point of no return configured in OSM SOM.

• It may be that the SRM system that you are communicating with does not have the capability of accepting revisions to CFSs sent by the original interaction between OSM SOM and the SRM system, but can only accept cancelation requests. In which case OSM SOM must configure the automation task to completely undo the original request then redo it with using the new CFS information.

• It may be that you want to configure OSM TOM to accept revision orders, in which case, you can configure OSM SOM to redo the task that sends the technical order to OSM TOM such that is sends a versioned revision order.

See the following sections for more information:

• Modeling Changes to Orders

• Modeling Processes and Tasks

Cartridge Management Considerations for SOM

What kinds of cartridge management scenarios you want to plan for in advance, such as the impact of upgrading cartridge functionality, how such upgrades impact run-time orders, how best to structure cartridges to minimize the impact of such changes, and so on.

See "Managing OSM Solution Cartridges" for more information.

Modeling TOM Order and Order Recognition Requirements

You must determine what kind of orders you need to model in OSM TOM, what order life-cycle states and state transitions the orders have, and who has permissions to do various tasks in fulfilling the order.

At this point, it is important to understand that the TOM order is a child of the SOM parent order and must report back to the SOM order component that generated the technical order. In the example provided in "Modeling COM Orchestration Fulfillment Patterns and Fulfillment Modes", the order component that generated the service order to TOM is a task that is part of a process triggered by the CreateTechnicalOrderFunction/OSMTOMsystem/OrderGranularity run-time order component. Any notification from OSM TOM relating to the service order would return back to this task.

Depending on how you have modeled your SOM solution, OSM TOM may receive more than one technical order. For example, you may want to configure OSM COM to send a separate service orders to fulfill the broadband internet CFS and another that fulfills a VoIP CFS. OSM SOM would process these orders separately. OSM SOM sends the service order to the SRM system to generate technical actions that OSM SOM sends to OSM TOM as a technical order. Therefore, OSM TOM would receive two separate technical orders to fulfill resource actions on the original sales order sent to OSM COM.

Like OSM COM, you may want to create separate target orders for each technical order based on the different domains they interact with (broadband, VoIP, Mobile, and so on), or one generic target order that receives all technical orders.

If you create individual order types, you also need to create corresponding order recognition rules that match incoming orders to the target order. You can consider the following approaches when modeling order recognition rules for OSM TOM:

• You would typically not have multiple OSM SOM instance interacting with the same OSM TOM instance using different message format, but usually each OSM SOM instance would have its own OSM TOM instance. This means it is unlikely that you would need multiple order recognition rules pointing to the same OSM TOM instance target order.

• If you have multiple order target orders based on domain groupings, you must create a separate order recognition rule for each target order type.

• If you have one OSM instance operating in more than one role, for example, if the same system is operating in both the SOM and the TOM role, you need to configure an order recognition rule that points to a corresponding target order for each role.

• If you have one OSM SOM instance and one OSM TOM instance, then you typically need only one order recognition rule that points to one target order.

You need to determine what corresponding order recognition rules you need to model in OSM to recognize, validate, prioritize, and transform order data from sales orders into a matching OSM target order. You must map incoming order data to the data defined in the creation task of the target order.

See the following sections for more information:

• Modeling Orders and Permissions

• Modeling Order Life-Cycle Policies

• Modeling Order Recognition

TOM Data Modeling Considerations

Answer the following questions to determine what corresponding order data you need to model on the OSM order to capture the incoming order data:

• What data is required to complete an order?

• What data do the tasks require? For example, what data is required on each interaction with the Activation, the PWG, the WFM, and the SCM systems? What message format do these interactions require?

• Which data is not required on the technical order, but is required by the different fulfillment systems that OSM TOM interacts with?

• Does the incoming order include all of the data needed for the order? If not, you can use data providers in your tasks to get the data from some other source.

• Which nodes on the service order contain order item information that represents the actions on the order?

• What order item parameters represent the name of the action order item?

• If the order items are hierarchical what data elements specify the parent child relationship between each order item? For example, you may want to specify a hierarchy between an overall parent action with related child order items, such as CreateDSL_CPE with children order items that decompose to a shipping component, another to a workforce management component, and a third for the activation component.

• If the order items must be delivered at different times and dates, what data element contains the requested delivery date?

• What data element specifies the action that must be performed on the order item during the fulfillment process? For example, add, change, delete, move, and so on.

• What data element specifies the overall purpose of the order, such as deliver, cancel or technical service qualification (TSQ)?

See the following sections for more information:

• Modeling Order Data

• Modeling Orders and Permissions

• Modeling Behaviors

Modeling TOM Orchestration Order Items and Bindings Conceptual Model Parameters

You must determine what nodes in the incoming order you want to designate as order items containing actions on resources and RFSs. What data in the order items you want to use for specific orchestration functions, such as the actions you want OSM to perform on those order items, the requested delivery date when the order item actions need to occur, what CFS the order item represents that OSM then uses to map the order item to specific fulfillment patterns, and so on.

You can also use order item parameter bindings to bind conceptual model resources and RFSs with their corresponding conceptual model actions and the parameters to a OSM TOM order item specifications. This allows you to have strongly typed parameters that you don't need to model within order item specifications. For example, Figure 1-1, "Sample Conceptual Model" defines the DSL resource-facing service that can optionally be fulfilled using the ADSL or VDSL interface, that also requires a DSL customer premise equipment (CPE). You can use order item parameter bindings to map these conceptual model resources, RFS entities, the actions associated with them and their data to order item specifications by configuring an order item property for the order item recognition and an order item property as a dynamic parameter where the parameters are stored.

Order item parameter bindings in OSM TOM are important for validating the incoming resource and RFS data generated from the SRM system and sent to OSM TOM from OSM SOM. Transformation is not typically required in OSM TOM because the SRM system that produced the technical actions should have already used the correct format.

See "Modeling Orchestration Plans" for more information.

Modeling TOM Orchestration Order Item Decomposition

You need to decide what orchestration stages you want OSM to evaluate when decomposing resources and RFS order items into order components. These order components typically designate functions, systems, and granularity.

Based on the previous sections, you should already have some knowledge of what the service order you are creating contains. Using this knowledge, you can provide answers to the following questions:

• What are the systems that OSM must communicate with? For example, OSM TOM typically communicates with shipping, activation, WFM, and SCM systems.

• What order items do each system require? For example, the activation system may require the DSL RFS, the DSL CPE resource, and the Email account resource, the PGW may require the local loop resource, and the WFM and SCM systems may require the DSL CPE.

• What are the business functions that each system must perform on these order items? For example, the SCM must ship the DSL CPE, the WFM system must dispatch personnel to install the CPE, the PGW must configure the local loop, and the activation system must activate the DSL access node, the DSL CPE, and the Email account.

• How should OSM deliver this data for the functions to process? Does the function operate on the whole order, or does the function require a separate interaction per order item parent child order item combination on the order, or per order item?

Based on the answers you provide to these questions, can you begin to model order item decomposition stages.

Figure 1-1, "Sample Conceptual Model" defines the multiple resources and RFS entities. You can decompose these order items into function, system, and granularity order components in the same way you do in the COM and SOM (see "Modeling COM Orchestration Order Item Decomposition").

You must determine what high-level tasks are involved in fulfilling customer orders at the OSM TOM level. You can define orchestration order components that correspond to the functions performed by these tasks that you can then add to the function stage (see Figure 1-2). See "About the OSM Solution Modeling Process" for a sample list of OSM TOM related tasks that can be modeled as function order components.

You must determine what kinds of OSS fulfillment systems you have at the OSM TOM level. You can define orchestration order components that correspond to these systems that you can then add to the system stage. As illustrated in Figure 1-1, "Sample Conceptual Model", the systems that normally interact with OSM SOM include activation, PGW, shipping, WFM, and SCM systems.

You must also determine what kind of order granularity you need when fulfilling each function order components. For example, at the TOM level, you might configure OSM to pass the whole order to the activation and completion function but requires order item specific granularity for the shipping, WFM, and SCM related functions.

For each of these options, you need to create an order component that OSM can use to decompose the order items to, such as whole order granularity or product order item granularity, and so on. At this point, you are only defining the order components that OSM can use to decompose order items to during order decomposition. You configure the actual decomposition behaviors and conditions with other Design Studio orchestration entities such as fulfillment patterns and orchestration decomposition rules.

See "Modeling Orchestration Plans" for more information.

Modeling TOM Orchestration Fulfillment Patterns and Fulfillment Modes

You must determine what fulfillment patterns each order item should decompose to and what action you want to specify on the overall order that you can model as fulfillment modes for the order, such as deliver, technical service qualification, or cancel.

In a conceptual model project, you map conceptual model resource and RFSs to conceptual model fulfillment patterns. These resources also specify the conceptual model actions that fulfill them. For example, the AAA_Account may be associated with the ActivateAAA_Account, AlterAAA_Acount, and DeactivateAAA_Account actions. In the conceptual model, you must also specify what realizes these actions. In this case these actions would be realized by an activation system, such as Oracle Communications ASAP, and more specifically, by ASAP service actions. Other resources would be realized by other systems and action types in a similar way. However, the information important to OSM in term of order item decomposition, are the resources and RFSs that contain these actions.

When you build an OSM cartridge, OSM generates a sample XML file that contains all these resource and RFS to fulfillment pattern mappings that you can reference using an OSM TOM order item specification order item property that defines XQuery logic that determines how each order item decomposes to what fulfillment pattern during run-time.

For example, an technical order to OSM TOM may have an Email_Account resource order item that maps to a conceptual model fulfillment patter that is realized by an OSM TOM fulfillment pattern. The OSM TOM fulfillment pattern would in turn decompose the Email_Account order item into the Activation functions because there is a condition on the activation order component within the fulfillment pattern that only allows order items to decompose to that order component that contain an order item property with a value of Activation. All other functions order components would also have conditions such that only order items destined for the systems the function order components are associated with can decompose to them.

At run-time, OSM evaluates the function, system, and granularity stages in a similar way to OSM in the COM role (see "Modeling COM Orchestration Fulfillment Patterns and Fulfillment Modes"). The function, systems, and granularity stages might generate the following run-time order components with associated resource and RFS order items and the actions they contain:

• ShipFunction/SCMsystem/OrderItemGranularity

• InstallFunction/WFMsystem/OrderItemGranularity

• ConfigureLocalLoopFunction/PGWsystem/OrderItemGranularity

• ActivationFunction/Activationsystem/OrderGranularity

• CompleteTechnicalFunction/SRMsystem/OrderGranularity

Modeling TOM Orchestration Dependencies

You must determine what dependencies exist between executable order components. These dependencies are called orchestration dependencies. You typically define all orchestration dependencies using fulfillment patterns for function order components, but you can also specify dependencies between system order components using orchestration dependency rules. In addition, you can specify when order components can start based on dates provided by customers for when they want a service to begin.

For example, the tasks specified in "About the OSM Solution Modeling Process" for OSM TOM may require that each function operate in the sequence specified in Figure 1-9. The ship function and the install function must complete before the activation function can start. In addition, the activation function is dependent on the configure local loop function that communicates with the PGW. The complete function has dependencies to the install and activation function and does not start until those functions have completed.

Figure 1-10 Example OSM TOM Dependencies

These dependencies make sense when you understand what each function is doing. For example, the activation function cannot activate the service until the DSL CPE has been shipped to the customer and the CPE has been configured properly. In addition, the activation function requires that the third-party company that owns the local loop configure this resource for the CSP's customer. It is only after these dependencies have been meet that the activation function can configure the network resources that deliver the service to the customer.

See the following sections for more information:

• Modeling Orchestration Plans

• Modeling Order Scheduling

Modeling TOM Processes and Tasks

You must determine what process flow of sequential or parallel manual and automated tasks are required when interacting with target systems for each functional component.

Tasks in OSM TOM typically involve sending resource and RFS order item actions to the SCM, WFM, PGW, and activation systems and receiving back the responses from these systems. You must careful analyze the API requirements for the interfaces to each system and model the data on the tasks to meet these requirements for each interaction with these systems. You also model automated tasks with automation plug-in senders that build and send messages to these systems containing the actions each external system is to fulfill. When the systems complete their work, they send responses back to OSM TOM that OSM TOM correlates back to the automated task to an automation plug-in automator that is waiting for a response message. You must develop to so that the automation plug-in automator can review the response message and determines that the system completed its tasks successfully (or whether some problem occurred) and then transitions the automated task to the completed state (or a fallout execution mode) which also completes the order component to the task belonged to.

OSM also provides a specialized automated task for communicating service requests to Oracle Communications ASAP product or the Oracle Communications IP Service Activator product. You can use this task to define the relationship between OSM task data and ASAP and IP Service Activator service actions.

See the following sections for more information:

• Modeling Processes and Tasks

• Modeling Behaviors

• Modeling Data for Tasks

Modeling TOM Fallout Scenarios

What fallout management scenarios can be anticipated, determine how they can be detected, how relevant parties or systems can be notified of the problem, and what recovery processes can be implemented.

For example, fallout scenarios may occur within the external fulfillment systems the OSM TOM communicates for a variety of reasons. For example, there may be an outage in one of the network elements that the activation system is working with, or a package sent from the SCM containing the router may have been lost or broken during delivery. Typically, many of these problems can be resolved directly in the external system, however, you may want the tasks communicate with these external systems to trigger jeopardy notifications informing upstream systems of the delay so that the upstream systems can communicate the delay back to the customer who requested the service. You must carefully analyze as many of these fallout scenarios as you can and develop fallout strategies to recover from such scenarios. In some cases, manual intervention may be required while in other cases, you may be able to model automatic fallout recovery capabilities.

See the following sections for more information:

• Modeling Fallout

• Modeling Behaviors

• Modeling Processes and Tasks

• Modeling Jeopardy and Notifications

Modeling TOM Fulfillment States

What kind of order and order item fulfillment states you need to configure to track the overall status of an order and each order item based on status messages received from external systems. You also need to consider what notification messages you want to send to interested parties or systems as the order progresses.

For example, you can map messages from the SCM, WFM, PGW, and activation systems returning as these systems process messages sent by various order components to external fulfillment state in the OSM TOM system. These external fulfillment states can represent the result of various interactions between OSM TOM and these systems on the actions contained on each resource and RFS order item that OSM TOM then aggregates into order item and order-level fulfillment states based on order and order item fulfillment sate composition rule sets.

See the following sections for more information:

• Modeling Fulfillment States and Processing States

• Modeling Jeopardy and Notifications

Modeling TOM Processing States

You can track the state of order items by mapping responses from the SCM, WFM, PGW, and activation systems to resource and RFS order item processing states. You must decide what messages correspond to which predefine order component order item processing state that OSM provides. OSM then aggregates these order component order item processing states for each order item into an overall order item processing state. You may decide to use warning and failure order item processing states to trigger jeopardy notifications from OSM TOM to OSM SOM or from OSM TOM to fallout personnel. In many cases, you can also use the same messages from external systems to trigger external fulfillment state changes.

See the following sections for more information:

• Modeling Fulfillment States and Processing States

• Modeling Jeopardy and Notifications

Modeling Change Order Management for TOM

You need to determine if you want to enable change order management, and if you do, what change order management scenarios you want OSM TOM to support.

You must consider change order management based on end-to-end scenarios that span OSM COM, SOM, and TOM. For example, if you enable OSM SOM to send a revision order through to OSM TOM from the OSM SOM Create Technical Order function then you must decide what compensation OSM TOM must undertake to implement the changes in the revision order. For example, you might consider some of the following question:

• Is there a point of no return where you do not want OSM TOM to accept any new revision orders from the OSM SOM Create Technical Order function? For example, you may want to configure a point of no return that is associated with when the activation system completed the activation functions based on an external fulfillment state change. This would mean that OSM TOM does not accept revision orders from OSM SOM stemming from changes coming from OSM COM service orders. Or you may decide that OSM TOM should never accept revision orders, in which case you could disable this functionality on the target order specification.

• For each automated task that communicates with a different external fulfillment system, you must determine how the task should behave based on the changes on the technical order.

See the following sections for more information:

• Modeling Changes to Orders

• Modeling Processes and Tasks

Cartridge Management Considerations for TOM

What kinds of cartridge management scenarios you want to plan for in advance, such as the impact of upgrading cartridge functionality, how such upgrades impact run-time orders, how best to structure cartridges to minimize the impact of such changes, and so on.

See "Managing OSM Solution Cartridges" for more information.