Skip Headers
Oracle® Communications Order and Service Management Concepts
Release 7.2.2

E35415-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 About Tasks and Processes

This chapter describes how Oracle Communications Order and Service Management (OSM) uses processes and tasks to fulfill order requirements.

Before reading this chapter, read "Order and Service Management Overview" for more information.

About Tasks and Processes

A task is a specific activity that must be carried out to complete the order; for example, if an order needs to verify that an ADSL service was activated, you might model a task named Verify ADSL Service. Tasks can be manual or automated. Manual tasks must be processed by an order manager, using the Task Web client. Automated tasks run automatically with no manual intervention. See "About Tasks" for more information.

A process is a sequence of tasks. A process includes tasks, subprocesses, the sequence in which tasks are run, and ways to control how the tasks are run; such as rules and delays. Processes allow you to break down the work required to execute and fulfill an order into functional tasks, which can be distributed to various systems and people to be completed in a controlled manner. See "Understanding Processes" for more information.

Figure 5-1 shows a process in Oracle Communications Design Studio. The process adds a DSL service. Each box represents a task in the process. Automated tasks include an arrow in the icon.

Figure 5-1 Process as Modeled in Design Studio

Graphic is described in surrounding text.

The process shown in Figure 5-1 includes the following tasks:

  1. An automated task verifies that an ADSL service is available.

  2. A manual task assigns a port. If the port is not available, another manual task runs that adds capacity. The process then returns to the task for assigning a port.

  3. An automated task activates the service.

  4. A manual task sends a customer survey.

  5. After the customer survey is sent, a manual task verifies the order. The process is complete.

About Tasks

A task is a specific activity that must be carried out to complete the order. For example, to complete an order for a telephone service, the following tasks might be required:

There are two types of tasks: automated and manual.

Automated and manual tasks share many of the same modeling activities, such as defining task data. Some configuration steps, however, are specific to each task type. For example, you model behaviors for manual tasks only.

Most tasks perform actions that fulfill order data; for example, activating a service. You can also use tasks for other purposes. For example:

Tip:

You can insert manual tasks in a process that function as breakpoints for debugging. This allows you to control a process when you test it.

About Task Data

Each task includes a set of data, which you specify when modeling the task. Figure 5-3 shows the task data included in a task for assigning a port.

Figure 5-3 Task Data in Design Studio

Shows task data in Design Studio.

The data included in a task is data relevant to the function of the task. Table 5-1 shows some example tasks and the task data they include.

Table 5-1 Examples of Tasks and Task Data

Task Task Data

Add capacity

Bandwidth

Send customer survey

Name, phone number, address

Query task (to display data in the Task Web client)

Name, phone number, bandwidth, port ID


When you model a task, you assign it to an order. The available task data is limited to the data that the order requires. At run time, task data can be entered by an OSM user, provided on an incoming order, or provided from a previous task in the order. Figure 5-4 shows a task specification for a task used by the order type named OsmCentralOMExampleOrder.

Figure 5-4 Order Specified in a Task

Graphic is described in surrounding text.

Figure 5-5 shows task data defined in a task in Design Studio and how the data is displayed in an order in the Task Web client.

Figure 5-5 Task Data in a Task Specification and in an Order

Graphic is described in surrounding text.

Tip:

To improve performance, usability, and security, include only the data that is necessary to perform the task. Unnecessary data is not exposed to the user performing the task, even though the order may contain much more data.

When modeling orders, it is common to include the entire XML representation of the order in the order data as an XML data type. If you include the XML data, consider defining smaller XML elements for storing sections of a sales order rather than including a single XML data type that contains the entire sales order. This allows you to map only the parts of the order that are needed for each task. Including the XML representation is typically done only in the modeling process as an aid to development.

In addition to defining the data included in each task, you can use behaviors in manual tasks to manipulate many aspects of how the data is displayed, formatted, and validated. For example, you can specify if data is read-only, or you can modify the value of the data in a task. See "About Behaviors" for more information.

Generating Multiple Task Instances from a Multi-Instance Field

Some tasks require multiple task instances to complete. For example, you might need to create three task instances to retrieve three different address fields. To accomplish this, you designate a field as a pivot data element for the task. When OSM runs the task at run time, the system generates a separate task instance for each separate instance of the pivot data element in the order. The system creates as many instances of the task as there are instances of the data field or data structure, up to the maximum number defined for the field. This feature works for a structure of data also. For example, if the address is a structure called Address, with nested elements of Street, City, and Postal Code, the system generates an instance of a task for each instance of the structure. The data that is visible to the task instance will be restricted to data structure that it is for, and that task will not have visibility to the other instances of the data.

