| Oracle® Life Sciences Data Hub Application Developer's Guide Release 2.2 Part Number E22746-02 |
|
|
View PDF |
| Oracle® Life Sciences Data Hub Application Developer's Guide Release 2.2 Part Number E22746-02 |
|
|
View PDF |
This section contains information on the following topics:
Figure 10-1 Process of Creating a Workflow Definition and Instance
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
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".
Workflow Rules Workflows must conform to a number of rules to be valid and installable. See "Workflow" and "Workflow Instance" for further information.
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.
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 Chapter 14, "System Reports" for information.
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:
In a Work Area, select Workflow from the Add drop-down list.
Click Go.
The system displays the Create Workflow screen.
Choose one of the following options:
Create a new Workflow definition and instance. Choose this option if no Workflow definition exists that can meet your needs, either as it is or with some modification.
Create an instance from an existing Workflow definition. Choose this option if a Workflow definition already exists that meets your needs.
If you can adapt an existing Workflow definition to make it fit your needs, first copy it into the current Application Area, then choose this option and select the copied definition. See "Finding an Appropriate Definition" and "Reusing Existing Definitions" for further information.
Depending on your choice, follow one of the following sets of instructions:
When you select Create a new Workflow definition and instance in the Create Workflow screen, additional fields appear.
Enter values in the following fields:
Name. See "Naming Objects".
Description. See "Creating and Using Object Descriptions".
In the Classification section, select the following for both the definition and the instance:
Subtype. Select a subtype according to your company's policies.
Classification Values. See "Classifying Objects and Outputs" for instructions.
Click Apply to save your work and continue defining the Workflow.
The system opens the Properties screen for the new Workflow instance.
Define the Workflow details. It may help you to draw a diagram on paper or white board of the Workflow so you can see which executables, Structures, Notifications and Transitions you need to define. Begin by adding executables and Workflow Structures. See:
Next, add Transitions and Workflow Parameters and create at least one Execution Setup. See:
After you have finished setting up Parameter value propagation, define at least one Execution Setup. See Creating, Modifying, and Submitting Execution Setups.
Click Check In. The system checks in Version 1 of the Workflow definition.
Install the Workflow instance (see Chapter 12, "Using, Installing, and Cloning Work Areas").
Validate both the definition and the instance according to your company's policies.
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.This section contains the following topics:
Subtabs:
See also Figure 10-1, "Process of Creating a Workflow Definition and Instance"
See "Modifying Workflows" for information on modifying Workflows.
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.
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. For further information, see "Definition Source".
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 Appendix A, "Installation Requirements for Each Object Type".
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 Appendix A, "Installation Requirements for Each Object Type".
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 Appendix A, "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".
This section includes the following topics:
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.To add an Oracle LSH executable to the Workflow, go to the Table of Contents tab and do the following:
From the Add drop-down list, select the type of executable you want to add.
Click Go. The system opens the Create screen for the object type you selected.
Choose one of the following.
Create an instance of an existing object definition. See "Creating an Instance of an Existing Definition" for instructions.
Note:
Oracle recommends this option because you can run and test the executable independently before including it in the Workflow.Create a new object definition and instance.
Click Apply.
See "Finding an Appropriate Definition" and "Creating and Reusing Objects" for general information on reusing object definitions.
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.
This section contains the following topics:
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.
Each Workflow Structure has its own function, as follows:
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.
A Fork activity has a single input activity and multiple output activities, creating two or more branches. The subsequent activities run in parallel.
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.
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 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 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 ends Workflow execution with a status of Warning.
You can use this Structure after a conditional Transition whose condition is Warning.
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.
This section includes the following topics:
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.
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.
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.
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:
In a Work Area, select Notification from the Add drop-down list.
Click Go.
The system displays the Create Notification screen.
Choose one of the following options:
Create a new Notification definition and instance. Choose this option if no Notification definition exists that can meet your needs, either as it is or with some modification.
Create an instance from an existing Notification definition. Choose this option if a Notification definition already exists that meets your needs.
If you can adapt an existing Notification definition to make it fit your needs, first copy it into the current Application Area, then choose this option and select the copied definition. See "Finding an Appropriate Definition" and "Reusing Existing Definitions" for further information.
Depending on your choice, follow one of the following sets of instructions:
When you select Create a new Notification definition and instance in the Create Notification screen, additional fields appear.
Enter values in the following fields:
Name. See "Naming Objects".
Note:
The Name does not appear on the actual notification sent to recipients. Recipients see the Subject instead. Definers searching for a Notification definition to use can see the Name.Description. See "Creating and Using Object Descriptions".
Subject. Enter the summary text recipients see, up to 80 characters including text variable values. See "Creating and Using Text Variables".
Type. Select FYI (For Your Information) or Approval. See "Types of Notifications".
Priority. In Oracle LSH Release 2.2 this field has no effect.
Primary Recipient Timeout. This field applies only to Notifications of type Approval. Specify the days, hours, and/or minutes from the time the system sends the Notification to the time the Notification times out for the primary recipients.
Backup Recipient Timeout. This field applies only to Notifications of type Approval. Specify the days, hours, and/or minutes from the time the Notification times out for the primary recipients to the time the Notification times out for the backup recipients. If you do not plan to add backup recipients, enter a zero (0) in each field.
If you selected Approval as the type, select a value for Approval By:
All Recipients. The system moves to the next Workflow activity after the success Transition only after all recipients have approved the Notification.
Any Recipients. The system moves to the next Workflow activity after the success Transition as soon as any one recipient approves the Notification.
In the case of All Recipients, if a single recipient rejects the Notification, and in the case of Any Recipients, if all the recipients reject the Notification, the system moves to the next Workflow activity after the error Transition.
Timeout and Rejection are both failures and the system moves to the workflow after the error transition in both the cases.
In the Classification section, select the following for both the definition and the instance:
Subtype. Select a subtype according to your company's policies.
Classification Values. See "Classifying Objects and Outputs" for instructions.
Click Apply to save your work and continue defining the Notification.
The system opens the Properties screen for the new Notification instance. You must click Update to add recipients or links to outputs.
Define the Notification details. See:
Click Check In.
The system checks in Version 1 the Notification definition. The definition is located directly in the current Application Area. The instance is located in the Workflow.
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.
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:
Click Update. The system refreshes the screens with enterable fields.
From the Group drop-down list, select the user group to whom you want to send the Notification.
From the Role drop-down list, select the role required for Notification recipients.
From the Recipient Type drop-down list, select either Primary or Backup.
Primary recipients receive the Notification when it is first generated by the Workflow.
Backup recipients receive the Notification only if the first group of recipients do not approve or reject the Notification before the timeout period ends.
Click Add Recipient. The system adds the user group and role combination to the recipient list.
Click Apply.
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.
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.
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.
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.
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.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
This section includes the following topics:
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.
Create Transitions in the Workflow's Properties screen, Transitions subtab.
In the Transitions subtab, click Add Transition. The system opens the Create Workflow Transition screen.
Display the From drop-down list. The system displays all the activities you have created for the Workflow.
Select the activity that occurs earlier in the Workflow of the two whose Transition you are defining. For example, if you are defining the Transition between the Workflow Structure Start and the first executable, choose Start in the From column.
From the To drop-down, choose the second activity of the two whose Transition you are defining. This activity will occur immediately following the first if the condition is met.
From the Condition drop-down list, choose the condition you want to apply to the Transition. The choices are:
Error. If the first activity of the pair ends in failure (or a Notification times out, or is rejected), the system uses this Transition to determine the next activity.
None. The Transition is unconditional. The second activity is fired regardless of the completion status of the first.
Success. If the first activity of the pair ends in success (or a Notification of type Approval is approved), the system uses this Transition to determine the next activity.
Warning. If the first activity of the pair ends in warning, the system uses this Transition to determine the next activity.
Note:
If you define an unconditional Transition between two activities, you cannot also define conditional Transitions between the same two activities.Click Apply. The system returns you to the Transitions subtab and displays the Transition you just defined in the last row.
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.
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.
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.
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 Appendix A, "Installation Requirements for Each Object Type" for the reasons these objects may not be installable.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".
This section contains the following topics:
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".
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.
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. See "Definition".
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.
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.
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".
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".
|
 Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
