Modeling Order Scheduling

14 Modeling Order Scheduling

This chapter describes how to model order scheduling entities in an Oracle Communications Order and Service Management (OSM) solution.

About Order Item Requested Delivery Date and Order Components

OSM can process orders at different times. In many cases, a customer wants an order to be completed as soon as possible, in which case OSM can start processing the order immediately. However, in some cases, the start date of an order should be delayed until a future date. For example:

A customer might request that a new VoIP service be added at the beginning of the next month, when their current service expires.
A customer might request the disconnect of an existing service at the end of the current month.

In addition, there may be groups of order items within an order that need to be fulfilled at different times. For example, an order might contain three services, such as internet, IPTV, and VoIP. The internet and IPTV services might have an immediate requested delivery date, but the VoIP service might only be required at the end of the month, after the customer's current phone service plan has expired. In this case, you can enable OSM to calculate a time to start fulfilling the VoIP service at a future date that would allow the service to be activated by the requested delivery date: at the end of the month.

Different groups of order items may have orchestration dependencies configured that have an impact on when a service gets fulfilled. For example, the internet service might be required before you can activate an IPTV or VoIP service. These dependency scenarios are fixed and take precedence over honoring requested delivery dates. In other words, OSM will only honor a requested delivery date for a service if there is enough time to fulfill that service given the time it takes to perform the fulfillment tasks and any dependencies that might exist between one service and another. In such a scenario, the order completion date will be later than the delivery date requested by the customer.

To accurately calculate when an order should start so that it can meet a requested delivery date, you must determine how long it takes to perform certain tasks contained in the order and you must know when a customer wants a service.

Note:

Orders must have an orchestration plan to be able to calculate the order completion date.

When viewing an entire order in the Order Management web client Summary tab General area, you see the following fields:

Order Creation Date: The date when the order is created in OSM.
Expected Order Start Date: The date when the order is expected to start being processed.
Expected Order Completion Date: The date when the order is expected to be completed.
Requested Order Delivery Date: The date by which the customer requests the order be delivered.
Expected Order Duration: The amount of time the order is expected to take to complete processing.

These fields are used in, or derived from, an orchestration plan algorithm. This algorithm, at its highest level, uses the Order Creation Date (for orders that start immediately) or the Expected Order Start Date (for future dated orders) in conjunction with the Expected Order Duration to determine whether there is enough time to achieve the Requested Order Delivery date. If there is enough time, then the Expected Order Completion Date is the same date as the Requested Order Delivery Date. If there is not enough time, then the Expected Order Completion Date is later than the Requested Order Delivery Date.

When viewing a specific order item in the Order Management web client Summary tab General area, you see the following fields:

Expected Order Component Start Date: The date when the order component that processes the order item is expected to start.
Expected Order Item Start Date: The date when the order item is expected to start. This is always the same date as the first Order Component Start Date to start processing the order item.
Expected Order Item Completion Date: The date when the order item is expected to be complete. In some scenarios, an order item may require processing from more than one order component. For example, one order component may provision the service while another performs the billing function. And so the order item completion date must take into account the total time it takes to complete these two order components.

The following sections describe the design-time and run-time elements that you must model so that the orchestration plan algorithm can generate an order fulfillment timeline.

How OSM Decomposes and Processes Order Items in Order Components

You can model the decomposition of order items into order components that typically share the same function, are destined for the same fulfillment system, and share the same processing granularity. The entity that ultimately processes order items is an executable order component that is linked to a process that contains a sequence of manual and automated tasks that fulfill every order item in the order component.

OSM calculates the order component start dates based on the requested delivery date for order line items in customer orders. This requested delivery date order line item value must be mapped to an order item specification requestedDeliveryDate order item property in Oracle Communications Design Studio.

For example, a group of six order items might be gathered in an executable component that is linked to a process that contains an automated task that generates and sends a service request to an activation system. The service request that the automated task builds would contain all the information from the six order items that the activation system requires to activate services that correspond to the order items in the network.

When OSM has determined the order component start date, all order items in the order component begin processing immediately (regardless of their requested delivery date). Although this can mean that some order items might be delivered early, it ensures that no order items are delivered late.

About Grouping Order Items in Order Components by Date Range