Note:

OSM compensation processing does not support task pivot data elements.

About Extending Tasks

You can create a new task by extending from an existing task. The new task inherits all of the data, tasks, rules, and behaviors of the base task from which it was extended. Changing something on the base task is reflected in all tasks extending from it.

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. Extending tasks can significantly reduce duplication and maintenance.

About Task States

A task state determines the condition of a task in a process. Every task in OSM has a set of states that reflect the lifecycle of the task. The minimum states required for a task to be completed are Received, Accepted, and Completed.

Changing the state of a task changes how it can be worked on; for example, changing the state to Assigned restricts who can work on the task. Table 5-2 shows the predefined task states. All of them are mandatory.

Table 5-2 Task States

State Description

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. Users with assignment privileges can re-assign tasks if needed.

Accepted

An order manager has accepted the task and is working on it. A task can be accepted by a user by explicitly changing the state of the task to Accepted or by editing the order. 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.


The Received, Assigned, and Accepted task states are the only task states provided by OSM. However, you can create your own task states. For example, you can define different types of suspended task states; for example, Waiting for Client Confirmation.

Using Task States to Manage Orchestration Dependencies

You can use task states when defining orchestration dependencies. For example, you can specify to wait until a task has reached a specified state before an order component can be processed. See "About Dependencies" for more information.

About Task Statuses

A task status represents the result of the task, and determines how a task can transition to a next step in the process. For example, if a task can either succeed or fail, the task status can be either success or failure, and each might transition to a different task in the process.

The statuses that you define in Design Studio appear as task transition options in an OSM Web client. Figure 5-6 shows part of the Task Web client. The list showing Delete and Submit shows the possible statuses for the task. Task statuses can also be displayed in the Task Web client as buttons; for example, the Back and Next buttons.

Figure 5-6 Task Statuses in the Task Web Client

Shows part of the task web client.

Figure 5-7 shows part of a process defined in Design Studio. The Assign Port task has two possible statuses: Port Available and Port Unavailable. If the port is available, the status is changed to Port Available. If not, the status is changed to Port Unavailable.

If the status is changed to Port Unavailable, the process transitions to the Add Capacity task. This task has two possible statuses: Next and Failure. If the capacity cannot be added, the task status is changed to Failure, and the process ends. If the capacity can be added, the task status is changed to Next and the process transitions back to the Assign Port task.

Figure 5-7 Task Status in Design Studio

Graphic is described in surrounding text.

The default statuses for a manual task are:

  • Back

  • Cancel

  • Finish

  • Next

The default statuses for an automated task are

  • Failure

  • Success

The default statuses for activation tasks are:

  • Success

  • Failed

  • Update Order Failed

You can also select from additional predefined statuses

  • Delete

  • False

  • Rollback

  • Submit

  • Failed

  • True

You can also define your own task statuses.

Using Task States and Statuses to Trigger Event Notifications

You can use task states and task statuses to trigger event notifications. For example, changing to the Failure status can trigger a notification to a fallout specialist. See "About Event Notifications" for more information.

Task Statuses and Constraint Behavior Violation Severity Levels

You can use task statuses in combination with Constraint behaviors to specify the conditions under which a process can make a transition to the next task or activity in the process.

You use Constraint behaviors to validate order data. For example, you can validate that a telephone number has 10 digits or ensure that a numeric value is between 0 and 100.

Constraint behaviors include a Display as violation severity level and a message to be displayed in the Task Web client when a constraint behavior violation occurs. When Save is clicked in the Task Web client Order editor, the save action taken depends on the constraint behavior violation severity level.

Table 5-3 Constraint Behavior Actions

Constraint behavior violation severity levels, from highest severity to lowest Message display: When Save is clicked:

Critical

OSM displays the message in bold red text, with the label "ERROR".

The data is not saved.

Error

OSM displays the message in red text, with the label "ERROR".

The data is saved.

Warning

OSM displays the message in yellow text, with the label "WARNING".

The data is saved.

Valid

OSM displays the message in green text, with the label "INFO".

The data is saved.


Using Task Statuses to Control Process Transitions

You can use task status Constraint values to determine how Constraint behavior violation severity return values affect whether or not a process can make a transition to the next task or activity. Task status Constraint values include:

  • Critical

  • Error

  • Warning

  • None

  • Valid

The task status Constraint value represents the highest allowable Constraint behavior violation value with which the task transition will be allowed to occur. When Update is clicked, in the Task Web client Order editor, the transition action taken depends on the task status Constraint severity value in conjunction with the Constraint behavior violation severity level, if any.

