10 Defining Workflows
Figure 10-1 Process of Creating a Workflow Definition and Instance
Description of "Figure 10-1 Process of Creating a Workflow Definition and Instance"
This section contains information on the following topics:
About Workflows
Workflows allow you to create a single automated process that includes multiple steps, or activities, with conditional branching. The activities can include Oracle Life Sciences Data Hub (Oracle LSH) executables—Load Sets, Programs, Report Sets, and Data Marts—and Structures such as Fork, And, and Or.
Using a single Workflow you can, for example:
-
Load data from SAS and Oracle Clinical into Oracle LSH, write Programs to combine, transform and report the data, combine the results into a Report Set, and notify the appropriate people that the Report Set is available
-
Use the results of one Program in a subsequently executed Program in the same Workflow
-
Use Programs that run on different applications, such as SAS and PL/SQL, in the same Workflow
-
Generate a Report Set or Data Mart intended for submission to a regulatory agency and send Notifications to the appropriate people requesting their formal approval before sending the Report Set or Data Mart to the regulatory agency
-
Include Program outputs in the zipped file of a Data Mart
Parent topic: Defining Workflows
Workflow Components
A Workflow includes the following components, which you must define. Executable instances in a Workflow, Workflow Structures, and Notifications are all called Workflow activities.
-
Oracle LSH Executable Object Instances. To execute a Load Set, Program, Report Set, or Data Mart as part of a Workflow, you must create an instance of it in the Workflow. See Adding Executables.
-
Workflow Structures. You can add predefined structural activities such as Fork, And and Or to control Workflow execution. See Adding Workflow Structures.
-
Notifications. Notifications are messages sent to Oracle LSH users either simply to convey information or to request approval. You can link a Notification to the completion of an activity in the Workflow. For example, when a Load Set execution completes you can request approval from one or more people. The Workflow waits while these people verify that the Load Set successfully loaded the correct data. Only after receiving approval from one or all recipients (depending on how you define the Notification) does the Workflow proceed to the next activity. You can also use a Notification to alert a group of people that a report has been successfully generated on fresh data. See Defining Notifications.
-
Transitions. Transitions define the condition, if any, required to move from one activity to the next. You must define a Transition between each sequential pair of activities. See Defining Transitions.
-
Workflow Parameters. You can define Parameters directly in the Workflow for the purpose of passing their value (which is set in the Execution Setup definition or at runtime) to input Parameters of the executables within the Workflow. You can also set up value propagation from the output Parameter of one Program to the input Parameter of another Program executed later in the Workflow. See Setting Up Parameter Value Propagation.
Parent topic: About Workflows
Workflow Rules
Workflows must conform to a number of rules to be valid and installable.
Parent topic: About Workflows
Execution
During Workflow execution the system detects when one activity has ended and triggers the beginning of the next if the necessary condition has been met, according to your definition of the Workflow activities and Transitions.
The system prevents access to data produced by Programs within a Workflow to Programs outside the Workflow until execution of the entire Workflow has been completed (see Refresh Groups).
The system uses Oracle Workflow to create and execute Workflows.
You define Execution Setups for Workflows the same way you do for other executables. See Creating, Modifying, and Submitting Execution Setups for further information.
Parent topic: About Workflows
Reports on Workflow Definitions and Instances
From the Actions drop-down list, you can generate reports that provide information on a Workflow definition or instance; see System Reports for information.
Parent topic: About Workflows
Creating a Workflow
When you create a Workflow in a Work Area, you are actually creating an instance of a Workflow definition.
To create a new Workflow instance:
Parent topic: Defining Workflows
Creating a New Workflow Definition and Instance
When you select Create a new Workflow definition and instance in the Create Workflow screen, additional fields appear.
Parent topic: Creating a Workflow
Creating an Instance of an Existing Workflow
If you use an existing Workflow as a definition source, all of its elements, Transitions, Parameters and other characteristics are already defined. See Creating an Instance of an Existing Definition for instructions.
You must go into each executable instance contained in the Workflow and map its Table Descriptors to Table instances. You must map target Table Descriptors to Table instances located in the same Work Area as the Workflow instance. See Mapping Table Descriptors to Table Instances for instructions.
Note:
If you have developed the executables outside the Workflow there may be mapping conflicts because only one Program instance can write to a Table instance. See Mapping Table Descriptors within a Workflow for further information.
Parent topic: Creating a Workflow
Using the Workflow Properties Screen
If you are working in a Work Area, you see the properties of both the Workflow instance and the Workflow definition it references. If you are working directly on the definition in an Application Area or Domain, you see only the properties of the definition.
See Modifying Workflows for information on modifying Workflows.
See also Figure 10-1
This section contains the following topics:
Parent topic: Defining Workflows
Instance Properties
You can see the following instance properties:
-
Name: You can click Update and modify the name. See Naming Objects for further information.
-
Description: You can click Update and modify the description. See Creating and Using Object Descriptions for further information.
-
Definition: This field specifies the Workflow definition to which this Workflow instance points.
You can upgrade to a new version of the same definition. See Upgrading to a Different Definition Version from an Instance.
-
Version: This field displays the current version number of the Workflow instance.
-
Version Label: This field displays the version label, if any, for the current Workflow instance version.
For further information on object versions, see Understanding Object Versions and Checkin/Checkout.
-
Validation Status: This field displays the current validation status of the Workflow instance. If you have the necessary privileges, you can change the validation status by selecting Validation Supporting Information from the Actions drop-down list. See Validating Objects and Outputs for further information.
-
Status: This field displays the installable status of the Workflow: Installable or Non Installable. See Installation Requirements for Each Object Type.
Parent topic: Using the Workflow Properties Screen
Definition Properties
-
Checked Out Status: This field displays the status of the definition: either Checked Out or Checked In. You must check out the definition to add, remove, or modify activities, structures, or transitions. However, you can map Table Descriptors without checking out the definition. See Understanding Object Versions and Checkin/Checkout for further information.
-
Latest Version: If set to Yes, this Workflow instance is pointing to the latest version of the Workflow definition. If set to No, this Workflow instance is pointing to an older version of the Workflow definition.
-
Checked Out By: This field displays the username of the person who has the Workflow definition checked out. See Understanding Object Versions and Checkin/Checkout for further information.
-
Version Label: This field displays the version label, if any, for this definition version.
-
Validation Status: This field displays the current validation status of the Workflow definition. If you are working directly in the definition in an Application Area or Domain and you have the necessary privileges, you can change the validation status by selecting Validation Supporting Information from the Actions drop-down list. If you are working in an instance of the Workflow in a Work Area, and you want to change the validation status of the definition, you must go to the definition. See Validating Objects and Outputs for further information.
-
Status: This field displays the installable status of the Workflow: Installable or Non Installable. See Installation Requirements for Each Object Type.
Parent topic: Using the Workflow Properties Screen
Buttons
From a Workflow instance in a Work Area, you can use the following buttons:
-
Install: Click Install to install the Workflow instance, including mapping target Table Descriptors and installing mapped target Table instances; see Installing Workflow Instances. For a list of reasons a Workflow instance may not be installable, see Installation Requirements for Each Object Type.
-
Submit: Click Submit to run the Workflow instance. Before you can run the Workflow, you must install it and create an Execution Setup for it (select Execution Setups from the Actions drop-down list).
-
Update: Click Update to modify the Workflow instance properties. See Modifying Workflow Instance Properties.
-
Check In/Out and Uncheck: Click these buttons to check out, check in, or uncheck the Workflow definition. Different buttons are displayed in the Workflow Definition Properties section depending on the Checked Out Status and whether or not you are the person who has the definition checked out. If someone else has checked out the definition, you cannot check it in or uncheck it. The username of the person who has checked it out is displayed. See Understanding Object Versions and Checkin/Checkout.
Parent topic: Using the Workflow Properties Screen
Adding Executables
This section includes the following topics:
- About Executables as Workflow Activities
- Adding an Executable to a Workflow
- Mapping Table Descriptors within a Workflow
Parent topic: Defining Workflows
About Executables as Workflow Activities
Oracle LSH executables—Load Sets, Programs, Report Sets, and Data Marts—are the substance of a Workflow; the purpose of a Workflow is to execute them as a single process, with contingencies for the success or failure of the execution of each one.
You must add executables to the Workflow before you can define Transitions between them or Parameter value propagation. However, you can add executables to the Workflow over time and add or modify Transitions and Parameter value propagation as necessary.
Although you have the option of creating a new executable from within the Workflow, Oracle recommends that you either use an existing validated definition of a Load Set, Program, Report Set, or Data Mart, or create a new one in a Work Area first so that you can test it independently before creating an instance of it in the Workflow. However, this may lead to mapping conflicts; see Mapping Table Descriptors within a Workflow for further information.
Note:
Oracle does not support multiple concurrent users developing a Report Set inside a Workflow. If more than one person will work on the Report Set at a time, develop the Report Set directly in a Work Area and add it to the Workflow when it is ready.
Parent topic: Adding Executables
Adding an Executable to a Workflow
To add an Oracle LSH executable to the Workflow, go to the Table of Contents tab and do the following:
See Finding an Appropriate Definition and Creating and Reusing Objects for general information on reusing object definitions.
Parent topic: Adding Executables
Mapping Table Descriptors within a Workflow
When you add a Load Set, Program, Report Set or Data Mart instance to the Workflow through a Workflow instance, you cannot map Table instances to Table Descriptors from the executable's screen. You must use the Table Instances from Existing Table Descriptors job from the Actions drop-down list on the Workflow's Properties screen.
See Adding a New Target Table Descriptor for further information.
If you create a Load Set or a Program in the same Work Area where your Workflow instance is located, and then create a new instance of that Load Set or Program inside the Work Area, the system does not allow you to map the instance in the Workflow to the same target Table instances. Only one executable can write to any particular Table instance. You can do either of the following:
-
Create new Table instances and map them to the Program or Load Set instance that is contained in the Workflow. You can use the Table Instances from Existing Table Descriptors job in the Actions drop-down list to create the Table instances and map them automatically.
-
Unmap the target Table instances from the instance of the Program or Load Set that is contained directly in the Work Area.
If you unmap before adding the Program or Load Set to the Workflow, and if the Table instances have the same name as the Table Descriptors, you can run the Automatic Mapping By Name job in the Actions drop-down list after you add the instances to the Workflow.
See Mapping Table Descriptors to Table Instances for further information.
Parent topic: Adding Executables
Adding Workflow Structures
This section contains the following topics:
Parent topic: Defining Workflows
About Workflow Structures
Workflow Structures are predefined activities that you use to control the execution of the Workflow. They can detect the completion status of the previous activity through their input Transition(s) and fire the next one or more activities as specified for their type.
You must add the number of Structures you need; if you need two Forks, for example, you must add two Forks. You need to be able to distinguish the two Forks from one other when you define the Workflow's Transitions. Therefore, give them unique names; for example, append the name of the preceding activity, such as Program_A_Fork.
Structures can be followed only by unconditional Transitions.
When you create a Workflow, the system automatically adds one Start Structure and one of each End Structure to the Workflow. You must add Transitions to connect the Start Structure to the first Workflow activity and to connect one End-type Structure to the last activity on each branch.
Parent topic: Adding Workflow Structures
Types of Workflow Structures
Each Workflow Structure has its own function, as follows:
-
And: An And activity has multiple input activities and a single output activity. It synchronizes events; it waits for all incoming Transitions to be completed before proceeding with the next Transition.
-
Fork: A Fork activity has a single input activity and multiple output activities, creating two or more branches. The subsequent activities run in parallel.
-
Or: An Or activity has multiple inputs and a single output. It fires the next Transition as soon as any one of its input activities completes.
-
Start: All Workflows must contain a single Start Structure as their first activity. A Workflow can contain only one Start. If you need to begin with more than one activity—for example, two or three SAS Load Sets, each loading a different data set—use a Fork immediately after the Start, with an unconditional Transition to each Load Set after the Fork.
-
End_Success: End_Success ends Workflow execution with a status of Success. Use this Structure at the end of the successful completion of the Workflow. If you have multiple branches with parallel activities, use an And Structure before End_Success so that they must all complete successfully before Workflow execution ends with success.
-
End_Failure: End_Failure ends Workflow execution with a status of Failure. Use this Structure following a Transition with a condition of Failure, after each executable. If the executable fails to execute properly, execution of the Workflow ends with an error.
Use this Structure also following a Notification of type Approval, after a conditional Transition whose condition is Failure. If an Approval times out—its recipients do not either approve or reject it within the defined timeout period—the system interprets the timeout as a failure.
-
End_Warning: End_Warning ends Workflow execution with a status of Warning.
You can use this Structure after a conditional Transition whose condition is Warning.
Parent topic: Adding Workflow Structures
Adding Structures
You can add Workflow Structures in the following places in the Workflow user interface:
- In the Activities subtab, choose a Structure from the Add drop-down list and click Go. The Create Workflow Structure screen opens.
- From the Structure Type drop-down list, select the type of Structure you want to add.
- Enter a name for the Structure. The name will help you distinguish this structure from others of the same type, so that you create the transitions you intend.
- Click Apply.
Note:
Only one Start structure is permitted.
Parent topic: Adding Workflow Structures
Defining Notifications
This section includes the following topics:
Parent topic: Defining Workflows
About Notifications
A Notification is a message that you can define as an activity in a Workflow to be sent to recipients you specify after the completion of another Workflow activity. A Notification can include the following:
-
a subject line
-
a text message
-
a link to an Oracle LSH output
-
a request for approval or rejection
A Notification appears on the Oracle LSH My Home screen of each recipient. Each Oracle LSH user can also set a user preference to receive Notifications as email. See "Using Notifications" in the Oracle Life Sciences Data Hub User's Guide for instructions.
You can create a set of standard Notification definitions for reuse.
Parent topic: Defining Notifications
Types of Notifications
There are two types of Notifications:
-
FYI (For Your Information). FYI Notifications pass information to the recipients. They can contain text and a hyperlink to an Oracle LSH output. You must specify one or more recipients by user group and role.
-
Approval. Approvals pass information to the recipients and also request action from the recipients. The system waits for a response before proceeding to the next activity in that branch of the Workflow. You can define the Notification to require action from one or from all recipients.
Parent topic: About Notifications
Using Approvals
You can use an Approval as a manual checkpoint in the Workflow's business process—for example, to ensure that the system loaded the correct lab data before generating a report on the data—or as a record that a report output has been reviewed and approved (see Writing Text for Approvals).
In the Notification you specify whether approval is required by one or all of the recipients to proceed to the next Workflow activity. You also specify a timeout period. You can specify a backup group of recipients to receive the Notification if the timeout period expires, plus a timeout period for the backup recipients.
When a user receives an approval-type Notification, it includes two buttons labeled Approve and Reject, respectively, but the approval or rejection is not of the Notification itself. You must make it clear to the recipient in the text what will happen if he or she clicks each button.
You must define two Transitions following a Notification, one for each condition: Success and Failure. The system interprets an approval by the required number of recipients as success, and a rejection or a timeout as a failure.
Success and Failure Conditions: In the Workflow, you must define two Transitions following each Approval Notification, one each for success and failure. The system interprets an approval as a success, and a rejection or a timeout as a failure.
Parent topic: Defining Notifications
Creating a Notification
When you create a Notification in a Work Area, you are actually creating an instance of a Notification definition.
To create a new Notification instance:
- Creating a New Notification Definition and Instance
- Creating an Instance of an Existing Notification
- Specifying Notification Recipients
- Defining a Link to a Planned Output
- Writing Notification Messages
- Defining Notification Parameters
Parent topic: Defining Notifications
Creating a New Notification Definition and Instance
When you select Create a new Notification definition and instance in the Create Notification screen, additional fields appear.
Parent topic: Creating a Notification
Creating an Instance of an Existing Notification
If you create an instance of an existing Notification, its Recipients, Parameters, Message, and other attributes are already defined. You can modify them as necessary in the instance. See Creating an Instance of an Existing Definition for instructions.
Parent topic: Creating a Notification
Specifying Notification Recipients
You specify recipients by their user group and role. The system sends the Notification to all users who have the role you select in the user group you select. You can specify any number of combinations of user groups and roles.
To add recipients:
If you want to specify one or more recipients by name, you must create a user group specifically for this purpose and add the users to the group. Creating user groups requires administrative privileges.
Parent topic: Creating a Notification
Defining a Link to a Planned Output
In the Notification definition you must define a link to a Planned Output of an executable contained in the Workflow. At runtime, the system generates a link to the actual output generated from the Planned Output, and puts the link into the Notification in a reserved area of the Notification.
To define a link to a Planned Output:
- Click Update. The system refreshes the screens with enterable fields.
- Click Add Planned Output. The Search and Add Planned Outputs screen appears.
- From the Activities in the Workflow drop-down list, select the executable to whose output you want to create a link.
- In the Output Name field, enter the name or title of the Planned Output to which you want to create a link. You can use special characters; see "Using Special Characters" in the Oracle Life Sciences Data Hub User's Guide for instructions.
- Click Go. The system performs the search and displays the results.
- Select the Planned Output you want by clicking its Select checkbox and clicking the Select button.
Parent topic: Creating a Notification
Writing Notification Messages
This section includes the following topics:
Creating and Using Text Variables
The Message is the text content of the Notification. The message and Parameters are part of the Notification definition, and you must click the hyperlink to the definition to define them.
To create the Notification message:
-
Click the hyperlink to the definition located under the Subject line. The Notification definition's Properties screen appears.
-
Click Update. The system refreshes the screen and makes the fields enterable.
-
In the Messages subtab, enter text in the Body field. You can use the Insert Parameter button to insert runtime Parameter values into the body of the text; see Defining Notification Parameters.
-
Click Apply.
Parent topic: Writing Notification Messages
Writing Text for Approvals
When you write text for approval Notifications, be careful to make it clear to the recipient what a response of Approve or Reject means. For example, use wording such as:
-
If you have reviewed this report and believe its contents are accurate, click Approve. If you have reviewed this report and believe its contents are not accurate, click Reject.
-
Please review the report on the lab data load at the link below. If the system has loaded the correct data, click Approve. If not, click Reject.
The system does not link the approval or rejection to the actual report. In case of an approval, it proceeds to the step following the success Transition in the Workflow. If rejected, the system proceeds to the step following the error Transition. Therefore, if clicking Approve indicates approval of the report's contents, ensure that the Notification text conveys that understanding.
The system keeps a record of all approvals and rejections.
Parent topic: Writing Notification Messages
Defining Notification Parameters
You can save time and ensure consistency and quality by reusing Notification definitions with clear, carefully worded text that includes Parameters as text variables so that you can use them in multiple situations.
The system places the Parameter value in the message at the point where you insert the Parameter, displayed in the Notification definition preceded by an ampersand (&). At runtime the system replaces the backslashes and the Parameter name with the current value of the Parameter.
The Parameter appears in the Execution Setup of the Workflow under the Notification. You can define a Parameter directly in the Workflow that will appear at the top of the Execution Setup and set up value propagation from that Parameter to the Notification Parameter; see Defining Parameters.
For example, you can use the same Notification definition for multiple reports and multiple studies by inserting the following Parameters into the message text:
-
Study Name
-
Report Title
The person submitting the Workflow for execution enters the correct value for that execution and the system propagates the value to the Notification, so that Notification recipients see the appropriate study and report title.
Note:
If the Parameter value is so long that the subject or body exceeds the maximum size, the system truncates the subject or text. The maximum size of the subject is 80 characters. The maximum size of the body is 32K characters.
Parent topic: Creating a Notification
Modifying Notifications
The system copies all the attributes of a Notification definition to the instance. Your changes affect only the instance of the Notification in the Workflow, not the source definition. You can modify the following attributes:
-
Priority
-
Recipients
-
Approval Required By All Recipients
-
Timeout
-
Backup Recipients
-
Backup Timeout
-
Link to Planned Output
Parent topic: Defining Notifications
Defining Transitions
This section includes the following topics:
Parent topic: Defining Workflows
About Transitions
Transitions specify the sequence of activities in the Workflow and the condition, if any, necessary to proceed from one activity to the next. You must explicitly define the Transition between each sequential pair of activities.
You must add activities (Oracle LSH executables—Load Sets, Programs, Report Sets, Data Marts, and Notifications—and Workflow Structures—Start, And, Or, Fork, and the End Structures—before you can define the Transitions between them.
Each activity (except Start and End Structures) must have a Transition defined immediately before and after it in the Workflow. In addition, each Transition must have an activity defined immediately before and after it.
You can define more than one Transition following a single activity, but each Transition must each have a different condition. To create parallel branches where each branch is the result of the same condition of the same activity, use a Fork activity.
Transitions can be conditional or unconditional:
-
Unconditional Transitions occur as soon as the first activity has completed. If the first activity is an executable, either a success or failure end status triggers the next activity. You can define an unconditional Transition after either an executable or a structural activity.
Conditional Transitions can occur only after an executable or a Notification. The executable must return a completion status of success, warning or failure and you must define a conditional transition to handle each completion status.
See Workflow Rules for further information.
Parent topic: Defining Transitions
Creating Transitions
Create Transitions in the Workflow's Properties screen, Transitions subtab.
Continue adding Transitions until you have covered all those necessary for the Workflow. Each activity (except Start and End ones) should occur at least once in the From column and once in the To column. If you use Forks or create branches for different outcomes (success or failure), some activities must appear multiple times in either or both columns.
Parent topic: Defining Transitions
Defining Workflow Parameters
You can define Parameters directly in the Workflow for the purpose of passing their value to the input Parameters of Programs and Report Sets contained in the Workflow. See Defining Parameters and Setting Up Parameter Value Propagation for information.
Parent topic: Defining Workflows
Workflow Planned Outputs
A Workflow may generate multiple report outputs, but the system uses the Planned Outputs defined for Programs contained in the Workflow to generate them.
The Workflow itself has no Planned Outputs. Outputs are produced by the executable objects under the Workflow. Therefore Planned Outputs are defined directly under the objects.
Parent topic: Defining Workflows
Installing Workflow Instances
You can install a Workflow instance directly from its Properties screen, using the Install button, or in its Work Area (see Installing a Work Area and Its Objects).
When you install a Workflow instance using the Install button on its Properties screen:
-
The system checks in the Workflow instance and definition, and also the Table instances in the current Work Area to which the instance is mapped.
-
The system checks if the Workflow is installable. If not, the system performs Automatic Mapping by Name on any unmapped target Table Descriptors. If the Workflow is still not installable and there are still unmapped target Table Descriptors, the system creates Table instances in the current Work Area from the target Table Descriptors and maps them.
-
The system attempts to install the Workflow instance and its source and target Table instances in the current Work Area. The system displays a success or error message. If the installation fails, the error message displays the name of any objects that were not installable.
Note:
If any of the Table instances or the Workflow definition is not installable, the system cannot install the Workflow instance. See Installation Requirements for Each Object Type for the reasons these objects may not be installable.
Note:
To continue working on the Workflow, check it out.
Parent topic: Defining Workflows
Accessing the Log File
To see the log file for the installation, you must go to the Work Area Installation screen, as follows:
-
Click the Applications tab. The main Application Development screen opens.
-
Click the name of the Work Area you are working in. The Work Area screen opens.
-
From the Actions drop-down list, select Installation History.
-
Click Go. The system displays the Installation History screen with the log files in chronological order.
-
Click the View Log link for the most recent installation attempt or for the date and time that you ran the install process. The system displays the log file.
For information on installation and on reading the log file, see Installing a Work Area and Its Objects.
Parent topic: Installing Workflow Instances
Modifying Workflows
If you have the necessary privileges, you can modify a Workflow either through an instance of it in a Work Area or directly in the definition in its Domain or Application Area. In most cases it makes sense to work through an instance in a Work Area for the following reasons:
-
In order to use or test changes to the definition you must create and install an instance of it.
-
If you work through an instance, the system automatically repoints the instance to the new version of the definition.
However, if you need to change properties of the definition, you must work directly in the definition in its Domain or Work Area.
Whether you work in an instance or directly in the definition, when you check in the new version of the definition you have the opportunity to upgrade instances of the original definition to the new version; see Upgrading Object Instances to a New Definition Version.
This section contains the following topics:
Parent topic: Defining Workflows
Modifying Workflow Instance Properties
On the Workflow instance's Properties screen, click Update to enter changes. Oracle LSH creates a new version of the instance you are working on and applies your changes to it when you click Apply. Click Cancel to discard your changes and the new version.
You can modify some properties through the Actions drop-down list; see Using the Actions Drop-Down List for further information.
Note:
You must reinstall the Workflow for the changes to take effect.
You can modify the following:
-
Name: See Naming Objects for further information.
-
Description: See Creating and Using Object Descriptions for further information.
-
Definition Source: This field applies to the instance only. It specifies the Workflow definition to which this Workflow instance points. It generally does not make sense to change the source definition for the following reasons:
-
Changing the definition may result in a new set of Activities, Transitions, Notifications, and Parameters.
-
Any new Table Descriptors are not mapped.
-
The Workflow's status changes to Non Installable.
If you want to change to a new version of the same definition, use the Upgrade Instance option from the Actions drop-down list.
-
Parent topic: Modifying Workflows
Modifying Workflow Definition Properties
You can go to a Workflow definition's Properties screen in one of the following ways:
-
From the Workflow's Properties screen: Click the hyperlink of the Workflow definition that appears in the Definition field.
-
From the Domain or Application Area where you created the definition: Click Manage Definitions to view all the definitions in that Domain or Application Area. Click the definition name.
Once on the Workflow definition screen, click Update to enter changes. Oracle LSH creates a new version of the definition. You can change the following properties:
-
Name: See Naming Objects for further information.
-
Description: See Creating and Using Object Descriptions for further information.
You can modify some properties through the Actions drop-down list; see Using the Actions Drop-Down List for further information.
Parent topic: Modifying Workflows
Modifying Activities and Transitions
Activities (executable instances, Notification instances, and Workflow Structures) and Transitions belong to the Workflow definition. You cannot modify them, but you can add and remove them.
Parent topic: Modifying Workflow Definition Properties
Modifying Parameters
Parameters belong to the Workflow definition. You must check out the Workflow definition to modify Parameters.
You can change the following:
-
You can add and remove Parameters owned directly by the Workflow, modify their default value and other settings, and change the Parameters to which they propagate their value at runtime.
-
You can modify Parameter value propagation relations defined in the Workflow from the output Parameter of one Program to the input Parameter of another Program executed subsequently in the Workflow.
You cannot modify, add, or remove the Parameters that belong to the Programs and other executables inside a Workflow, except to redefine their value propagation relationships. See Setting Up Parameter Value Propagation.
You can change some Parameter values and settings in one or more Execution Setups. Select Execution Setups from the Actions drop-down list in the Workflow instance in the Work Area. See Creating, Modifying, and Submitting Execution Setups.
Parent topic: Modifying Workflow Definition Properties
Modifying Table Descriptor Mappings
All the Table Descriptors in a Workflow belong to the executable instances it contains, including Load Sets, Programs, Data Marts, and the Program instances contained in Report Set instances in the Workflow.
However, you can use the Actions drop-down item Table Instances from Existing Table Descriptors directly from the Workflow, to create Table instances from existing Table Descriptors owned by any Program instance in the Workflow and map them at the same time; see Creating Table Instances from Table Descriptors and Simultaneously Mapping Them.
You can also use Automatic Mapping by Name directly from the Workflow; see Automatic Mapping by Name.
Parent topic: Modifying Workflow Definition Properties