If order items belong to the same function and go to the same fulfillment system need to be fulfilled on substantially different dates, you can model different order components in Design Studio that execute at different stages or within the same stage, but that have different start dates.

In addition, OSM provides Java functions that can be used along with order item hierarchies to further delineate and group order component IDs based on order item requested delivery date. For more information about creating custom component IDs using Java function, see "About Component Specification Custom Component ID XQuery Expressions".

Modeling Order Component Minimum Processing Duration

When you model orders in Design Studio, you need to provide OSM with enough information to be able to meet the order item requested delivery dates with as much accuracy as possible. To do so, you specify a minimum processing duration value that defines how long it typically takes to fulfill all order item within an executable order component. You can model this value at the order component level (see Figure 14-1) or at the fulfillment pattern order component level (see Figure 14-2). OSM always uses the larger of the two values. This duration should take into account the total duration of any manual or automated tasks involved in completing the process. For example, if you know that it takes one week to ship a telephone, you specify one week for the minimum processing duration for an order component that is used for shipping a telephone.

You can specify a different minimum processing duration for each fulfillment mode in the fulfillment pattern. For example, the Deliver fulfillment mode can have a different duration than the Cancel fulfillment mode.

Figure 14-1 shows the duration defined for an order component.

Figure 14-1 Processing Duration Defined for an Order Component

Description of "Figure 14-1 Processing Duration Defined for an Order Component"

Figure 14-2 shows the processing duration assigned to an order component when it is used in a fulfillment pattern Order Components tab, Selected Order Components sub-tab.

Note:

The Duration tab displayed beside the Order Components tab and Dependencies tab in Figure 14-2 is no longer used. This tab still appears in Design Studio to support OSM cartridges that target pre-OSM 7.2.2 servers.

Figure 14-2 Processing Duration Defined for an Order Component as Used in a Fulfillment Pattern

Description of "Figure 14-2 Processing Duration Defined for an Order Component as Used in a Fulfillment Pattern"

The minimum processing duration of an order may vary greatly depending on a number of factors:

The kinds of products or services. Orders for mobile services typically have a very short processing duration, whereas a complex business-to-business order might take weeks.
What must be done to fulfill the actions on the product or service, such as shipping or installation work.
Any dependencies within and between the products and services. For example, PSTN provisioning must complete before ADSL provisioning starts.

Because a single order can have multiple values for the minimum processing duration, defined in multiple order components and at the order level, OSM compares all of them (if they are defined) to find the longest processing duration for the order:

OSM compares the two possible values of the minimum duration for an order component:
- The duration specified in the order component itself.
- The duration assigned to the order component in its fulfillment pattern.
OSM uses the larger of the two values as the order component minimum processing duration.
OSM adds the calculated durations for all of the order components in the order. OSM takes into consideration dependencies between order components. For example, if the order component that provisions a service depends on the order component that processes billing, the minimum processing duration for both components must be used.
OSM calculates the order duration based on the expected order completion date minus the start date.

About Minimum Processing Duration Inheritance in Fulfillment Patterns

For the minimum processing duration that is assigned to an order component by a fulfillment pattern, the minimum processing duration for the order component is inherited in fulfillment patterns extended from the parent fulfillment pattern. For example:

In the BaseProductSpec fulfillment pattern, the BillingFunction order component is assigned a duration of 2 days.
The Service.Fixed fulfillment pattern is extended from the BaseProductSpec fulfillment pattern. Therefore, if you do not specify a duration for the BillingFunction order component in the Service.Fixed fulfillment pattern, it inherits the duration of 2 days from the BaseProductSpec fulfillment pattern.

Figure 14-3 shows how the duration is inherited from a parent fulfillment pattern.

Figure 14-3 Minimum Processing Duration for an Order Component Inherited in a Fulfillment Pattern

Description of "Figure 14-3 Minimum Processing Duration for an Order Component Inherited in a Fulfillment Pattern"

About Minimum Processing Duration Expressions

In addition to specifying a fixed amount of time as the duration, you can use an XQuery expression. The following expression returns a duration of three hours:

PT3H0M0S

You typically use a duration expression if you have an external system that keeps track of processing duration and the load levels of systems. You can write a duration expression that uses this information dynamically. For example, the calculation can take into account peak activity periods.