For example, if the task status Constraint value is set to Error, then Error is the highest allowable Constraint behavior violation value with which the task can be transitioned. The task is not allowed to transition if a Constraint behavior violation of Critical occurs, but is allowed if an Error, a Warning, or a Valid Constraint violation occurs.

The following table explains whether task transition is allowed for all combinations of Constraint behavior violation severities and task status Constraint values.

Table 5-4 Constraint Behavior Actions

Task status Constraint value (highest allowable constraint violation): Task transition allowed for Critical constraint violation? Task transition allowed for Error constraint violation? Task transition allowed for Warning constraint violation? Task transition allowed for Valid constraint violation?

Critical

Yes

Yes

Yes

Yes

Error

No

Yes

Yes

Yes

Warning

No

No

Yes

Yes

Valid

No

No

No

Yes

None

No

No

No

No


Specifying the Expected Task Duration

You can specify the expected length of time to complete a task. This information can be used to trigger jeopardy notifications and for reporting. See "About Notifications" for more information. This information is also used by OSM to calculate the order component duration.

You can specify the length of time in weeks, days, hours, minutes, and seconds. The default is one day.

You can also calculate the duration based on your workgroup calendars. If you have more than one workgroup with different calendars all responsible for the same task, the calculation is based on the first available workgroup that has access to the task. This ensures that a the task only exceeds it's duration based on the workgroup calendar time.

For example, there might be a task with an expected duration of two hours, and the workgroup that processes the task only works 9 AM - 5 PM Monday to Friday as indicated on their workgroup calendar. If such a task is received at 4 PM on Friday, then the expected duration of the task will expire at 10 AM Monday, as there was only two hours of the workgroup calendar time that had elapsed (4-5 PM Friday, then 9-10 AM Monday). This ensures that notifications and jeopardies are triggered appropriately.

See OSM Task Web Client User's Guide for more information.

Specifying the Task Priority

Task priority is the same as the order priority unless a priority offset is defined. Priority of orders and their tasks becomes effective when the system is under heavy load, ensuring that high priority orders and tasks are not starved of resources by lower priority orders and tasks.

You define the task priority as an offset from the priority of the order itself. This specifies the priority of the task in relation to other tasks in the order.

For example, if the order is created at priority 6, and this task is assigned a priority offset of -2, then this task would run at priority 4 while tasks in the order with no offset would run at priority 6. Similarly, you could assign a task a priority offset of +2, which would mean that the task would run at a slightly higher priority than other tasks in the order.

See "About Specifying the Order Priority" for more information.

Managing Tasks During Amendment Processing and Task Compensation

See "Managing Changes to Orders" for information about amendment processing.

You can define how amendment processing affects each task; for example, if it should be redone or undone. To model amendment processing, you specify if a task should be re-evaluated and, if so, what should be done (redo or undo then do).

Tasks must be re-evaluated when:

  • An order amendment changes data that is flagged as significant.

  • The task is affected by compensation performed on another task. For example, an amendment changes the data for Task A, which when redone changes the output data that is used as input into the data for Task B, requiring Task B to be redone.

If a task must be re-evaluated, you can specify the following actions:

  • Do Nothing: If nothing must be done, you can specify to skip the task. You typically choose this option if the change to the order is handled by a similar task downstream in the process or if there is no functional need to compensate for the task; for example, if there is a task to send a marketing brochure, this may not have any compensation necessary.

  • Redo: You can specify to redo the task (this is the default). Redoing performs Undo and Do operations in a single operation. This option is recommended, because it performs the fewest number of operations.

  • Undo then do: You can specify to undo and then redo the task. This option undoes the task and all successor tasks, rolls back all order changes, then performs the Do operation again. This is useful if you need to rollback all subsequent order changes and re-perform the task from the beginning.

  • You can specify to run a task manually or automatically during compensation. For example, you can specify that an automated task can only be redone or undone manually. This is useful for gradually introducing amendment processing into a solution.

You can also specify how to handle the task if it is no longer needed. A task can no longer be needed in two cases:

  • When the order is canceled.

  • When the branch on which the task is located becomes obsolete. A branch becomes obsolete when the redo processing causes a task or subprocess to exit with a different completion status and start a new branch.

In both scenarios, the system rolls back the order changes. For each task, you can specify that OSM either roll back the task automatically or run a manual undo task. The manual undo task must be completed in the Task Web client to allow OSM to roll back the canceled or obsolete task.

Controlling Who Can Process a Task

You can assign roles to each task and to each processing type that can be performed on a task; for example, Do, Redo, and Undo. For example, you can restrict basic order processing personnel from redoing and undoing tasks and allow those operations only for fallout specialists. Roles are also used for managing jeopardy notifications for tasks.

