About Task Compensation

Compensation refers to the changes OSM makes to an order when a customer requests a change to the order after the service fulfillment process has been initiated or when a failure occurs during order processing that triggers compensation for fallout management purposes. OSM manages these in-flight changes, called order amendments, by analyzing the tasks performed in the process and determining whether data has changed. This analysis, called Order Change Management, is necessary when, for example:

A consumer orders high-speed internet access, then calls back midway through the service fulfillment process to change bandwidth or cancel the order.
A business customer orders VoIP service for several office locations and then calls back multiple times to change the feature sets for the various offices as the order is being processed.
An error occurs in an in-flight order where a user or an automation plug-in can raise an exception, trigger fallout, and make changes to compensate for errors that caused the error.

In Design Studio, you configure the manner in which OSM manages these changes to in-flight orders by indicating how the run-time environment compensates the task if it is affected by an amendment.

Note:

Compensation ignores timer delays and event delays between tasks while undoing or redoing the tasks in a process.

Execution Modes

Tasks can execute in one of the following possible execution modes:

Do is the default mode for a task that executes under normal processing.
Undo reverses the effects of the associated Do operation.
Redo combines both Undo and Do operations in a single operation.
Do in Fallout is the mode that a task uses after the task has moved from the Do execution mode because of a failure condition. You can use this mode to manually investigate and resolve failure conditions or trigger automation plug-ins set to run in the fallout mode.
Undo in Fallout is the mode that a task uses after the task has moved from the compensation Undo execution mode because of a failure condition. You can use this mode to manually investigate and resolve failure conditions or trigger automation plug-ins set to run in the fallout mode.
Redo in Fallout is the mode that a task uses after the task has moved from the compensation Redo execution mode because of a failure condition. You can use this mode to manually investigate and resolve failure conditions or trigger automation plug-ins set to run in the fallout mode.

On the Compensation Strategy tab of the Task editor, you define how the run-time environment compensates tasks if they are affected by an amendment. Each section on this tab represents a scenario to consider when determining a compensation strategy for the task.

You can model a static compensation strategy from the predefined list or a dynamic compensation strategy based on an XQuery expression that compares data from the revision order with the results of a comparison between the current order perspective and the historical order perspective. Dynamic compensation strategies can be useful if you want to model different compensation types based on revision order data values. For example, you could model the XQuery to select an Undo then do compensation strategy if the revision order bandwidth parameter is greater than 50 MB, and only a Redo compensation strategy if the bandwidth parameter is less than 50 MB.

You can also configure whether a task is included in compensation when it is completed or in progress, or you can use an XQuery expression that evaluates whether an in progress task can be included in compensation based on order data. This ability is important for long running tasks where a response to a request takes hours or even days but still needs to be considered in compensation. If you specify that a task can be compensated while it is in progress, you can also specify whether a grace period should be observed before performing the compensation. In addition, you must use an XQuery expression to evaluate any changes to the compensating task data to identify when the compensation has completed and the task can enter into normal do mode again.

For example, some automated plug-ins communicating with workforce management systems may involve the dispatching of personnel to perform work over several days. In such cases the automation plug-in sends the dispatch request to the workforce management system, and remains in progress until such time as the work is completes. If a revision order were to arrive that changes some aspects of the work required by the dispatched personnel, then the in progress automation plug-in responsible for sending the original request should be included in the compensation plan. You can specify an XQuery that evaluates data on the in progress task communicating to the work force management system that determines if the task needs to be compensated. In addition, you can specify whether a wait period should be observed before starting compensation. You must also write an XQuery that determines when compensation has completed, for example, when the task receives the response from the new request indicating the workforce management system has received the new work details and has begun to processing the request.

See "Compensation XQuery Expressions" for more information about compensation XQuery expressions.

Note:

If you modify the default strategy settings, ensure that you analyze the task within the context of the entire workflow because modifying strategy settings in one task can adversely effect subsequent tasks and task data.