This section provides instructions on how to create an execution workflow step source. Before you start to perform these steps described in this section, we recommend that you use the Execution Step Worksheets (see Execution Workflow Step Worksheets) to gather the information you will need to successfully create an execution workflow step source.
To create a new execution workflow step source:
On the PPM Workbench shortcut bar, click Configuration > Workflows.
Open a workflow.
The Workflow window opens.
Select the Workflow Step Sources window.
In Filter by field, select Requests, Packages, or Release Distributions, depending on the type of workflow.
Select the Executions folder.
The Execution window opens.
Provide the information described in the following table.
The name of the workflow step source. The step can be renamed when added to the workflow.
Describes the type of workflow that will be using this step source. Use the list to select a workflow scope. The following lists the possible values:
ALL. For all workflow types.
Requests. For Demand Management request workflows.
Packages. For Deployment Management package workflows.
Release Distributions. For Deployment Management release workflows.
Code to refer to this execution workflow step source. PPM automatically populates this box based on the value you type in the Name box. You can accept the default value or enter a different code.
Description of the step source.
Used to select the type of execution to be performed. Use the list to select an execution type. The following lists the possible values:
Built-in Workflow Event. Executes a predefined command and returns its result as the result of the step.
SQL Statement. Executes a SQL statement and returns its result as the result for the workflow step.
PL/SQL Function. Runs a PL/SQL function and returns its result as the result for the workflow step.
Token. Calculates the value of a token and returns its value as the result for the workflow step.
Workflow Step Commands. Executes a set of commands, independent of an object, at a workflow step.
For Execution Type Built-in Workflow Event, the specific event to perform must be selected. The available choices in the list depend on the workflow scope selected. The choices include:
execute_object_commands. Executes the object type commands for a package line.
execute_request_commands. Executes the request type commands for a request.
create_package. Generates an Deployment Management package.
create_package_and_wait. Generates an Deployment Management package. The create workflow step that generates the package holds it until the package is closed.
create_request. Generates another request.
wf_close_success. Sets the request or package line as closed with an end status of Success.
wf_close_failure. Sets the request or package line as closed with an end status of Failed.
wf_jump. (Deployment Management and Demand Management) Instructs the workflow to proceed to a corresponding Receive Workflow Step in another workflow.
wf_receive. (Deployment Management and Demand Management) Instructs the workflow to receive a Jump Workflow Step and continue processing a request or package line initiated in another workflow.
wf_return. (Deployment Management and Demand Management) Used to route a subworkflow process back to its parent workflow.
For Execution Type PL/SQL Function, the actual function to run. The results of the function determine the outcome of the step. The results must be a subset of the validation values for that workflow step.
For Execution Type Token, the token that will be resolved. The results of the token resolution determine the outcome of the workflow step.
For Execution Type SQL Statement, the actual query to run. The results of the query will determine the outcome of the workflow step.
The results of the query must be a subset of the validation values for that step.
Workflow step commands
For Execution Type Workflow Step Commands, the actual commands to run. The commands will result with a Succeeded or Failed value. Use a validation with those values to enable transitioning out of the step based on the execution results.
Defines when the execution is performed. Use the list to select a processing type. The following lists the possible values:
Immediate. Executes the workflow step when the workflow step becomes eligible.
Manual. Executes the workflow step manually by a user.
Note: If the previous step is an execution step and the Processing Type is set to Immediate, the status dependencies, such as Clear, will not be triggered in the current step. It requires user interaction for these types of status dependencies.
Validations determine the transition values for the workflow step. Use the list to select a validation.
Amount of time that a step is eligible before completing with an error. Timeouts can expressed in minutes, hours, days, or weeks. Timeout parameters for executions are a combination of a numerical timeout value and a timeout unit, such as days.
If this workflow step remains eligible for the value provided in the timeout value, you can configure the request, package line, or release to send an appropriate notification.
Timeouts can be uniquely configured for each workflow step on the Layout tab. The timeout value specified in the workflow step source acts as the default timeout value for the step. When adding a workflow step to the workflow using this workflow step source, you can specify a different timeout value for the workflow step.
For executions, timeouts can also be uniquely configured for the amount of time that an execution is allowed to run before completing with an error. This applies to the workflow step commands and object type commands only. Command-level timeouts are set in the Command window of an object type.
You can select a different graphic to represent this steps of this workflow step source.
This graphic needs to exist in the icons subdirectory. All icons are in gif format.
The workflow step source must be enabled in order to add it to the workflow layout.
Click the Ownership tab.
Use the Ownership tab to specify the security groups that can edit this workflow step. The default is to allow all security groups who can edit workflows to edit a workflow step source. For complete instructions on how to configure workflow step security, see Configuring Ownership of Workflow Step Sources.
Click the User Data tab.
Product entities such as packages, workflows, requests and projects include a set of standard fields that provide information about those entities. While these fields are sufficient for day-to-day processing, user data fields provide the ability to capture additional information specific to your organization. (User data is defined from the User Data tab. If there are no user data fields, the User Data tab is disabled.)
Click the Used By tab.
The Used By tab displays reference information about the workflow step.
The new workflow step source is now included in the Workflow Step Sources window. It can be used in any new or existing workflow with the corresponding workflow scope.