See the discussion of roles and permissions in OSM System Administrator's Guide for more information.

Specifying How to Assign Tasks to OSM Users

There are two approaches to assigning tasks to users in OSM:

  • A work offer approach, which is by role, where tasks are associated to a role and users performing that role may select tasks from their worklist to work on them.

  • A work assign approach, where a task assignment algorithm is used to specifically assign each task to a user performing the role.

For each manual task, you can specify how it is assigned to an OSM user for completion. You can use the following methods:

  • Round robin assignment automatically assigns tasks to users in a workgroup alphabetically by user name.

  • Load balancing assignment automatically assigns users in a workgroup to balance the workload across users, based on the number of tasks assigned to each user. The user with the least number of tasks is assigned the task.

You can also create custom automatic assignment methods. For example, you might specify that the first task received is the first one assigned or that the last task received is the first one assigned.

Before you can use a custom task assignment algorithm in an OSM cartridge, you must develop then deploy custom task assignment algorithm Java code. The OSM cartridge management tool (CMT) is an Ant based application that you must use to deploy a custom task assignment algorithm to the OSM WebLogic Server.

OSM provides the OSM_home/SDK/Samples/TaskAssignment/code /CustomizedTaskAssignment.java sample task assignment algorithm as part of the selectable SDK Samples OSM installation component as a reference to help develop custom task assignment algorithms. This sample implements the com.mslv.oms.behavior and the com.mslv.oms.behavior.taskassignment OSM API packages and the java.util Java SE package. For more information about the classes in the OSM packages extract the OSM_home/SDK/osm7.2.x-javadocs.zip OSM Java docs (where x is the software build numbers). For more information about the java.util Java SE package, see the Java SE documentation.

Deploying a Custom Task Algorithm using the OSM Cartridge Management Tool

Before you can use OSM CMT to deploy a custom task assignment algorithm, ensure that:

  • You can access and reference a WebLogic Server and ADF installation home directory from the OSM CMT build files. See OSM Installation Guide for version information.

  • You must download and install Ant. See OSM Installation Guide for version information.

  • You install the SDK Tools and the SDK Samples components using the OSM installer. You do not need to install the other options. See OSM Installation Guide for more information about using the OSM installer.

  • You have created a custom task assignment algorithm. See the OSM_home/SDK/Samples/TaskAssignment/code /CustomizedTaskAssignment.java reference sample for more information about creating a custom task assignment algorithm.

