About Tasks and Processes

A task is an activity that must be carried out to complete an order; for example, if an order needs to verify that an ADSL service was activated, you could model a task named Verify ADSL Service. Tasks can be manual or automated.

Manual tasks must be processed by order management personnel, by using the Task web client. Manual tasks typically include tasks that cannot be automated, or tasks that require decision-making, when there are multiple choices for how to proceed with order processing.
Automated tasks run automatically with no manual intervention. Automated tasks typically communicate with external systems by using the external system's API. For example, you could define an automated task called Verify Address. An automation plug-in can be configured to send order data to a third-party address verification system whenever an order reaches the Verify Address task. The third party returns an address confirmation to OSM, completing the task.

A process is a sequence of tasks and subprocesses that run consecutively or concurrently to fulfill all or part of an order. Processes enable you to break down the work required to execute and fulfill an order into functional tasks, which can be distributed to various systems and order managers to be completed in a controlled manner.

In processes, you can control how the tasks are run. For example, you could create a rule that evaluates data and branches the process appropriately. Any number of processes can be defined in an order process, consisting of any number or combination of manual and automated tasks. You can also run subprocesses from a process. Subprocesses are processes that are launched from another process, as opposed to being launched from an order.

Figure 5-1 shows a process and its tasks, as shown in Design Studio:

Figure 5-1 Example of an OSM Process

Description of "Figure 5-1 Example of an OSM Process"

This process manages the fulfillment of a request for an ADSL service:

The first task, Verify ADSL Service, is an automated task that verifies that the ADSL service exists. For example, the task might run a web service operation that reads a database to determine if the service is available at the specified address.
After verifying that the service is available, the process branches to two tasks that are independent and can run in parallel:
1. The Ship Modem Self-Install Pkg task sends a shipping order to the hardware provider.
2. The Assign Port task looks up a port in the inventory system and assigns it.
  
  If the port is available, the next task is Activate DSLAM. However, if the port is not available, the process transitions to the Add Capacity task, and then back to the Assign Port task.
After the Assign Port task is finished, the Activate DSLAM task can run. This task contains an OSM integration with a third-party activation system to activate the DSLAM.

The Assign Port task is dependent on the completion of both the Ship Modem Self-Install Pkg task and the Activate DSLAM task. Therefore, even if the Ship Modem Self-Install Pkg task completes, the Activate DSLAM task cannot start until the Assign Port task is finished.
When the activation is complete, the next two tasks send the customer survey and require that an OSM user verifies the order to make sure it is complete. After these two tasks are completed, the order is complete.

Any of the tasks in this process can be configured as automated tasks. For example, the Assign Port task can be an automated task if there is an integration with the inventory system, and the inventory system is able to respond to an automation plug-in sender requesting a port number with a response that assigns the port number for the service.

When you create tasks in Design Studio, you define the data required by the task. A task typically contains a subset of the order data received on an incoming order. For example, the task for shipping a modem might require a customer name, phone number, and address but not the required internet bandwidth.

About Manual Tasks

Manual tasks are assigned to personnel who complete the work for these tasks in the OSM Task web client. Personnel can manage tasks by adding comments to the order, attaching documents, displaying the history of the order, and manually entering and saving order data required to complete the task.

To run manual tasks by using the OSM Task web client, an order manager works from a list of manual tasks called a worklist. To complete a task, an order manager typically enters data or reviews the data, and then indicates that the task is complete.

Figure 5-2 shows tasks displayed in the Task web client worklist. In this example, Assign Port and Ship Modem are manual tasks.

Figure 5-2 Tasks Displayed in the Task Web Client

Description of "Figure 5-2 Tasks Displayed in the Task Web Client"

Task states track the progress of a task. For example, when a task begins, it is in the Received state until such time as an operator accepts the task. The task remains in the Accepted state until the operator complete the task.

When you model manual tasks in Design Studio and define the data required for the task, you can do the following:

Assign Roles: You can assign roles to tasks which, when associated with OSM WebLogic user accounts as workgroups, limit who can receive, accept, and work on new tasks in the Task web client.
Define Notifications: You can configure a task to trigger notification messages that appear in the Task web client to inform order managers of the progress of the order. Notifications can also trigger automation plug-ins that send status updates or jeopardy warnings to external systems or users.
Configure Behaviors: You can use behaviors to manipulate data and to control how data is displayed in the Task web client. For example:
- You can specify the maximum allowed number of characters for text string data.
- You can specify the contents of a list displayed in the Task web client.

About Automated Tasks

Automated tasks require no manual intervention. Automated tasks handle internal interactions with external fulfillment system, such as billing systems, shipping systems, activation systems, and other fulfillment systems. OSM processes typically include more automated tasks than manual tasks.

To create an automated task, you do the following:

Model a task entity in Design Studio. An automated task entity includes many of the same elements as a manual task; for example, data required for the task, notifications to send, and task states.
Create one or more automation plug-ins. Automation plug-ins can perform custom logic, send a message to an external system, or update OSM with data received from an external system. For example, you could define a task called Verify Address. An automation plug-in can be configured to send order data to a third-party address verification system whenever an order reaches the Verify Address task. Another plug-in can be used to receive the address verification. Most plug-ins use XQuery to find, filter, and transform data.

OSM uses the automation framework to run and manage plug-ins. The automation framework provides the primary interface for outbound and inbound operations that interact with external systems for automated order fulfillment. The automation framework also provides internal data processing for automated tasks within a process workflow. A plug-in can access task data and perform OSM functions such as completing a task.

An activation task is a type of automated task, designed specifically to interact with the Oracle Communications ASAP product and the Oracle Communications IP Service Activator product to activate services on your network.

Activation tasks include many of the same properties as other automated tasks; for example, you can assign permissions, define the task data, and configure notifications that trigger automation plug-ins. However, you also configure activation-specific data elements, such as how to map data sent to and received from ASAP or IP Service Activator.

About Task States

A task state determines the condition of a task in a process. Every task in OSM has a set of possible states that reflect the life cycle of the task. The required tasks are:

Received: The task has been received by a workgroup and is waiting to be accepted.
Assigned: The task has been assigned to a specific OSM user. Tasks that are in the assigned state cannot be worked on by other users.
Accepted: An order manager has accepted the task and is working on it. Tasks that are in the Accepted state cannot be worked on by other users unless the state is returned to the Received state.
Completed: The task has been completed by a user or an automation plug-in. A task that has been completed no longer appears in a user's worklist.