Calculating the Earliest Order Component Start Date (Order Start Date)

The first order component to start processing can contain one or more order items. OSM uses the order item with the earliest requested delivery date to calculate the order component start date. If there were only one level of order component decomposition in the orchestration plan and there were no dependencies between order components, OSM would calculate the order component start date by taking the earliest order item requested delivery date and subtracting the configured minimum processing duration for the order component. This calculated start date would also be the order start date.

In the scenario, the following order component start dates are possible:

If the component start date (also the order start date) is in the future, OSM does not start the order component until the future date. In the Order Management web client, you would see:
- The expected order start date would be later than the order creation date.
- The order component Expected Start Date would be the same as the expected order start date.
- The expected order item start date for all order items in the order component would be the same as the order component Expected Start Date.
- The expected order completion date and the requested order delivery date would be identical.
If the component start date is in the past, OSM starts the order immediately. In the Order Management web client, you would see:
- The order component Expected Start Date would be the same as the expected order start date.
- The expected order item start date for all order items in the order component would be the same as the order component Expected Start Date.
- The requested order completion date would be before the expected order delivery date.
If no minimum processing duration was configured for the order component, then the order component would start on the same day as the requested delivery date, assuming that day was a future date. In the Order Management web client, you would see:
- The expected order start date would be later than the order creation date.
- The order component Expected Start Date would be the same as the expected order start date.
- The expected order item start date for all order items in the order component would be the same as the order component Expected Start Date.
- The requested order completion date would be on the same date as the expected order delivery date.
If the order item contained no value for the requested delivery date property, then OSM starts the order immediately.

About Calculated Order Component Start Dates

The first order component in an order and any initial order component that does not depend on another order component always uses a calculated start date based on order item requested delivery date values. If the order items do not have values for the requested delivery date, then the order begins processing immediately.

Dependent order items start in the following ways:

Any dependent order components start immediately after the first or initial order component completes and all dependencies are resolved. This is the default behavior for order components.
You can enable calculated start dates for dependent order components by selecting the Use Calculated Start Date check box in the Order Component Specification (see Figure 14-4). Dependent order components use the calculated start date based on the earliest order item requested delivery date in the order component, minus the order component duration. See "Modeling Order Component Dependencies and Requested Delivery Dates" for more information about configuring dependent order component calculated start dates.

Figure 14-4 Enabling Order Component Calculated Start Dates

Description of "Figure 14-4 Enabling Order Component Calculated Start Dates"

For a three stage orchestration cartridge with function, system, and granularity components, you can enable calculated start dates at the function level if you wanted all components related to that function to use a calculated start date. Or you can enable calculated start dates at the system level. In this second scenario, one function might decompose to more than one system level component and a calculated start date might only be required for one of them.

Modeling Order Component Dependencies and Requested Delivery Dates

An OSM orchestration cartridge can have several order components with dependencies configured between them. OSM always honors any order component dependency wait condition before starting a new order component. You can configure dependent order components to start immediately after the blocking order component is complete and all dependencies have been met, or you can use the calculated start date. See "About Calculated Order Component Start Dates" for more information.

This scenario assumes that the dependency between the order component order items are between different order items. For example, order item 1 is only processed by order component A (the blocking order component) and order item 2, which is dependent on order item 1, is only processed by order component B (the waiting order component).

The following dependent calculated order component start date scenarios are possible:

If the component start date is in the future, and the blocking order component is complete with all dependencies met, then OSM does not start the order component until the calculated start date arrives.
If the component start date is calculated to a date before the blocking order component is complete and all blocking order component dependencies are met, then OSM ignores the calculated start date. The order component begins immediately after the blocking order component completes and all dependencies are resolved.
If the order item contained no value for the requested delivery date parameter, then OSM starts the order immediately.

Modeling Order Items Processed by Multiple Dependent Order Components