To deploy a custom task algorithm to an OSM server using OSM CMT:

  1. From a Windows command prompt or a UNIX terminal, go to WLS_home/server/lib (where WLS_home is the location of the base directory for the WebLogic Server core files).

  2. Create a WebLogic client wlfullcient.jar file that OSM CMT uses to communicate with the OSM WebLogic server:

    java -jar wljarbuilder.jar
    
  3. Copy the following files required by OSM CMT to the Ant_home/lib folder (where Ant_home is the location of the Ant installation base directory).

    • WLS_home/server/lib/weblogic.jar

    • WLS_home/server/lib/wlfullclient.jar

    • MW_home/modules/com.bea.core.descriptor.wl_1.2.0.0.jar (where MW_home is the location where the Oracle Middleware products were installed.)

    • OSM_home/SDK/deploytool.jar

    • OSM_home/SDK/Automation/automationdeploy_bin/automation_plugins.jar

    • OSM_home/SDK/Automation/automationdeploy_bin/xmlparserv2.jar

    • OSM_home/SDK/Automation/automationdeploy_bin/commons-logging-1.1.jar

    • OSM_home/SDK/Automation/automationdeploy_bin/log4j-1.2.13.jar

  4. Set the following environment variables and add them to the command shell's path:

    • ANT_HOME: The base directory of the Ant installation.

    • JAVA_HOME: The base directory of the JDK installation.

    For example, for a UNIX or Linux Bash shell:

    ANT_HOME=/home/user1/Middleware/modules/org.apache.ant_1.7.1
    JAVA_HOME=/usr/bin/local/jdk160_33
    PATH= $ANT_HOME/bin:$JAVA_HOME/bin:$PATH
    export ANT_HOME JAVA_HOME PATH
    

    For example, for a Windows command prompt:

    set ANT_HOME=c:\path\to\oracle\home\Middleware\modules\org.apache.ant_1.7.1
    set JAVA_HOME=c:\path\to\oracle\home\Middleware\jdk160_24
    set PATH=%ANT_HOME%\bin;%JAVA_HOME%\bin;%PATH%
    
  5. Open the OSM_home/SDK/Samples/config/samples.properties file.

  6. Set the following variables:

    • Set osm.root.dir to the OSM installation base directory.

    • Set oracle.home to the Oracle Middleware products base directory.

      For example, for a UNIX or Linux Bash shell:

      /home/oracle/Oracle
      

      For example, for a Windows command prompt:

      C:/Oracle
      
  7. Copy the custom task assignment algorithm file you created to OSM_home/SDK/Samples/TaskAssignment/code.

  8. Open the OSM_home/SDK/Samples/TaskAssignment/code/build.properties file.

  9. Set the following variables:

    • Set weblogic.url to the WebLogic Administration Server URL. The format is:

      t3://ip_address:port
      

      where:

      • ip_address is the IP address for the WebLogic Administration Server.

      • port is the port number for the WebLogic Administration Server.

    • Set weblogic.domain.server to the name of the WebLogic Administration Server.

    • Set weblogic.username to the WebLogic Administration Server user name.

    • Set webLogicLib to the path to the WLS_home/server/lib folder.

    • Set ejbname to the Enterprise Java Bean (EJB) name for the task assignment behavior.

    • Set ejbclass to the class name for the task assignment behavior.

    • Set jndiname to the Java Naming and Directory Interface (JNDI) bind name for task assignment behavior.

    • Set targetfile to the deploy target file name for a target file that does not contain a suffix like .ear or .jar.

    Note:

    ejbname, ejbclass, jndiname, and targetfile are preconfigured to deploy the OSM_home/SDK/Samples/TaskAssignment/code/CustomizedTaskAssignment.java sample task assignment algorithm. Replace these default values with those for the custom task assignment algorithm.
  10. Create and deploy Design Studio cartridge that includes a manual task that you want to associate to the custom task assignment algorithm. You can associate the custom task assignment algorithm in the Details tab of the manual task using the Assignment Algorithm and JNDI Name fields. See the Design Studio Help for more information.

    Note:

    You can import the sample task assignment cartridge from OSM_home/SDK/Samples/TaskAssignment/data/ taskassignment.xml. For more information about importing an OSM model into Design Studio, see the Design Studio Help.
  11. From the Windows command prompt or UNIX shell, type:

    ant
    

    The Ant script begins to run.

  12. When the ant script reaches Input WebLogic Password for user weblogic ..., enter the WebLogic Administration Server password.

    The ant tool compiles, assembles, and deploys the custom task assignment algorithm to the OSM WebLogic Server.

    Note:

    You can also individually compile, assemble, deploy, or undeploy using the following Ant commands:
    ant compile
    ant assemble
    ant deploy
    ant undeploy
    

About Automated Tasks

You can create an automated task to connect to a database, transform some data, or communicate with an external system. Most tasks are automated.

Automated tasks and automated notifications trigger automation plug-ins. An automated task triggers a specific automation plug-in when the task transitions to the Received state. This occurs when an instance of the task is created in OSM. An automated task receives a message internally from OSM, and the information contained in the internal message is made available to the automation plug-in. The automation plug-in uses that information to perform custom logic, update OSM, or send a message to an external system. If a message is sent to an external system, the plug-in is capable of receiving a message externally from the system with which it initiated communication.

When you create an automated task, you must also configure at least one automation plug-in to perform the operation. An automated task might have a single automation plug-in associated with it (for example, to interrogate the task data, perform some calculation, and update the order data), or it might have multiple automation plug-ins associated with it (one to send information to an external system, one to receive replies from the external system, and another to perform some calculation, update the order, and transition the task).

Automated tasks are supported by the following plug-ins:

  • XSLT Plug-in. A plug-in that supports an XSLT script that generates an outbound message and processes an in-bound message.

  • Email Plug-in. A plug-in that sends notifications to external systems through email.

  • JDBC Plug-in. A plug-in that uses Java Database Connectivity (JDBC) to retrieve or update data in the database.

  • XQuery Plug-in. A plug-in that runs XQuery expressions to generate an outbound message and process an in-bound message.

You can create custom plug-ins. See the Design Studio online Help and OSM Developer's Guide for more information.

Understanding Automation Plug-ins

There are two types of predefined automation plug-ins: automator and sender.

  • Automator plug-ins receive information from OSM or an external system and perform some business logic. They can also be configured to update the order data.

  • Sender plug-ins send information from OSM to an external system. They perform business logic and can update orders. Additionally, they can produce outgoing JMS or XML messages to be delivered to an external system.

Both plug-in types can be implemented using XSLT or XQuery.

