About Revision Order In OSM

About Revision Order In OSM

    The new version of the order includes all of the data relevant to the order, not just changed data.
 
    A revision Order can have :-Change ,Remove ,ADD in existing Data.

Steps In OSM for Revision Order :-
 
   1. OSM Check for Order Amendable or not, in the Amendable tab of Order you can check it .
 
   2. OSM checks in-flight orders for a matching value to an order key,in the Amendable tab of Order you can check it how to find the Order Key and Version
 
   3. Now OSM check the base order  allowed to be amended.
       3.1. Order Should not be in Not Started, Completed, or Aborted state(OLP).
      3.2. Check for PONR, should  not passed the point of no return.
      3.3. Check for Version , Lower version will get ignored .

If a revision cannot be processed, or if the order life-cycle has not allowed the revision,
the revision order is set to the Failed state, and the base order continues to be processed.
 
   4. Analyzing order data
         4.1 At order Level , revision order data and the base order data .
        4.2 At task level , OSM compares task data for each task in the order process to further validate the compensation requirements for DO,REDO,UNDO .
        4.3 Check for significance data .

   5. For orchestration orders, the order components of the orchestration plan are analyzed to                determine which order components need to be redone, undone, or done for the first time (amend do).

The tasks of the sub-processes run for each of those order components to be compensated are also analyzed.

   6. Any order components with data that has changed as a result of the revision are redone.
       Any order components that have been processed but are no longer required in the revision are undone in reverse dependency sequence.
Any order components that are inserted as new requirements are fulfilled   

Intra and Inter order dependencies

How to achieve intra and inter order dependencies

1.Intra-Order Dependencies Need to configure in product specifications(fulfilment pattern) .

2.Inter-Order Dependencies in Order item specifications.


1.About Intra-Order Dependencies

 Dependencies that can be created within the same order
   a). Order item
       Order Item Dependency Wait Conditions
      Order Item Dependency Wait Conditions Based on Data Changes

   b).Modeling a Product Specification Dependency
       You can define dependencies across different order items by basing the dependency on the        product specifications of the order items.
     For example, you can create a dependency that specifies to provision fixed services only after broadband services have been provisioned
 
c).Modeling an Order Item Property Correlation Dependency
       Using properties correlation is the most flexible way to configure dependencies. You use this method to create a dependency on two different order items that share the same order item property.

 As with other dependencies, you specify a blocking component (the From Component field) and a waiting component (the To Component field), but you also

 enter an XQuery expression to select the order item property that order items in the To Component field must share with order items in the From Component field

2.About Inter-Order Dependencies

An inter-order dependency is a dependency between order items in different orders.
You typically configure this type of dependency to manage changes to an order when that order has passed the point of no return and cannot be amended. However,

you can also use inter-order dependencies for other purposes, such as managing fulfillment functions on different systems, load balancing, and so on.
   

About Behaviors

About Behaviors
 Behaviors means to control  the data element values , there are various way  and 3 level to achieve the it.

Examples of behaviors 

You can specify the maximum allowed digit for phone number field .

You can add the values of multiple fields like first name and last name  and display the sum in another field like customer name(first+last) .

You can specify the minimum and maximum times that a data element can be used in an order.

For example, an order might require that exactly two IP addresses are added.

OSM Behaviors

• Calculation Computes the value of a field value based on a formula that references order data.
• Constraint Specifies a condition that must be met for the data to be considered valid.
• Data Instance Declares an instance that can be used by other behaviors.
• Event Specifies an action that is performed when data is modified.
• Information Specifies the label, hint, and help information for the data element instance.
• Lookup Specifies a set of dynamically generated choices from which you can select.
• Read Only Specifies whether a value can be modified or not.
• Relevant Specifies whether data is visible or hidden.
• Style Specifies the visual appearance of fields.

Evaluating Behavior Levels

In Design Studio, you can create behaviors for data nodes at three levels:

• Data element level (most general)
• Order level (more specific)
• Task level (most specific)

OSM evaluates behaviors from the general level to the specific level. For example, OSM evaluates behavior conditions defined at the data element level first, and evaluates behaviors defined for data nodes at the task level last. At run-time, OSM determines which level to use for a behavior type and data node combination and evaluates rules from that level only.