If OSM processes an order item in more than one executable order component, and there is a dependency between these executable order components, then OSM calculates the order component start dates for the first order component by subtracting the duration from the longest chain of order component durations involved in processing the order item from the earliest order item requested delivery date. This ensures that all order components can be delivered by the requested delivery date. All dependent order components in this scenario would start immediately after the previous order component was resolved. For example, if order item 1 is processed by order component A, B, and C, and B and C depend on A, then the order component start date for A would be the requested delivery date for order item 1 minus the duration of either order components B or C (whichever was longer) and A. Or, if B was dependent on A, and C was dependent on B, then OSM would subtract the total duration of A, B, and C from the requested order delivery date of order item 1 to determine the start date for order component A.

Revisions of Future-Dated Orders

You can submit revision orders to future-dated orders. The revision order can have a different requested delivery date than the base order or the same requested delivery date. In either case, OSM re-calculates the start date for the revision order based on its requested delivery date and on the minimum processing durations of the revised order components.

Note:

Future-dated orders that cancel a future-dated base order are special cases. In this situation, the base order is canceled immediately, regardless of the requested delivery dates.

You can submit a future-dated revision order for an order that has already started processing. Only order components that have not started can have new calculated start dates applied. The new requested delivery date will trigger a compensation only if the order item specification requestedDeliveryDate order item property is marked as significant. Any task compensation required (for example, in previous completed order components) also happens immediately.

As a result of changing a significant order item requested delivery date, OSM calculates a new orchestration plan. Order components that have compensation tasks set with undo, redo, or amend do compensation strategies are executed based on the dependency graph of the revised base order orchestration plan. The order item requested delivery date modification may change the calculated start date of the order component that is processing the order item and, by extension, may also change the expected order completion date.

Examples of Calculating the Expected Start Date

The following examples show scenarios for calculating the expected start date for an order and order components.

Example 1: Calculating Start Dates for Order Components with No Dependencies

In this example:

A billing function order component has a duration of 2 days and processes order item 1 with a requested delivery date of January 3rd.
A provisioning function order component has a duration of 3 days and processes order item 2 with a requested delivery date of January 5th.
There are no dependencies between order components.

The start date for each order component is calculated as follows:

The calculated start date for the Billing order component is calculated using the following logic:
- Order item 1 requested delivery date January 3th
- Minus Billing order component duration 2 days
- The Billing order component start date is January 1st.
Because there are no dependencies between the order components, OSM calculates the start date for each order component separately.
The calculated start date for the Provisioning order component is calculated using the following logic:
- Order item 1 requested delivery date January 5th
- Minus Provisioning order component duration 3 days
- The Provisioning order component start date is January 2nd.

Example 2: Calculating Start Dates for Order Components with Dependencies

OSM always uses the final set of order components for in an orchestration plan to determine the start date for the order component. A final order component has no successor order components. For example, Figure 14-5 shows the order component processing flow for three order items. Order components C and E are final order components.

Figure 14-5 Order Component and Order Item Processing Flow

Description of "Figure 14-5 Order Component and Order Item Processing Flow"

OSM calculates start dates for each order component starting with the requested delivery date of the final order components minus the order duration and any dependency condition wait delay duration. In this example:

Order component C processes order item 1 and 2. Order item 1 has a requested delivery date of January 8, while order item 2 has a requested delivery date of January 10. OSM always uses the earliest requested delivery date to calculate the start date for the order component, which means the January 8 date is used. Because order component C is configured with a duration of 2 days, then order component C starts on January 6th.
Order component E processes order item 3 that has a requested delivery date of January 18. Because order component E is configured with a duration of 2 days, then order component E would start on January 16th.

OSM calculates the start date of order component B by subtracting the configured duration for order component B (2 days) minus the start date for order component C (January 6th) resulting in a start date for order component B of January 4th.

OSM uses order component C instead of order component E to calculate the start date for order component B because order component C is a final order component with an order item that has the earliest requested delivery date. OSM does this to ensure that all order items being processed by an order component are not started late, even though they may start early. In other words, those order items being processed in order component B complete earlier than order component E needs them, but those order items destined for order component C complete with sufficient time for order component C to meet order item 1's requested delivery date of January 8th.

Finally, OSM calculates the start dates for order components A and D. Order component A has a configured duration of 3 days minus the start date for order component B (January 4th) resulting in a start date of January 1st. Order component D has a configured duration of 2 days resulting in a start date of January 2nd.

The order start date is the earliest of all starting order components. In this example, the earliest order component start date is January 1st for order component A.