An automated task can be associated with either a single automation plug-in or with multiple automation plug-ins. For example, you might model multiple automation plug-ins for an automated task to communicate with external systems. These could include:

  • A sender plug-in to send task data to an external system for processing.

  • An automator plug-in to receive the reply from the external system and update the order data.

  • A sender plug-in to send the external system a message to begin processing.

  • An automator plug-in to receive processing messages from the external system, update the order, and transition the task.

Understanding Activation Tasks

Important:

Before you can model Activation tasks in Design Studio, you must install the Design Studio for Order and Service Management Integration feature. This feature includes the Design Studio for Activation feature for integrating with ASAP and IP Service Activator. To model activation tasks, you must also install the Design Studio for Activation feature.

An activation task is a type of automated task that provides an integration between OSM and ASAP or OSM and IP Service Activator. By using activation tasks, you can model a process flow that includes one or more tasks that activate services in a network.

Note:

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

The interaction between OSM and ASAP or OSM and IP Service Activator is established through a Web request and response, which you configure by mapping OSM task data to ASAP parameters or to IP Service Activator parameters.

  1. OSM transforms order data into an operations support system through Java (OSS/J) message or a Web Service message and sends it to ASAP or to IP Service Activator. To model this, you configure service action request mapping, to map OSM data to ASAP data or to map OSM data to IP Service Activator data. See "About Service Action Request Mapping" for more information.

  2. ASAP or IP Service Activator receives the data, activates the service, and returns a success or failure status to OSM. To allow OSM to handle the returned data, you model service action response mapping. See "About Service Action Response Mapping" for more information.

Other elements specific to activation tasks are:

  • You can configure state and status transitions for completion events and exceptions returned by ASAP or IP Service Activator.

  • You can configure how to handle amendment processing with activation tasks.

  • If you are sending JMS OSS/J messages, Oracle recommends that you configure JMS store and forward (SAF) queues to manage the connection to ASAP or to manage the connection to IP Service Activator.

  • If you are sending Web Service messages, Oracle recommends that you configure Web Service SAF queues to manage the connection to ASAP or to manage the connection to IP Service Activator.

Figure 5-8 shows activation task details.

Figure 5-8 Activation Task Details

Shows activation task details.

About Service Action Request Mapping

You send fulfillment data to ASAP or to IP Service Activator as a service action request. To model a service action request, you map OSM header data (information that applies to the customer or to all order line items on the order) and OSM task data to the following service order activation data:

  • Activation order header: Information that applies to the entire work order.

  • Service action: Information that is required to activate a service.

  • Global parameters: Information that you define once and which applies to multiple service actions.

Figure 5-9 shows service action request modeling in Design Studio.

Figure 5-9 Service Action Request Modeling in Design Studio

Shows service action request modeling in Design Studio

About Service Action Response Mapping

After ASAP or IP Service Activator activates a service, it returns information to OSM. You create data structures in OSM to contain the response information returned from ASAP or IP Service Activator. For each event and exception returned by ASAP or IP Service Activator, you select the ASAP or IP Service Activator data that you want to retain, then identify the OSM data structure to which that data is added. When ASAP or IP Service Activator returns an event or exception, OSM updates the order data with the ASAP or IP Service Activator data that you specified.

Tip:

The amount of response data from ASAP or IP Service Activator can be very large, though the data that is needed might be small. Parsing large amounts of ASAP or IP Service Activator response data can affect OSM performance. If you notice a reduction in OSM performance due to large amounts of ASAP or IP Service Activator response data, you can specify a condition on specific parameters to limit the ASAP or IP Service Activator response data.

Figure 5-10 shows service action response modeling in Design Studio.

Figure 5-10 Service Action Response Modeling in Design Studio

Shows service action response.

About State and Status Transition Mapping

You can configure state and status transitions to manage completion events (for example, activation complete) and errors returned by ASAP or returned by IP Service Activator. You can define multiple transitions to model different scenarios for variations in the data received from ASAP or received from IP Service Activator. For example, if an ASAP parameter or IP Service Activator parameter returns the value DSL, you may want the task to transition to a DSL task; when the same parameter returns the value VOIP, you want the task to transition to a different task.

You can define state transitions for user-defined states only; you cannot define transitions for system states, such as Received, Accepted, and Completed. At run time, OSM evaluates the conditions in the order and stops evaluating when a condition evaluates to true. Completion events and errors must include a default transition in case all specified conditions fail.

About Activation Tasks and Amendment Processing

You can configure how to manage an activation task if the associated order undergoes amendment processing. The options are:

  • Intervene manually.

  • Do not perform any revision/amendment.

  • Have OSM redo the activation task, using the previously defined request mapping.

  • Have OSM redo the task, using different request mapping.

Understanding Processes