For example, consider that you create a Calculation behavior at the data element level, and for the same data node you create a Calculation behavior at the order level. In this scenario, OSM would never evaluate the conditions defined for the Calculate behavior at the order level (unless you force evaluation using the Override or Final options), even if all of the conditions defined for the behavior at the data element level evaluate to false.

OSM does, however, evaluate different types of behaviors defined for a data node at different levels. For example, if for the same data node you define a Calculation behavior at the data element level and a Constraint behavior at the order level, OSM evaluates the conditions for both behaviors at run-time.

You can force local, specific exceptions to the way behaviors are evaluated for a given node by selecting the Override and Final check boxes on the appropriate Behaviors Properties view Details tab in Design Studio. You can select the Override attribute to allow the behavior to take precedence over any other behavio

About Using Automation

Two basic types of built-in automation plug-ins:
1.Sender :-The plug-in will receive data, perform some work, then send data to external systems .
2.Automator :- The plug-in will receive data and perform some work .

Event Type
1.Internal Event Receiver :- An event occurs within OSM,creates a message and sends it to the internal message queue.
2.External Event Receiver :- An event occurs in external system and send message to external queue and automation framework subscribes
 to the external message queue through the information you define on the External Event Receiver tab of the automation definition


 AbstractAutomator
        |
|
       \/
 AbstractSendAutomator

 The AbstractAutomator can receive information, either from OSM or from an external system.
 The AbstractSendAutomator inherits this ability, so it can also receive information from OSM or from an external system;
 however, it can also send information. If the custom automation plug-in you are writing is to send a message,
 it should extend the AbstractSendAutomator class; otherwise, it should extend the AbstractAutomator class

OSM Data Significance

Data Significance  become important when Order amendment  is triggered , on the basis of Data Significance OSM decide whether Data need to be updated or not .

By default, all data is flagged significant.
We can make any data structure  as Significant or non-Significant , During amendment processing,
OSM identifies all tasks in the order that are affected
by the changed order data then determines whether the data being changed is flagged as significant ,
because OSM compensate only those tasks that process significant data

Level Of Significance

Data Dictionary(High) --->  Order template data -----> Task data(Low)

Changes to non-significant data are updated on the in-flight order. For example, if the
customer’s preferred contact method (email or text message) is marked as
non-significant, a revision order that changes only that data does not trigger
amendment processing. Instead, the base order is changed, and the revision order is

completed without starting amendment processing. The next task that uses the
changed data uses the updated values.

Order Item Association

Order Item Association

Association can be Achieved in 3 way

1. Fulfilment pattern :- In this case you have to put name of fulfillment pattern which you want to include in order component  after decomposition.

2. Matching Order component ID

3:- Property Correlation :-

x Query / Enrich the order item after decomposition .
when order is moving from one function(fromOrderComponent) to other function(toOrderComponent) .

Order Item Association XQuery assigns order items to order components that are not assigned by their product specification.

These order item associations are typically required when external systems need a specific context for an order item and includes the following characteristics:

let $fromItem := osm:fromOrderComponent/osm:orderItem[osm:name/text()="Speed By Demand [Add]"]
let $toItem := osm:toOrderComponent/osm:orderItem[osm:name/text()="Broadband Bundle [Add]" and osm:properties/im:SiteID/text() = $fromItem/osm:properties/im:SiteID/text()]
return
<osm:dependency fromOrderItemId='{$fromItem/@id}' toOrderItemID='{$toItem/@id}'/>
where

osm:fromOrderComponent: Returns the set of order items included in the order component after the decomposition phase.

osm:toOrderComponent: Returns the entire set of order items included in the order.

osm:orderItem: These are the order items in the fromOrderComponent or toOrderComponent categories.

osm:dependency fromOrderItemId='{$fromItem/@id}: The output of the XQuery specifying the source order item ID for the association.

toItem='{$childOrderItem/@id}'/>: The output of the XQuery specifying the target order item ID for the association.

Understanding Order Recognition

Order recognition is the process of determining the type of an incoming customer

order so it can be mapped to an order type in OSM. Recognition rules allow OSM to

accept any input message structure.

During order recognition, OSM steps through a prioritized list of recognition rules to

determine which rule applies to the in-bound order. Each recognition rule is associated

with an order specification. The first rule that evaluates to true determines the order

specification to use for the incoming customer order and which validations and

transformations are required, if any. Rules are evaluated in an order based on a

property called relevancy, which is defined as part of the recognition rule specification

in Design Studio.

