Use the Task editor to model the tasks you use in your processes to offer a specific service to a customer. Each task type has its own set of tabs in the Task editor. The following table lists the Task editor tabs that appear for each task type.
| Tab Name | Manual Task | Automated Task | Activation Task | Transformation Task |
|---|---|---|---|---|
| Task Editor Activation Task Details Tab | No | No | Yes | No |
| Task Editor Automation Tab | No | Yes | No | Yes |
| Task Editor Behaviors Tab | Yes | No | No | No |
| Task Editor Compensation Tab | Yes | Yes | No | Yes |
| Task Editor Details Tab | Yes | Yes | Yes | Yes |
| Task Editor Events Tab | Yes | Yes | Yes | Yes |
| Task Editor Fallouts Tab | Yes | Yes | No | Yes |
| Task Editor Jeopardy Tab | Yes | Yes | Yes | Yes |
| Task Editor Permissions Tab | Yes | Yes | Yes | Yes |
| Task Editor Redo Tab | No | No | Yes | No |
| Task Editor Request Data Tab | No | No | Yes | No |
| Task Editor Response Data Tab | No | No | Yes | No |
| Task Editor Composite Data View Tab | Yes | Yes | No | Yes |
| Task Editor States/Statuses Tab | Yes | Yes | Yes | Yes |
| Task Editor Task Data Tab | Yes | Yes | No | Yes |
| Task Editor Undo Tab | No | No | Yes | No |
The following field is common to multiple tabs in the Task editor:
| Field | Use |
|---|---|
| Description | Edit the display name of the task. |
The Task editor Activation Task Details tab appears for activation task types.
Use the Activation Task Details tab to define the attributes that enable the activation task to execute properly in the Activation environment. For example, you can associate an activation task with an order, specify the user to run this task, and provide the details for the response queue name, maximum cache size, and cache time-out.
| Field | Use |
|---|---|
| Activation System | Displays the activation system against which the activation task is registered. |
| Run As | Enter the OSM user name (security principal) that can execute this task. A password is not necessary to authenticate this user because only an administrator has the authority to deploy components into the server.
Ensure that the user is set up in the WebLogic Server console. For more information about setting up users and groups, see OSM System Administrator's Guide. Note: Oracle recommends using the DEFAULT_AUTOMATION_USER cartridge model variable in the Run As field. See "Project Editor Model Variables Tab" for more information. |
| Maximum Number in Cache | Specify the maximum number of entries in the cache that are maintained at any one time. |
| Cache Timeout | Specify the number of seconds for which the cache is valid. |
| Exception | Select the exit status to use when an exception occurs during the activation task processing. Status options include any status values you assigned to the task. |
| Activation Order ID Node | Select a data node to store the order ID. The activation order ID is used by the defined compensation strategy when a task is affected by amendment processing. See "Task Editor Redo Tab" and "Task Editor Undo Tab" for more information. |
| OSSJ | Enter the location to which OSM sends OSSJ service action requests. Configure this attribute if you want to connect to an ASAP instance using Java message service (JMS).
Depending on how you set up your cartridge project model variables, you can use the default values or define your own queue location names. See "Project Editor Model Variables Tab" for more information. |
| Web services | Enter the location to which OSM sends web services service action requests. Configure this attribute if you want to connect to an activation system instance using web services messages. You must also configure the Map and Key fields to secure the web services messages.
Depending on how you set up your cartridge project model variables, you can use the default values or define your own queue location names. See "Project Editor Model Variables Tab" for more information. |
| Map and Key for Activation Credential | ASAP and IP Service Activator secure web services service actions with a web services user name and password located in the activation system WebLogic server. You must store this user name and password within the Fusion Middleware Credential Store Framework (CSF) using the credStoreAdmin.bat tool located in the OSM_home/SDK/XMLImportExport folder, where OSM_home is the location where the OSM software is installed. The credStoreAdmin.bat tool creates a map and a key that corresponds to the ASAP Web Services user name and password. For more information about this tool, see the OSM System Administrator's Guide. |
| Environment ID | Enter the activation system environment ID to which the service action requests are sent.
Note: When you create cartridges, some of the variable information to define may depend on a specific environment. If you do not have environment specific values for variables that you will need at run time, you can create tokens for the variables and later define specific variable values for each environment in which you will use the variable. Tokens are place holders for environment-specific values that can be defined at the time of deployment. See "Project Editor Model Variables Tab" for more information. |
| Response Queue | Enter the JNDI name of the response queue on which this automator listens. If you do not enter a value, the system uses a default value. Values must be defined in WebLogic Server.
Design Studio populates this field with a default value if service action requests are configured to be submitted using OSSJ. When service action requests are configured to be submitted using web services, you must define a response queue. |
| JMS topic for events | Enter the location to which service action responses are sent. Depending on how you set up your cartridge project model variables, you can use the default values or define your own topic location names. See "Project Editor Model Variables Tab" for more information.
If you are using store and forward (SAF) to communicate to an ASAP instance located on a different WebLogic server, Oracle recommends selecting the Use a queue check box to use a queue instead of a topic. For more information about SAF, see the OSM Installation Guide. |
The Task editor Automation tab appears for automation and transformation task types.
The Automation tab displays a list of automation plug-ins registered against the automated task. When the OSM server encounters the task during run-time it triggers the plug-ins to begin the work that they are designed to perform.
When modeling automated tasks in the Automation tab, see the following topics for more information:
| Field | Use |
|---|---|
| Name | Displays the name of the automation plug-in. Click the value in the Name column to change or edit the name.
Note: Design Studio displays the automation plug-ins in the Automation tab alphabetically in ascending or descending order. The order in which the plug-ins appear does not indicate or affect the order in which the plug-ins will perform during run time. When you have multiple automation plug-ins registered against an automated task, you must ensure that the plug-ins are consuming only those messages that are pertinent to the plug-in operation. See "Properties View External Event Receiver Tab" for information about how to filter for specific message properties. |
| Type | Displays the automation plug-in type. There are two basic types of built-in automation plug-ins: Sender and Automator. Each type can be implemented by an XSLT style sheet or by XQuery. Additionally, you can create your own custom plug-in using the customer plug-in template. See "Working with Automation Plug-Ins" for more information.
Note: XQuery automation types cannot be implemented when using releases prior to OSM 7.0. |
| Event Type | Displays whether an automation plug-in receives data from an external system queue or from an internal OSM queue. See "Configuring Automation Plug-In Properties" for more information. |
| Properties | Select an automation plug-in from the Automation table and click Properties to access the Automation Plug-in Properties tabs. See "Configuring Automation Plug-In Properties" for more information. |
| Remove | Select an automation plug-in from the Automation table and click Remove to delete the automation from the list of plug-ins registered against the task. |
| Add | Click to add an automation plug-in to the list of plug-ins registered against the task. See "Adding Automation Plug-ins to Automated Tasks" for more information. |
Use the Properties view Detail tab to define information that is common to all types of automation plug-in and event receiver types.
| Field | Use |
|---|---|
| Name | Enter a plug-in name. The name must be unique among plug-in entities in the same namespace.
Note: While plug-in names can be any arbitrary name that you assign to the automation, Oracle recommends that you use a consistent naming pattern for all of the automations that you create. |
| EJB Name | Edit the system-provided default EJB name. The default value with which Design Studio initially populates this field depends on where the automation is defined:
Note: The EJB name must be unique per OSM server. However, as there is no method for predicting to which OSM server the cartridge will be deployed, you should ensure uniqueness across all automation plug-ins defined for a cartridge. The default EJB name guarantees this uniqueness; therefore, Oracle recommends that you do not change the defaulted EJB name. See "Working with Jeopardy and Event Notifications" for more information jeopardy and event notifications. |
| Run As | Enter the OSM user name (security principal) whose credentials are used to execute this automation plug-in. A password is not necessary to authenticate this user because only an administrator has the authority to deploy components into the server.
The value of this field must reflect the user ID that is used to run the automation:
Note: Oracle recommends using the DEFAULT_AUTOMATION_USER cartridge model variable in the Run As field. See "Defining Model Variables" for more information. |
| Event Type | This field is enabled only for automations defined for automated tasks. Select one of the following:
Note: If you intend to secure automations such that different user IDs have access to run different automations, Oracle recommends that you incorporate these changes after you ensure that the automations are working successfully. Changing a plug-in's automation event type may result in the loss of any data that is not common between the event receiver types. |
| Fail Task on Automation Exception | Select this check-box to fail the task if an exception occurs when running the automation plug-in. The plug-in can throw any exception and OSM retries the plug-in as many times as configured on the JMS destination retry. On the last retry attempt OSM fails the task and logs the exception message as the failure reason. |
Use the Properties view External Event Receiver tab to define how OSM retrieves and processes messages placed on the queue by external systems.
The Properties view External Event Receiver tab appears only for Automator and Sender plug-in types defined as external event receivers. External event receivers listen to external system queues or topics for JMS messages. To define a plug-in as an external event receiver, select the External Event Receiver option on the Add Automation dialog box when creating a new automation entry.
| Field | Use |
|---|---|
| JNDI Name | Enter the name of the external system from which the plug-in receives messages. JNDI Name is mandatory and contains a system-supplied default value which you must change to reflect your own system topology. The JNDI Name must be unique in the workspace.
The default value with which Design Studio initially populates this field depends on where the automation is defined:
|
| Destination Type | Select the type of the response destination. A JMS destination is either a javax.jms.Queue or a javax.jms.Topic. Topics are generally used when messages are published for general availability to multiple external systems. Queues are generally used if the sender wants only a single external system to consume the message. |
| URL, Initial Context Factory, Connection Factory | (Optional) Enter this information to connect to an external application server. Specify the URL and the InitialContextFactory class for the JNDI provider, and specify the ConnectionFactory class for the JMS server. |
| Message Property Selector | Enter a selector based on the message properties applied to the external queue. Using an XPath expression or query statement in this field enables you to filter incoming messages to only those messages with specific properties defined at the header level. Using a message property enables you to interrogate the message on the external queue and determine which plug-in should perform the processing of this task instance.
When you have multiple plug-ins with identical event receiver types defined for a task, the OSM server will select the first plug-in whose message property selector evaluates to true. A message on an external JMS queue can be consumed only once. Consequently, it is critical to ensure that your plug-ins consume the appropriate messages. Useful properties for selection include source, type, process, process status, or priority. For example, for a single task, you might create multiple external event receiver Automator plug-ins, each defined with a mutually exclusive message property to distinguish between task priority levels, where one plug-in processes tasks defined as high priority, and a different plug-in processes tasks defined as low priority. Note: See the JMS specification for the syntax of this selector expression on the Oracle Technology Network website at:
Note: When you define only one automation plug-in external event receiver for each automated task, and you use the Optimized build-and-deploy mode to build and deploy automation plug-ins, you are not required to enter a selector in the Message Property Selector field. (For OSM 7.3 servers and later, Optimized is the only build-and-deploy mode available.) In this case, automated tasks can share the same JMS queue without a message property selector being set. You must set a message property selector when you do either of the following:
Note: XPath and XQuery fields are limited to 4000 characters. |
| XML Message Body Selector | In the Select field, enter an XPath expression to select an element from the XML body content. In the Compare field, enter the string value of the element to determine the match. Using an XPath expression in this field enables you to filter incoming messages to only those messages defined with specific properties in the body of incoming messages.
The XML Message Body Selector function is deprecated, but it is supported for backward compatibility. Oracle recommends that you use an alternate way of filtering messages such as message property selector. For example, the following sample response from the external system includes a <typeOrder> element that defines the order type:
<orderResponse xmlns="http://xmlns.oracle.com/communications/sce/dictionary/OsmCentralOMExample/interactionResponse" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<numSalesOrder>1</numSalesOrder>
<numOrder>3</numOrder>
<typeOrder>NEW</typeOrder>
<errorCode>0</errorCode>
<message>OK</message>
<status>A</status>
</orderResponse>
For this example response, to consume only the NEW type of order, you can use either of the following in the Select field:
In both cases, you would set the Compare field to NEW. All selected messages that contain a typeOrder parameter value of NEW (for example, as opposed to Revision, or Follow-On) would be directed to the automation plug-in. Note: You can use the XML Message Body Selector with response messages of type XMLMessage. OSM ignores the selector for other message types, such as TextMessage. If you need to use the message body selector ensure that messages are of type XMLMessage message. For non-XMLMessage messages you are restricted to the Message Property Selector. Note: XPath and XQuery fields are limited to 4000 characters. |
Example: Modeling a Basic Automator Plug-In
Use the Properties view Compensation tab to define the execution modes that automation plug-in can process. This tab appears only for Automator and Sender plug-in types defined as an Internal Event Receiver.
| Field | Use |
|---|---|
| Execution Mode | Specify the execution modes that this plug-in can run when invoked. For more information about execution modes, see "About Task Compensation".
Select one of the following execution modes from the Normal column for execution modes that occur when the task is processing normally:
Select one of the following execution modes from the Fallout column for execution modes that occur when the task has failed:
Note: Design Studio has validations in place that prevent you from defining more than one internal event receiver automation with the same execution mode per automated task or automated notification. For example, an automated task can not define two internal event receiver automations that both have Do selected for the execution mode. However, an automated task can define three internal event receiver automations if each defines a different execution mode (Do, Redo, and Undo). |
Example: Modeling a Basic Automator Plug-In
Use the Correlation tab to specify how an in-bound response from an external system correlates back to the original outbound message that initiated the communication with the external system.
The Properties view Correlation tab appears only for Automator and Sender plug-in types defined as external event receivers. The Correlation parameter is mandatory and defaults to Message Property, which in turn defaults to JMSCorrelationID.
| Field | Use |
|---|---|
| Correlation | Select the method for correlating responses from external systems with the originating response:
The Correlation parameter is mandatory and defaults to Message Property, and the system sets the corresponding default value for the Message Property field to JMSCorrelationID. |
| Message Property or XML Body | This field is conditional to the selection that you make in the Correlation field. If you selected Message Property in the Correlation field, the system supplies the standard JMS correlation property JMSCorrelationID. The OSM order correlates with incoming events from external systems when the JMSCorrelationID on the order and on the message matches.
If you selected XML Body in the Correlation field, you can enter an XPath expression to point to an element in the XML body of the message. The value for this element in the OSM order must match the value for the same element on the incoming message. Note: XPath and XQuery fields are limited to 4000 characters. |
About Automation Message Correlation
Use the XQuery tab to specify your XQuery file so the predefined automation plug-in can access it. This tab appears for XQuery type plug-ins only.
Note:
XQuery automation types cannot be implemented when using releases prior to OSM 7.0.| Field | Use |
|---|---|
| Script | Specify which method to use to retrieve the XQuery file. Select from the following options:
Note: Oracle recommends that you select Bundle in for production mode, as this mode pulls the files into the OSM PAR file. As a result, you can deploy the EAR file (which contains the PAR file) to any server and, at run time, the application can locate the files. If you select Absolute Path or URL for production mode, you can deploy the EAR file (which contains the PAR file) to any server but are responsible for ensuring the files reside in specified location on the server. Conversely, Absolute Path or URL are optimal for testing mode because they do not require a rebuild and redeploy to pick up changes to the XQuery. |
| Maximum Number in Cache | Specify the maximum number of XQuery files that can be maintained in the cache at any one time. |
| Cache Timeout | Enter the number of seconds before the OSM server refreshes the cache. |
| Exception | Select the exit status that the plug-in should use if it throws an exception. Status options include any status values you assigned to the task.
Note: This field does not apply to an automation plug-in for an order milestone automation event notification (at the order level); it applies to setting up an automation at the task level. |
| Update Order | Select this option if you want to update (add, change, or delete) the OSM order data with the data retrieved from an external system. This field appears for Automator automation plug-ins only. |
About Automation Message Correlation
Use the Properties view XSLT tab to specify the location of your XSLT file so the predefined automation plug-in can access it. This tab appears for all plug-ins except for custom plug-ins.
You can use XSLT to perform some business logic against a task, and determine the exit status based on the processing results. XSLT enables you to model complex calculations, such as date-based calculations, mathematical expressions, calls to external systems, and so forth. Additionally, you can update the order data with the results from your XSLT calculations. Finally, you can use the XSLT style sheet to transform data when sending and receiving data from external systems.
| Field | Use |
|---|---|
| Script | Specify which XSLT style sheet you want to use to transform documents. Select from the following options:
Note: Oracle recommends that you select Bundle in for production mode, as this mode pulls the XSLT files into the OSM PAR file. As a result, you can deploy the EAR file (which contains the PAR file) to any server and, at run time, the application can locate the XSLT files. If you select Absolute Path or URL for production mode, you can deploy the EAR file (which contains the PAR file) to any server but are responsible for ensuring the XSLT files reside in specified location on the server. Absolute Path or URL are optimal for testing mode because they do not require a rebuild and redeploy to pick up changes to the XSLT. |
| Maximum Number in Cache | Specify the maximum number of XSLT style sheets that can be maintained in the cache at any one time. |
| Cache Timeout | Enter the number of seconds before the OSM server refreshes the cache. |
| Exception | Select the exit status that the plug-in should use if it throws an exception. Status options include any status values you assigned to the task.
Note: This field does not apply to an automation plug-in for an order milestone automation event notification (at the order level); it applies to setting up an automation at the task level. |
| Transformer Factory | (Optional) If you have developed a custom TransformerFactory for XSLT transformation, specify the location. Design Studio provides a default TransformerFactory. |
| Update Order | Select this option if you want to update (add, change, or delete) the OSM order data with the data retrieved from an external system. This field appears for Automator automation plug-ins only. |
Example: Modeling a Basic Automator Plug-In
Use the Properties view Routing tab to specify where to send XML messages and where external systems can deliver responses. The Properties view Routing tab appears for all non-custom XSLT Sender plug-ins.
On the Routing to subtab you can specify where to send the XML Request message (JMS Destination). On the Routing Reply to subtab you can specify where the external system can deliver the XML Response or Exception message.
| Field | Use |
|---|---|
| JNDI Name | Enter the name of the queue to which the automation plug-in sends messages (on the To tab) or to which external systems send response (on the Reply To tab). JNDI Name is mandatory. Edit the system-supplied default value to reflect your own system topology. The JNDI name must be unique in the workspace. |
| Destination Type | Select the type of the message destination. A JMS destination is either a javax.jms.Queue or a javax.jms.Topic. You might use a topic, for example, if you want to publish messages for general availability to multiple external systems (on the To tab) or subscribe to a queue with multiple listeners (on the Reply To tab). You might use queues if you want only a single external system to consume the message. |
| URL, Initial Context Factory, and Connection Factory | (Optional) Enter this information to connect to an external application server. Specify the URL and the InitialContextFactory class for the JNDI provider, and specify the ConnectionFactory class for the JMS server |
| Send Null Message | Select this option if you want to send a JMS message to an external system even if the message body is empty. |
Example: Modeling a Basic Automator Plug-In
Use the Properties view Custom Plug-in tab to define a custom automation plug-in entity in Design Studio. The Custom Automation Plug-in editor associates a Java class representing the custom automation plug-in to the custom automation plug-in entity.
This tab appears when the selected plug-in is a custom automation plug-in. The value is initialized with the value of the XML template for the type of custom automation plug-in.
See OSM Developer's Guide for more information about defining the custom automation plug-in.
Example: Modeling a Basic Automator Plug-In
Use the Properties view Notes tab to describe the intended use for the plug-in. The Properties view Notes tab is common to all types of automation plug-ins and event receiver types.
Example: Modeling a Basic Automator Plug-In
The Task editor Behaviors tab appears for manual task types.
Use the Behaviors tab to view all of the behaviors defined for the data nodes in a manual task.
The Behaviors table displays the name and type of the task, whether the behavior is enabled, the inheritance properties, the path name of the data node on which the behavior is defined, and the task where the behavior was originally defined.
The information on the Behaviors tab is read-only. To change the information that appears on this tab, select a behavior from the table and click the Properties button to access the Behaviors Properties tabs. See "Working with Behaviors" for more information about the defining behavior properties.
The Task editor Compensation tab appears for manual, automated, and transformation task types.
Use the Compensation tab to define your compensation strategy for manual and automated tasks.
| Field | Use |
|---|---|
| When this task needs to be re-evaluated, compensate by: | A task is re-evaluated by the system if it has visibility to order data (data that is defined as significant) that has changed as a result of an order amendment or as a result of amendment compensation performed on another task to which the task has visibility. The default option, which is to redo the task, applies to tasks that are linear in nature and have the same completion status (no branching).
Select Redo (one single operation) to instruct the system to perform Undo and Do operations in a single operation. This option is recommended, when possible, as it performs the fewest number of Undo and Do operations necessary for compensation. Select Undo then do (two separate operations) to undo this task and all successor tasks and roll back all order changes, then perform the Do operation again. Use this option to rollback all order changes and re-perform the task from the beginning. Select Do Nothing to instruct the system to bypass updating the affected task. For example, you might select this option if a similar task downstream in the process will be compensated, thereby optimizing the compensation plan. Select Compensation Expression to create an XQuery expression in the Compensation Expression field that dynamically selects a compensation strategy (Redo, Undo then do, or Do nothing) based on revision order data. For more information about compensation strategy XQuery expressions, see "Compensation XQuery Expressions". |
| When this task is no longer required, compensate by: | A task or subprocess is no longer required when:
In both scenarios, the system rolls back the order changes. The difference between them is the creation of a compensation undo task. Undoing the task and rolling back order changes creates an undo task; automatically rolling back order changes does not create an undo task. Undo compensation tasks created for manual tasks appear in the Task web client Worklists and must be manually acknowledged in order to be rolled back. Select Undo to create an undo read-only task in the Task web client. Select Do Nothing to instruct the system that no compensation is necessary. Select Compensation Expression to create an XQuery expression in the Compensation Expression field that dynamically selects a compensation strategy (Undo or Do nothing) based on revision order data. For more information about compensation strategy XQuery expressions, see "Compensation XQuery Expressions". |
| When an amendment occurs this task will be compensated if it is: | Most tasks should only be included in amendment processing after the task has completed. However, you may want to include in progress tasks in amendment processing when the tasks are long running, for example when interacting with a workforce management system where task fulfillment can take hours or even days to complete.
Select Completed to instruct the system to include the task in amendment processing only when the task is completed. Select Completed or in progress to instruct the system to include the task in amendment processing when the task is completed or when the task is in progress. A task is considered to be in progress when the task is in the Accepted state or in any user-defined state. You can also further refine when an in progress task is included into amendment processing by specifying the In Progress Compensation Include Expression and the In Progress Compensation Complete Expression XQuery expressions. Select In Progress Compensation Include Expression to create an XQuery expression that further specifies when instances of this in progress task can be included in amendment processing based on revision order data. For example, the expression may determine that the task only be included in amendment processing when it includes product A rather than product B. For more information about compensation strategy XQuery expressions, see "Compensation XQuery Expressions". Select In Progress Compensation Complete Expression to create an XQuery expression in the Compensation Expression field that runs whenever data is updated on the task that checks when compensation has completed based on the order data changes. For example, the order amendment could specify that the task run in redo mode. The task re-sends a request for a customer service with changes to an external fulfillment system that returns an acknowledgement response that the XQuery expression recognizes as completing the compensation for the in progress redo task. The task can then return to the normal do execution mode and waits for the external system to functionally complete the task and respond so that the task can be completed. For more information about compensation strategy XQuery expressions, see "Compensation XQuery Expressions". |
| When an amendment occurs if this task is in progress it will: | If amendment processing occurs while a task is in progress, you can specify what kind of grace period should be enforced before the task can run in the compensation execution mode.
Select Wait for the grace period to instruct the task to run in the compensation execution mode when the grace period specified on the order-life cycle for the Process Amendment transition. Select Be excluded from the grace period to instruct the task to run immediately regardless of the grace period specified on the order-life cycle for the Process Amendment transition. Select Wait for specified duration to statically configure the grace period for the task by seconds, minutes, hours, or days. Select Dynamic Expression to create an XQuery expression that dynamically specified the wait duration based on revision order data. This expression runs regardless of what option is specified from the above list. For more information about compensation strategy XQuery expressions, see "Compensation XQuery Expressions". |
Note:
Although compensation strategies are defined on an individual task basis, they must be analyzed within the context of the workflow.The Task editor Details tab appears for manual, automated, activation, and transformation task types.
Use the Details tab to define attributes that you can use to extend the task definition.
For all tasks in a process, there are properties that you define in Design Studio that the OSM server requires to properly execute the task. These properties include the order with which the task is associated, the amount of time in which you expect the task to complete, the group responsible for completing the task, and the manner in which the tasks are assigned. You configure these details on the Task editor Details tab. The Details tab also contains properties that enable you to add or remove a parent task (and its inherited data), and to model the data node on which a multi-instance process relies to create multiple instances of the task.
| Field | Use |
|---|---|
| Extends | Select an existing or create a new task to extend this task (the task's data is inherited) by clicking the Select button. To create a new task that this task would be an extension of, click New. After you have selected or created an task, click Open to access the Task editor. Click Clear (red X) to clear the selected value from the field.
Using task inheritance, you can leverage existing task data when building new, similar tasks. See "About Task Extensions and Inheritance" for more information. |
| Order | The order associated with a task determines the overall data set that will be available to the task when you model the task data.
Note: If you are planning to use the task for an order (OrderA) and also an order (OrderB) that is extended from that order, you must select the parent order (OrderA) here. |
| Pivot Node | (Optional) Select the Pivot node for this task. When OSM executes the corresponding task at run-time, the system generates a separate task instance for each separate value of the pivot node in the order. For example, if the pivot node is an address field, and three addresses are included in the order, the system generates three separate task instances when this task occurs in a process.
Note: OSM compensation processing does not support task pivot nodes. |
| Expected Duration and Calculate using Workgroup Calendar | Specify the length of time expected to complete the task. By default, the expected duration of a task is set to 1 day (system time). You can select any value up to 999 in weeks, days, hours, minutes, or seconds.
You can also calculate the duration based on your workgroup calendar by selecting Calculate using Workgroup Calendar. 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. Expected durations can be useful during reporting and jeopardy processing. |
| Order Priority Offset | Select a value between 9 and -9 to differentiate this task's priority within 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 other tasks in the order 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. |
| Responsibility | Select which department or team is responsible for this task. The default value is System.
You can select System or enter a value that is meaningful within the context of your system topology. This field is only visible to the reporting API. |
| Namespace Based on Task Name | (Automated, Activation, and Transformation tasks only)
Select this option to use a namespace for the task that is based on the task name. |
| Assignment Algorithm | (Manual tasks only)
(Optional) Select the algorithm to use when automatically assigning tasks to users. OSM provides two default algorithms: Load Balancing and Round Robin. The Load Balancing algorithm attempts to distribute tasks based on a user's current workload. The OSM server assigns tasks after determining which user in the workgroup has the fewest number of assigned tasks. The Round Robin algorithm assigns tasks in a predefined order among the users in the workgroup. You can add custom assignment algorithms to OSM, using OSM's cartridge management tools. For custom algorithms, you must manually enter the algorithm name in the Assignment Algorithm field. If you do not specify an algorithm in this field, you must manually assign tasks. |
| JNDI Name | (Manual tasks only)
Enter the JNDI name for custom assignment algorithms. |
| Transformation Manager | (Transformation tasks only)
Enter the name of the transformation manager to be called when this transformation task is reached. Do any of the following:
|
| Order Component | (Transformation tasks only)
Enter the name of the order component that provides context for this transformation task and assists in order item selection. Do any of the following:
If you are not using the default provided automation plug-in for the transformation task, this field may be optional, depending on the way your automation is written. |
| Update Order with Transformation Response | (Transformation tasks only)
Select this option to enable OSM to persist the transformed order items on the order. |
Note:
You cannot use pivot nodes to model multiple instances of activation tasks. To model multiple activation task instances, create a multi-instance subprocess that contains only the activation task.The Task editor Events tab appears for manual, automated, activation, and transformation task types.
Use the Events tab to create task state automation event notifications. You select the task state that triggers the automation, and then configure the automation plug-in that will perform the work.
| Field | Use |
|---|---|
| State | The State column displays the states for which you have defined automation events. When the task reaches the corresponding state, the OSM server triggers the automation event plug-in. |
| Name | In the Automation column, the Name field displays the name of automation plug-in. |
| Automation Type | Displays the automation plug-in type.
See "Working with Automation Plug-Ins" for more information. |
| Add | Click the State column Add button to add a predefined task state to the list. Click Add in the Automation column to define a new automation plug-in for the corresponding task state. |
| Remove | Select a state or an automation plug-in and click Remove to delete the entity from the list of events. |
| Properties | Select an automation plug-in and click Properties to configure the properties of the new plug-in. See "Configuring Automation Plug-In Properties" for more information.
The Properties button appears only after you have added at least one automation plug-in to the table. |
Creating Order Milestone and Task State Automation Event Notifications
The Task editor Fallouts tab appears for manual, automated, and transformation task types.
Use the Fallouts tab to specify the types of fallout that can occur for a task.
Click Add to open the Select Fallouts dialog box, where you can select fallouts previously defined on the Order editor Fallouts tab.
Select any fallout defined in the Name column and click Remove to delete the fallout from the list.
Select any fallout defined in the Name column and click Open to open the fallout in the Order editor Fallouts tab.
The Task editor Jeopardy tab appears for manual, automated, activation, and transformation task types.
Use the Jeopardy tab to create jeopardy notifications when certain conditions arise in a task and you want to alert users or systems of processes, orders, or tasks that may be at risk.
The Jeopardy tab has the following subtabs:
Use the Jeopardy Details tab to name the jeopardy, select the notification rule, set the priority level, enable or disable the notification, and specify whether to send the notification by email.
| Field | Use |
|---|---|
| Name | Enter a name to identify the jeopardy. |
| Rule | Select the rule the system should evaluate before generating this jeopardy. This field defaults to the system-based null_rule.
If you do not change the default value, OSM will always trigger this notification at the specified polling interval. See "Defining Order Rules" for more information about setting up new rules. |
| Priority | Enter a priority from 1 to 255 (1 is the highest priority). The notification with the highest priority is evaluated first. |
| Enabled | Select this option to enable this jeopardy notification, or deselect the option if you intend to implement the notification at a later time. |
| Select this option to send email notifications to all users in the workgroup associated with the specified role.
By default, notifications appear in the Notifications page of the Task web client. However, you can specify that notifications be sent by email by selecting the Email check box. When you assign users to a workgroup in the OSM Administration area of the Order Management web client, you can set up OSM to notify users by email. When a notification occurs, the system sends a notification ID number through email. See OSM Order Management Web Client User's Guide for information about configuring email notification properties for user roles. See OSM Installation Guide for information about configuring the outgoing email server. |
Creating Jeopardy Notifications in the Task or Order Editor
Use the Jeopardy Conditions tab to select the conditions under which the jeopardy should be raised. For example, you can raise a jeopardy when this task exceeds the expected or a given duration.
| Field | Use |
|---|---|
| Raise a Jeopardy when Process Duration Exceeds | Raise a jeopardy if the process to which the task is associated has exceeded the Expected Duration of the order (defined on the Order editor Details tab) or Given Duration, specified by the time interval defined in the adjacent field. |
| Raise a Jeopardy when Task Duration Exceeds | Raise a jeopardy if the task has exceeded the Expected Duration (defined on the Task editor Details tab) or Given Duration, specified by the time interval defined in the adjacent field. |
| Raise a Jeopardy when the order is received within | Raise a jeopardy if the order has been received and the time interval defined in the adjacent field has been exceeded. |
| Multiple events per Task instance | When a task has multiple instances, select this option if, when a jeopardy notification is triggered, you want a notification triggered for every task instance. |
Creating Jeopardy Notifications in the Task or Order Editor
Use the Jeopardy Notify Roles tab to select the roles to be notified when the jeopardy occurs.
Select a predefined jeopardy from the list in the left column to activate a list of available roles. For information about defining roles, see "Working with Roles". Using the directional arrow buttons, move the roles (those groups to whom you want the notification sent) into the Selected Column.
If the jeopardy notification is sent to an external system via an automation plug-in, ensure that you include the role whose credentials are used when running the automation plug-in. See "Configuring Automation Plug-In Properties" for more information.
Creating Jeopardy Notifications in the Task or Order Editor
Use the Jeopardy Polling tab to select the interval at which the OSM server evaluates the condition that triggers the jeopardy notification. You can define the polling so that the system checks for the condition only once, or you can define the polling at hourly, daily, weekly, or monthly intervals.
| Field | Use |
|---|---|
| Interval | Select the interval at which the OSM server evaluates the condition that triggers the jeopardy notification. Select Once if you want the system to check for the condition only once when the order is received. When you select Once, the system disregards the Next Start field.
Use the Hours, Days, and Months fields to define a specific interval at which the OSM server evaluates the condition that triggers the jeopardy notification. For example, if you want the system to check for the condition every two days, select the Day(s) option and from the drop-down list select 2. |
| Next Start | Select the date and time that you want the notification to begin checking. You can specify a date for any polling interval. The system uses the current date and time as the default value. |
Creating Jeopardy Notifications in the Task or Order Editor
Use the Jeopardy Automation tab to configure an automation plug-in that performs the work or sends data to an external system when the jeopardy notification is triggered. OSM supports one automation plug-in per Jeopardy.
| Field | Use |
|---|---|
| Add | Click Add to open the Add Automation dialog box is displayed, where you can define a new automation plug-in for the jeopardy notification. |
| Name | Enter a name for the automation entry. |
| Automation Type | Select the automation plug-in type from the available list.
Click OK to add the automation entry to the Jeopardy Automation table. |
| Properties | Select any entry in the table and click to define the automation properties. See "Configuring Automation Plug-In Properties" for more information about defining automation properties in the Properties view. |
Creating Jeopardy Notifications in the Task or Order Editor
Use the jeopardy Notes tab to denote the intended use of the notification or any additional information that you want to append to the jeopardy data.
Creating Jeopardy Notifications in the Task or Order Editor
The Task editor Permissions tab appears for manual, automated, activation, and transformation task types.
Use the Permissions tab to assign roles to each of the three possible task execution modes.
| Field | Use |
|---|---|
| Do, Redo, Undo, Do in Fallout, Redo in Fallout, and Undo in Fallout | For each role listed in the Role Name column, select or deselect, as appropriate, the Do, Undo, Redo, Do in Fallout, Redo in Fallout, and Undo in Fallout check boxes to enable or disable access to the task execution modes.
These options represent the three possible task execution modes:
|
| Select | Click Select to select a predefined role to add to the permissions list. If no roles have been previously defined, click New to create a role.
You must define at least one role in the permissions list for every task. |
| New | Click New to open the Role wizard and create a new role to assign to the task. To select a role that was previously defined, click Select.
You must define at least one role in the permissions list for every task. |
| Open | Select any role in the Role Name column and click Open to open the role in the Role editor. |
| Remove | Select any role in the Role Name column and click Remove to delete the role from the task permissions list. |
The Task editor Redo tab appears for activation task types.
Use the Redo tab to define part of your compensation strategy for activation tasks: to redo tasks that are affected by amendments. Complete the compensation strategy for activation tasks on the Undo tab. See "Task Editor Undo Tab" for more information.
| Field | Use |
|---|---|
| Compensation Strategy | Specify the compensation strategy to redo a task when it is affected by an amendment:
|
| Use existing request mapping | When Compensation Strategy is set to Redo (new order), the Redo operation uses the same request mapping settings as the original order. |
| Re-configure request mapping | When Compensation Strategy is set to Redo (new order), you can specify new request mapping settings for the Redo operation. The Task Data area and Service Actions area behave as they do on the Request Data tab. See "Task Editor Request Data Tab" for more information. |
The Task editor Request Data tab appears for activation task types.
Use the Request Data tab to configure service action requests by mapping OSM order header and task data to Activation order header, service action, and global parameters.
See the following topics for more information:
| Field | Use |
|---|---|
| Task Data area | Select one of the following values:
See "Configuring Service Action Requests" for information about mapping. See "Defining Task Data" for information about adding OSM data to the activation task. |
| Service Action area | Displays the request parameters to which you can map OSM data. Expand the Activation Order Headers folder, the Global Parameters folder, or any service action to review the parameters available for mapping. Check marks indicate which parameters are mapped to OSM data.
Note: Some Activation order header parameters require default values. Before mapping OSM data to Activation order header parameters, note which parameters are prepopulated with a check mark to determine those that require default values. Right-click in the Service Actions area to access the context menu. The Service Actions area context menu enables you to add service data to a task, define new global parameters, associate additional service actions to the tasks, remove parameters, and remove mapping information. Note: When adding service action parameters to OSM task data, you can add all parameters of a service action to a selected OSM data structure. Service action parameters are not added to the structure if it contains a child element with the same name as the parameter. Design Studio limits the maximum length of service action parameters to 1000 when adding them to a structure. If you create data elements for service action parameter fields manually (using the Data Schema editor), ensure that you set the maximum length of the new data element equal to the maximum length defined for service action parameter. |
Configuring Service Action Requests
About Service Action Request Mapping
Use the Activation Order Header Binding view to review and edit mapping information between OSM data and Activation order header parameters.
| Field | Use |
|---|---|
| Order Header | Displays the parameter label. |
| Condition | Enter the condition that determines whether the parameter is included in the request. If the condition evaluates to true, the parameter is sent. |
| Binding Type | Select to define the expression path as an XPath Expression or as an XSLT Snippet. For example, you might define the expression path as an XSLT snippet if you are mapping OSM data to a compound order header parameter. |
| Binding | Displays the mapping information for an order header parameter.
Note: If you are mapping OSM data to a compound parameter, you can reference the CreateOrderByValueRequest_generated.xsl file to ensure that all XPath expressions are defined correctly. To review the CreateOrderByValueRequest_generated.xsl file, switch to the Java perspective and click the Package Explorer tab. Each activation task is listed in the Activation directory in the project resources folder. |
Configuring Service Action Requests
Use the Global Parameter Binding view to review and edit mapping information between OSM data and global parameters.
| Field | Use |
|---|---|
| Parameter | Displays the parameter label. |
| Condition | Enter the condition that determines whether the parameter is included in the request. If the condition evaluates to true, the parameter is sent. |
| Binding Type | Select this option to define the expression path as an XPath Expression or as an XSLT Snippet. For example, you might define the expression path as an XSLT snippet if you are mapping OSM data to a compound global parameter. |
| Binding | Displays the mapping information for a global parameter.
Note: If you are mapping OSM data to a compound parameter, you can reference the CreateOrderByValueRequest_generated.xsl file to ensure that all XPath expressions are defined correctly. To review the CreateOrderByValueRequest_generated.xsl file, switch to the Java perspective and click the Package Explorer tab. Each activation task is listed in the Activation directory in the project resources folder. |
Configuring Service Action Requests
Use the Service Action Binding view to review and edit mapping information between OSM data and service action parameters and to define the conditions under which the service is added to the request.
| Field | Use |
|---|---|
| Service Action | Displays the service action to which the selected parameter is associated. |
| View Node | Displays the activation system parameter name. |
| Condition | Enter the condition that determines whether the service is included in the request. If the condition evaluates to true, the parameter is sent. |
Configuring Service Action Requests
Use the Parameter Binding view to review and edit mapping information between OSM data and service action parameters and to review the default information defined for the service action.
| Field | Use |
|---|---|
| Service Action | Displays the service action to which the selected parameter is associated. |
| Parameter | Displays the parameter name. |
| Default Value | Displays the default value defined for a parameter. You define service action parameters in the Service Action editor. |
| Condition | Enter the condition that determines whether the parameter is included in the request. If the condition evaluates to true, the parameter is sent. |
| Binding Type | Select this option to define the expression path as an XPath Expression or as an XSLT Snippet. For example, you might define the expression path as an XSLT snippet if you are mapping OSM data to an ASAP compound parameter. |
| Binding | Displays the mapping information for a parameter in a service action folder. Consider the following example, which demonstrates a mapping of OSM data elements dsl, VoIP, and tv to an ASAP compound parameter. In this example, you would select XSLT Snippet in the Binding Type field and enter the following:
<xsl:if test="osm:feature/osm:dsl='true'">
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>OLD_SERVICE</mslv-sa:name>
<mslv-sa:value>DSL</mslv-sa:value>
</mslv-sa:serviceValue>
</xsl:if>
<xsl:if test="osm:feature/osm:VoIP='true'">
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>OLD_SERVICE</mslv-sa:name>
<mslv-sa:value>VOIP</mslv-sa:value>
</mslv-sa:serviceValue>
</xsl:if>
<xsl:if test="osm:feature/osm:tv='true'">
<mslv-sa:serviceValue xsi:type="mslv-sa:ASAPServiceValue">
<mslv-sa:name>OLD_SERVICE</mslv-sa:name>
<mslv-sa:value>TV</mslv-sa:value>
</mslv-sa:serviceValue>
</xsl:if>
Note: If you are mapping OSM data to a compound parameter, you can reference the CreateOrderByValueRequest_generated.xsl file to ensure that all XPath expressions are defined correctly. To review the CreateOrderByValueRequest_generated.xsl file, switch to the Java perspective and click the Package Explorer tab. Each activation task is listed in the Activation directory in the project resources folder. |
Configuring Service Action Requests
The Task editor Response Data tab appears for activation task types.
Use the Response Data tab to map responses to OSM data structures and configure state and status transitions for completion events and exceptions returned by the activation system.
| Field | Use |
|---|---|
| Event/Exception | Select an event or an exception. For each event or exception, you define:
Events and exceptions that include any mapping or transition configuration are represented by a shaded (green) flag icon. Events and exceptions with no configuration defined are represented by an empty (or gray) flag icon. |
| Activation Response | Select the data returned from the activation system that updates the OSM order. If you do not select a data field for an event or exception, OSM ignores that event or exception. |
| Response Data Location | Define the OSM data structure to contain the data returned from an event or exception. For each event or exception, you select an existing data structure from the order template or from the data dictionary and right-click that data structure to define the data location. See "Configuring Service Action Responses" for more information. |
| OSM Data Binding | Bind activation response elements to arbitrary task data elements by dragging elements from the Activation Response area onto OSM data structures.
Note: Do not add an OSM data structure in this field that uses a distributed order template. Attempting to map a response value to a data element in a distributed order template will cause an error. For more information about distributed order templates, see OSM Concepts. |
| Transition to State or Status | Displays default transitions defined for completion events and exceptions. You can define additional state transitions for user-defined states and additional transitions for predefined task statuses using the Add button. |
| Move Up and Move Down | Select a state or status transition row in the Transition to State or Status table and click Move Up and Move Down to change the order in which OSM evaluates the transition conditions at run time. |
| Properties | Select a state or status transition row in the Transition to State or Status table and click Properties to define the condition against which OSM evaluates the transition. See "Properties State/Status Transition View" for more information. |
| Response Filter | Enables you to limit the amount of response data sent to update OSM order data. See "Response Filter Area" and "Filtering ASAP Response Data" for more information. |
| Remove | Select a state or status transition row in the Transition to State or Status table and click Remove to delete the transition. |
| Add | Click Add to define a new user-defined state or status transition for a selected event or exception. |
Configuring Service Action Responses
About Service Action Response Mapping
Use the Properties State/Status Transition view to define the condition against which OSM evaluates (at run time) a state or status transition for a service action response.
| Field | Use |
|---|---|
| Condition Name | Displays the condition name as defined on the Response Data tab in the Transition to State or Status table. |
| State/Status | Displays a user-defined state or status transition as defined on the Response Data tab in the Transition to State or Status table. Click Select to change the state or status. |
| Condition | Define the condition against which OSM evaluates the transition. At run time, OSM evaluates the conditions in an order you define and stops evaluating when a condition evaluates to true.
For example, consider that you want to define a condition for the orderFailEvent to transition the task to a suspended state (NEUnknown) because of a network element error. You can define the condition in the following manner:
Note: The |
Configuring Service Action Responses
Use the Response Filter area to display and define conditional mappings for service-action response parameters and value items. For example, you may want to update order parameters with response data only when certain infoParms have a certain value. In the Response Filter area, you can specify an XPath condition which determines whether or not to update OSM order data with response data.
| Field | Use |
|---|---|
| Event/Exception Name | Name of the event or exception on which to filter parameters or value items. |
| Filter on | Select the parameters on which to filter. Select from either infoParm or Command History value item. |
| Condition | Define the conditional mappings of the infoParm or value item parameters by dragging and dropping the desired parameters or items from the Activation Response area into the Condition field. When the XPath representation of a parameter is displayed, set the desired condition by entering an XPath operator.
For example, if you only want to update an order when the serviceId infoParm parameter from orderCompleteEvent is equal to two. First, select orderCompleteEvent in the Event/Exception field. Then, in the Activation Response area, click Detailed Parameters and infoParm. Drag and drop serviceId into the Condition field. The XPath representation of serviceId will appear as follows:
Now set the desired condition by adding ='2'
|
Configuring Service Action Responses
The Task editor Composite Data View tab appears for manual, automated, and transformation task types.
Use the Composite Data View tab to display all of the data that is available to a task within the context of an OSM solution. For example, if you added a new fulfillment function to extend a solution, you would see the additional data nodes required by the function as well as any new control data. The task data in the Composite Data View tab is read-only. You model the data in the Task Data tab of the Composite Cartridge View editor.
Tip:
A The composite data view has at least the same number or more data nodes than its corresponding task view.| Field | Use |
|---|---|
| Solution | Select the solution to display all of the task data associated with the solution. |
| Task Data | Displays all of the data that is available to a task, including additional data that has been contributed within the context of a solution. You cannot modify any data that appears in the Task Data area. |
| Behaviors | (Manual tasks only) Displays all of the behaviors defined for each data node. Select a data node in the Task Data area to view the behaviors defined for the node. You cannot modify any behaviors that appear in the Behaviors area. |
The Task editor States/Statuses tab appears for manual, automated, activation, and transformation task types.
Use the States/Statuses tab to add, remove, and assign predefined states and statuses to tasks, and to define status severity levels.
| Field | Use |
|---|---|
| Name | Displays the database name of the entity. Select the value in the column to rename. |
| Display Name | Displays the name of the entity as it will appear in the Task web client. Select the value in the column to rename.
Note: Design Studio automatically capitalizes display names. |
| Constraint | Sets the Constraint severity level, which determines the transition behavior of a task when a constraint violation is encountered. The Constraint value represents the highest allowable Constraint behavior violation value with which the task transition will be allowed to occur. Select one of the following:
See "Defining Constraint Behavior Properties" for more information. |
The Task editor Task Data tab appears for manual, automated, and transformation task types.
Use the Task Data tab to define which data is necessary to complete the task. You can drag data from the Data Element view into the Task Data area, or right-click in the Task Data area to select data from the Order Template or Data Dictionary dialog boxes.
When modeling task data using the Task Data tab, see the following topics for more information:
| Field | Use |
|---|---|
| Task Data | Displays the data that the task requires to complete. The order in which the data appears in the Task Data area is the order in which it appears in the Task web client (or the order in which the data appears in the XML API if this task is an automated task intended to integrate with an external system).
Select a data node, right-click and select Move Up or Move Down to reposition the node in the task view. See "About the Task Editor Task Data Context Menu" for descriptions of other actions you can perform in the Task Data context menu. |
| Behaviors | (Manual tasks only) Displays all of the behaviors defined for each data node. Select a data node in the Task Data area to view the behaviors defined the node, or to create new behaviors. When defining behaviors at the task level, you can use the Task editor Task Data tab to create the behavior, the Behavior Properties tabs to refine the behavior information, and the Task editor Behaviors tab to quickly view all of the behaviors defined for a task.
See "Defining Manual Task Behaviors" for more information. |
Use the Task Data Node Properties View Identification tab to edit the information defined for the corresponding data element at the task level.
Right-click any attribute in the Task editor Task Data tab and select Open Properties View to edit the data element properties at the task level.
| Field | Use |
|---|---|
| Name | Displays the name of the element as defined in the Data Dictionary. The name of the node is not available for edit. You can edit the value in the Display Name field on the Data Schema editor Details subtab to edit the manner in which the element displays. |
| Path | Displays an XPath expression to define the location of the node in the Data Dictionary. |
| Default Value | Select this option and enter a value to initially populate the field associated with this data node in the Task web client. |
| Read Only | Select this option to make the field read-only field (for this task only) in the Task web client. |
| Significance | By default, a node inherits significance from its parent. At the task level, you can define the significance as Not Significant if you do not want to use the node during amendment processing.
During amendment processing, the OSM system compensates only for task instances that use significant data elements as inputs. If an element is not specified as significant, the system updates the order only with the changed data (no compensation is required). Data significance is supported at the data dictionary, order template, and task view levels. |
| Override Data Dictionary Minimum/Maximum | You can define the Minimum and Maximum values at the task level:
In the Minimum field, select the number of times the global element referenced can appear in an instance document. Select 0 if you want the element to be optional. By default, nodes are optional at the task level. In the Maximum field, select the maximum number of times the global element referenced can appear. Select unbounded to indicate there is no maximum number of occurrences. |
| Apply To Children | Select this option to propagate the Read-Only, Significance, and Override Data Dictionary fields to all direct children of the selected element. The Confirm Change dialog box appears. Select Recursive in the Confirm Change dialog box to apply the changes to all other children of the selected element. All changes are saved immediately upon confirmation. |
| Contributor | Identifies the task that contributes the data element. For example, consider that you have 2 tasks, Task1 and Task2. Task2 extends Task1 and also contains 1 additional data element, billing_start_date. The contributor for all of the data elements (except for billing_start_date) appears as Task1. The contributor for billing_start_date appears as Task2. |
Use the Task Data Node Properties View Dictionary tab to edit the information defined for the corresponding data element at the task level.
Right-click any attribute in the Task editor Task Data tab and select Open Properties View to edit the data element properties at the task level.
| Field | Use |
|---|---|
| Name | Displays the name of the element as defined in the Data Dictionary. The name of the node is not available for edit. You can edit the value in the Display Name field on the Data Schema editor Details subtab to edit the manner in which the element displays. |
| Display Name | Displays the name of the element as it will appear in the Task web client. You can define different display names for the languages that you support in the Task web client. Only those languages defined on the Windows, Preferences, Oracle Design Studio dialog box appear as options. For more information about defining languages for use in OSM, see "Defining OSM Preferences". |
| Type | Displays the data element type. This field is read-only. |
| Max Length | Maximum number of units of length for a string element type. This field is read-only. |
| Minimum or Maximum | Displays the Minimum and Maximum field values as defined in the Data Dictionary. See "Task Data Node Properties View Identification Tab" for information about overriding this value. |
| Path | Displays an XPath expression to define the location of the node in the Data Dictionary. This field is read-only. |
| Namespace | Identifies the namespace in which this cartridge exists, and identifies cartridge version within the namespace, if applicable. |
The Task editor Undo tab appears for IP Service Activator and ASAP activation tasks. (A new activation task is designated to be either an IP Service Activator or ASAP activation task when you choose the Activation System value on the Activation Task Wizard.)
Use the Undo tab to define part of your compensation strategy for activation tasks: to undo tasks that are affected by amendments. Complete the compensation strategy for activation tasks on the Redo tab. See "Task Editor Redo Tab" for more information.
| Field | Use |
|---|---|
| Compensation Strategy (ASAP only) | Specify the compensation strategy to undo a task when it is affected by an amendment:
|
| Compensation Strategy (IP Service Activator only) | Specify the compensation strategy to undo a task when it is affected by an amendment:
|
| Cancel original order (IP Service Activator only) | When Compensation Strategy is set to Undo, this option cancels the original order id. |
| Create a new order to undo (IP Service Activator only) | When Compensation Strategy is set to Undo, you can configure a new task to undo, by specifying the data node that contains the Activation order ID. The Activation order ID is configured on the Activation Task Details tab. See "Task Editor Activation Task Details Tab" for more information. |