A process is a sequence of tasks and subprocesses that run consecutively or concurrently to fulfill all or part of an order. Any number of processes can be defined, consisting of any number or combination of manual and automated tasks. Subprocesses are processes that are launched from another process, as opposed to being launched from an order.

Figure 5-11 illustrates a simple process and its tasks, as shown in Design Studio:

Figure 5-11 Example of an OSM Process

Graphic is described in surrounding text.

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

  1. OSM runs the process. 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 services operation that reads a database to determine if the service is available at the specified address.

    Note:

    This example is a simplified example. A more complete process would have a failure path from this task, typically a fallout task to manage the order if the service is not available at that address.
  2. After verifying that the service is available, the process branches to two tasks that are independent, and can run in parallel:

    1. The Ship ModemSelf-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.

    As the tasks are processed, they are displayed in the Task Web client. Figure 5-12 shows two parallel tasks displayed in the Task Web client. They can be completed separately.

    Figure 5-12 Parallel Tasks Displayed in the Task Web Client

    Shows parallel tasks displayed in task web client.
  3. After the Assign Port task is finished, the Activate DSLAM task can run. This task contains an OSM integration with ASAP, IP Service Activator, or any 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.

  4. 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 manual tasks are completed, the order is complete.

Any of the tasks in this process could be configured as automated tasks. For example, the Assign Port task could be an automated task if there was an integration with the inventory system, and the inventory system was able to return the port number for the service.

For a detailed example of a process, see OSM Developer's Guide.

About Workflow Processes and Workstream Processes

A workflow process is a standard OSM process. A workstream process is a special type of process that is run differently from a workflow process in the Task Web client.

With a workflow process, the Task Web client displays the worklist after it completes each task. This is because a workflow process is intended to distribute work among different users in different workgroups. The next task in the process might be handled by a different user.

With a workstream process, OSM displays the order editor page for the next task automatically without first returning you to the worklist. Next and Back buttons allow you to navigate through the sequence.

A workstream process can include manual and automated tasks. If an automated task occurs, OSM processes it and displays a message indicating that processing is taking place. While automated processing is occurring in the workstream, you can return to the worklist to work on other tasks. The automated task in the workstream will continue to progress to completion. This is useful if the automated task in the workstream takes some time.

After the automated task finishes, and the next task becomes available, any user in the workgroup can pick up the workstream from that point. When the final task in a workstream completes, OSM returns you to the worklist. OSM automatically displays the order editor page for the next manual task in the workstream to the user.

About Modeling Processes

Processes have a single entry point and one or more exit points. When you create the process structure, you must place the tasks in the order in which the process is to complete them.

In addition to running tasks and subprocesses, you can control how a process runs; for example, specify to delay processing a task or redirect the process to another process.

Note:

Redirecting a process is useful for backwards-compatibility, but is not recommended. An order that has been redirected cannot use amendment processing.

About Process Properties

You can specify the following properties to processes:

  • The expected duration. This information can be used for jeopardy notifications and for reporting.

  • If you want this process to appear in the Process History - Summary Table window in the Task Web client.

  • If the process is a workstream process. See "About Workflow Processes and Workstream Processes" for more information.

Figure 5-13 shows process Start properties in Design Studio.

Figure 5-13 Process Start Properties

Shows process start properties in Design Studio.

About Process Activities

You use process activities to design how the process runs. Figure 5-14 shows the Activities options in Design Studio. The example process includes a timer delay between the two tasks.

Figure 5-14 Process Activities Options in Design Studio

Description of Figure 5-14 follows
Description of "Figure 5-14 Process Activities Options in Design Studio"

In addition to the tasks and subprocesses that the process runs, you can control the process by using the following:

  • Rules

  • Timer delays

  • Event delays

  • Joins

  • Ends

  • Redirects

Rules evaluate a condition and then specify the next step in the process. For example, a rule task might evaluate the data that describes the geographic region of the order and branch the process appropriately. Rule tasks perform as follows:

  • They typically read and evaluate data to determine what to do.

  • They always evaluate to true or false.

  • They are always run automatically, with no manual involvement.

Timer delays delay the process until a rule evaluates to true. Timer delays perform as follows:

  • The rule is evaluated at specified timed intervals.

  • The data evaluated in the rule must be data that is included in the order.

  • The rule always evaluates to true or false.

  • The delay is always run automatically, with no manual involvement.

Event delays delay the process until a rule evaluates to true. Event delays perform as follows:

  • The rule is evaluated only when the data specified in the rule changes.

  • The data evaluated in the rule must be data that is included in the order.

  • The rule always evaluate to true or false.

  • The delay is always run by OSM, with no manual involvement.