Recognition Rule Errors

There are two possible errors during order recognition:

■ A recognition rule fails to run; for example, because of bad syntax. Evaluation of

other rules continues.

■ The in-bound order is not recognized. If all recognition rules run and fail to find a

match, then no OSM order can be created. This failure generates fallout, which you

can view and manage as an order failure in the Order Management Web client.

To avoid this kind of failure, you can create a lowest-relevancy catch-all rule that

recognizes any in-bound order and maps it to a default order specification.

Creating a Catch-All Recognition Rule

An order that fails to be recognized by any recognition rule is rejected by OSM, and an

error is returned by the Web services operation to the order-source system. To make

sure that all orders are entered into OSM, create a catch-all recognition rule that

accepts all incoming customer orders.

To configure this recognition rule:

■ Set the relevancy to 0, and set the relevancy for all other recognition rules higher

than 0, so they are processed first.

■ Include the following recognition rule XQuery:

fn:true()

Understanding Order Transformation

■ Select the Fail Order check box, and enter a reason. For example:

No valid recognition rule found.

Using this lowest-level recognition rule, an invalid order is recognized and then fails

during validation. It then transitions to the Failed state and is kept by OSM.

About Central Order Management and Service Order Management

When fulfilling orders, OSM can perform two primary roles:

■ Central order management

■ Service order management

OSM in the central order management role receives customer orders from one or more

order-source systems. OSM creates an order, and manages the fulfillment of the order

across other enterprise systems including billing systems, shipping systems, and

service fulfillment systems.

The central order management role is also responsible for receiving status information

from the fulfillment systems and providing an aggregated status back to the

order-source systems. The central order management role is sometimes called central

fulfillment.

OSM in the service order management role is typically a part of a dedicated service

fulfillment system, working with inventory and activation systems to fulfill services in

About Central Order Management and Service Order Management

OSM Concepts

one or more network domains. OSM in its service order management role typically

receives a service order that manages a limited part of the overall order fulfillment. A

service order is typically sent by OSM in its central order management role. OSM

service order management can orchestrate and manage the fulfillment of the services

and resources for the order. It typically works in conjunction with an inventory system

to track and allocate resources (assign-and-design) and an activation system to

configure the network devices and applications. The service order management role is

sometimes called provisioning or local fulfillment.

All OSM functionality; (for example, orchestration) can be used in both of the roles.

However, the order processing performed by OSM in the central order management

role typically uses orchestration more, because of the need to manage relationships

between multiple systems. Orders sent to a service order management system often do

not require an orchestration plan because the tasks in the order can be run as a static

process by OSM.

As an example, an order might be processed as follows:

1. OSM in its central order management role receives a customer order for a

broadband service. Included in the order are requirements for billing, shipping,

and provisioning.

2. OSM generates an orchestration plan, which runs the various fulfillment processes

needed to fulfill the order.

3. To provision the order, OSM uses an automated task to create a separate service

order, which is sent to another instance of OSM functioning in the service order

management role.

4. OSM in its service order management role receives the service order and processes

the provisioning task. It sends the status back to the OSM instance running in the

central order management role.

Service order management typically handles specific provisioning tasks that do not

require orchestration, but you can use orchestration with service order management.

 shows two scenarios. In the first scenario, central order management

handles provisioning for a fixed-line service and a DSL service separately, and it is

therefore able to send service orders directly to OSM in the service order management

role. In the second scenario, the fixed-line service and the DSL service are sent

simultaneously to service order management. Service order management uses an

orchestration plan to send the provisioning requests to separate fulfillment

1. OSM first reads the incoming customer order and creates order items from the

order line items contained in the order.  shows that order line items for

two fixed services and handsets are derived from the order. There are different

regions defined for each service and handset (Ontario and Quebec).

2. OSM begins the orchestration process. The first step is to assign the order items to

order components that are based on fulfillment functions.  shows that

the order items are organized into three function order components: Provisioning,

Shipping, and Billing. The fixed-line services require provisioning, the handsets

require shipping, and all order items require billing, so they are all included in the

Billing order component.

3. The Billing order component must be decomposed further.  shows two

levels of decomposition:

■ Order items for the Ontario and Quebec regions are decomposed into target

system order components. This sends the billing fulfillment process to the

correct region, Ontario or Quebec.

■ For each region, the fixed-line service must be billed separately from the

handset.