A task is a specific activity that must be carried out to complete the order. OSM has more than one type of task:
A manual task requires user intervention, which is performed through the OSM Task web client. See "Working with Manual Tasks" for more information.
An automated task is run without manual intervention and is used to handle interaction with external fulfillment systems. See"Working with Automated Tasks" for more information.
An activation task is a type of automated task that interacts with Oracle Communications ASAP or Oracle Communications IP Service Activator. See "Working with Activation Tasks" for more information.
A transformation task is a type of automated task that accesses the OSM order transformation manager. See "Working with Transformation Tasks" for more information.
All types of tasks share many of the same modeling activities, such as defining task data, details, and compensation. Some configuration steps, however, are specific to each task type. For example, you model behaviors for manual tasks only.
During task creation, you can base new tasks on the functionality of an existing task by using the extend feature. When you extend a task, the extended task inherits all of the data, rules, and behaviors of the parent task. For example, if you have multiple tasks that all require the same data subset, you can create a base task that contains this data, then extend from this task to create as many new tasks as necessary. You can add new data and behaviors to each of the new tasks to create unique task and behavior functionality.
You cannot edit task data inherited from a parent task. For example, if you are working with a task that includes data inherited from a parent task, you cannot remove, rename, or reposition data elements inherited from the parent task, make changes to inherited behaviors, and so forth. Nodes inherited from the extended task are represented by a black icon and cannot be removed from the task. New nodes that you add to the task are represented by a green icon and can be removed from the task.
Additionally, tasks in a cartridge project can inherit from tasks in a different cartridge project, if the order with which the task is associated extends the order from the same source cartridge. For example, a task named Task2 in a cartridge named Cartridge2 can inherit data from a task named Task1 in a cartridge named Cartridge1, but only when the order (with which the task is associated) in Cartridge2 extends the order (with which Task1 is associated) in Cartridge1.
Note:
Design Studio does not permit cyclic referencing. For example, if task T2 extends from task T1, and task T3 extends from task T2, then you cannot extend task T1 from task T3.A task state determines the milestone of a task in a process. The default states are:
Received: The task has been received in the system and is waiting to be accepted.
Accepted: The assigned user (or system) has accepted the task. The task is locked so that it cannot be modified or completed by other users and systems.
Completed: The task is finished.
Assigned: (manual tasks only) The task has been assigned to a user.
Create Activation Work Order Failed: (activation tasks only) The task attempted to create a work order in the activation system but work order creation failed.
These states are mandatory and cannot be removed. You can define additional states (user-defined states) to support your business processes. If a task cannot be completed on time, you can change the task state to Suspended.
A task status describes how a task was completed and determines the next task in the process. Several default statuses are given for each task type. For example, the default statuses for a manual task are Back, Cancel, Finish, and Next. The default statuses for an automated or transformation task are Failure and Success. The default statuses for activation tasks are Success, Activation Failed, and Update OSM Order Failed. You can select from the set of additional predefined statuses (Delete, False, Rollback, Submit, Failed, and True), and you can also define your own.
Note:
A status represents a transition between tasks. The statuses that you define in the Task editor States/Statuses tab appear as task transition options in the Task web client. Statuses that you define for a task but fail to use in the process still appear in the Task web client as transition options. If a user selects one of these unmapped options, the OSM server terminates the process.When you execute a rollback from within a given task, the system executes an update that restores the order to the state that the order was in when the previous task finished. The system accomplishes this by deleting the new nodes, inserting the removed nodes, and restoring the updated nodes with the data they held before the current state.
If you are within a subprocess, you can roll back only to previous subprocess tasks. You cannot roll back from the first subprocess task to the previous parent task. This means that if you want to roll back an entire subprocess task, you must complete the subprocess, proceed to the next task in the main process, then roll back to the parent process task that spawned the subprocess in question.
Because the rollback executes when the Task web client user clicks the Back button, the order advances according to how you define the rollback status in the process.
If a task is at the rollback status, the Mandatory Check option is disabled for that task. See "Process Editor Flow Properties General Tab" for more information about the Mandatory Check option.
Designing Workstream Processes
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.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.
For more information about compensation XQuery expressions, see "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.Fallout refers to orders that encounter problems during fulfillment and therefore fall out of normal processing. OSM places these orders in Failed state (you can also manually fail orders in the Order Management web client).
In the Design Studio Order editor, you associate a fallout name with one or multiple data nodes whose values you will want to review (in the Order Management web client) when the corresponding type of fallout occurs. In the Task editor, you associate tasks with the types of fallout that can occur for the task.
See "Task Editor Fallouts Tab" when modeling task fallout in Design Studio.
Ensure that the Exception Processing permission is assigned to roles that are assigned to fallout tasks.
See "Role Editor Role Tab" for information on assigning permissions to role entities.
A Task web client user can reassign a task only after you configure the task for reassignment in Design Studio for OSM.
Before a Task web client user can reassign a task, you must ensure the following:
You have added the Assigned state to the task. See "Assigning Task States and Statuses" for more information.
You have added a role to the task that is responsible for reassigning the task. See "Assigning Task Permissions" for more information.
You have an Oracle WebLogic Server user account that is a member of the role entity, using the Administration area of Order Management web client, that has the Task Assignment permission applied. See "Role Editor Role Tab" for more information.
See OSM Task Web Client User's Guide for information about reassigning a task.