Joins combine a set of flows into a single flow. (Process flows define the sequence of tasks that the process performs. See "About Flows" for more information.) The unified flow can join flows based on all transitions completing or any one transition completing (by selecting All or selecting Any). Selecting Any will create one instance of the flow for each incoming transition.

Ends stop the process from continuing.

Redirects redirect the process to another task in the same process or to a different process.

Note:

Timer and event delays are not used during amendment processing.

Using the System Date in Delays

You can create a rule that uses the system data as part of a condition. For example, you can create a rule used in a delay that delays a task transition for one day after the system date. To do so, the data in the rule must be of the dateTime data type. Figure 5-15 shows a rule that triggers one day after the system date.

Figure 5-15 Using the System Date in a Rule

Shows a rule that triggers one day after system date

About Flows

Process flows define the sequence of tasks that the process performs. You can design flows for specific scenarios, including:

  • A flow that ends in a successful process completion (Success) or a process failure (Failure).

  • Flows for various activities, such as Cancel, Next, and Back.

Figure 5-16 shows how flows appear in a process in Design Studio. In this figure, flows are labeled with the task status; for example, route_to_osm.

Figure 5-16 Flows in a Process

Graphic is described in surrounding text.

You can control flows in the following ways:

  • You can use an order rule to apply conditions that must be met before the flow can continue.

  • You can ensure that the system verifies that mandatory fields are present when a task completes. (This option is not available for tasks with a Rollback status.)

  • You can specify a reporting status to display in an OSM Web client. This status is tracked in the Web client's OSM history.

Figure 5-17 shows flow properties in Design Studio.

Figure 5-17 Flow Properties

Shows flow properties in Design Studio.

About Subprocesses

A process that starts from another process is called a subprocess.

Figure 5-18 shows a process (Process A) that has two branches. In one branch, a task completes successfully and the process ends. In the other branch, the task fails, which starts a subprocess. When the subprocess ends successfully, the calling task is completed and Process A completes.

Figure 5-18 Subprocess Example

Graphic is described in surrounding text.

When you model subprocesses, you specify the following properties:

  • If you want the associated tasks to appear in the Process History window in the Task Web client.

  • The pivot data element on which OSM spawns individual subprocess instances. For example, if you have subprocess that creates an email address for every person in a list, you might select the Person data element as the pivot data element, so the subprocess spawns an instance for each person. See "Generating Multiple Task Instances from a Multi-Instance Field" for more information.

  • How to display the associated tasks in the Task Web client. For example, you can display them sequentially, sorted, or unsorted.

  • The process to run, based on rules.

  • How the subprocess handles exceptions. For example, you might have a process called create_vpn. Within that process, there is a subprocess called validate_address. The subprocess validate_address can throw an exception when an address is invalid. Using the exception mapping functionality, you can instruct the parent process and subprocesses to take specific actions when the subprocesses throw exceptions. Exception mapping enables you to indicate whether the parent process create_vpn should terminate all of the invoked instances, terminate only the offending instance, or ignore the exception altogether.

Understanding Parallel Process Flows

There are two ways to model parallel processes:

  • Subprocesses branching from a task. This allows multiple tasks to run within the same time frame. Parallel flows can be rejoined at an appropriate point if needed. Typically, there are no dependencies defined between parallel flows, but whether these tasks actually run simultaneously depends on the order data, how order tasks are fulfilled, and other factors.

  • Subprocesses running from a pivot data element. Multi-instance subprocesses are subprocesses that can be instantiated multiple times. When a subprocess has a pivot data element defined, multiple instances of the subprocess, running in parallel, are created. For example, if the pivot data element for a subprocess is defined as interested_party, and an order contains three instances of interested_party, each containing a different person's name and contact information, OSM creates three separate instances of the subprocess, one for each set of data.

When planning your order specifications, give careful consideration to which data you make available to each parallel process. Excessive and unnecessary data can have negative impacts on performance, and on usability if manual tasks are involved. Also, make sure to flag data as non-significant if the data is not needed for revision orders. By default, OSM assumes that all data is significant.

About Amendments and Multi-Instance Subprocesses

An amendment to an order on which some of the data affecting a multi-instance subprocess has changed can cause all subprocess instances to be redone, instead of only directly affected subprocesses to be redone. This can result in unneeded processing for the subprocesses with no data changes.

In amendment processing with multi-instance subprocesses, it is important to contain compensation to only the subprocess instances that require compensation. This is achieved by specifying a key. You specify a key in the Key subtab on the Order Template Node editor for the data element specified as the pivot data element of the subprocess in the order template. When a key is specified for a subprocess, OSM maps the revised data to the current data using the key field and redoes only the subprocess that was affected.