Administration > Configure workflows > Designing processes in Application Integration

Designing processes in Application Integration

You can use Process Designer of Application Integration to:

•Build a process from a variety of step types, including milestone, human tasks, decision, jump, end, and so on.
•Automatically link steps in a process as you select data and define actions, bindings, and other process properties.
•Test your process during process design.
•Publish the process.

Important: When you configure workflows, don't include sub-processes in a process.

Creating a new process

Use the process asset to orchestrate and define control-flow logic for business processes.

1In Application Integration, click New.

The New Asset dialog box appears. The following image shows the New Asset dialog box: The New Asset dialog box with Process selected.

2Select Processes > Process, and then click Create.

The Process1 page appears. The following image shows the Process1 page: The Process1 page with a Design and Properties section.

Setting process properties

1Select Processes > Process, and then click Create.

The Process Designer opens.

The following image shows the Process Properties panel:

The General tab of the Process1 Properties panel.

2Enter the required properties.

3Optionally, to view or edit the process properties, click the Start step.

4Click Save.

Note: When you configure workflows, the properties on the Output Fields, Temp Fields, Messages, and Notes tabs are not needed. You can skip these properties.

General properties

You can specify the following general properties for processes:

Property	Description
Name	Required. A descriptive name to identify the process in Process Designer and the name that appears when the process is available for use in other objects such as subprocess steps. The name can contain multibyte characters and must not exceed 80 characters. To change the name of a published process, you must first unpublish the process. Then, change the name and republish the process.
Override API Name	Optional. Overrides the API name that is auto generated when you publish the process with a name that you specify. When you select this option, the API Name field becomes available.
API Name	Required if you select the Override API Name option. A unique API name to override the auto-generated API name for the process. The API name that you specify in this field is used in the generated service URLs. The API name can contain only alphanumeric characters, underscores (_), and hyphens (-), and must not exceed 80 characters. To change the API name of a published process, you must first unpublish the process. Then, change the API name and republish the process. If you override the API name and import the process, the imported process uses the API name that you specified. However, if there is an existing process with the same API name that you specified, Application Integration uses an auto-generated API name for the imported process to avoid duplication. Application Integration also disables the Override API Name field. Similarly, when you copy a process, Application Integration uses an auto-generated API name for the copied process to avoid duplication and also disables the Override API Name field. If you override the API name and move the process to a different location, Application Integration retains the API name that you specified.
Location	Optional. The location of the project or folder you want the process to reside in. To select a location for the process, browse to the appropriate project or folder, or use the default location.
Description	Optional. A description of the process.

Start properties

Use the Start tab to define the binding type, access details, and the runtime environment details.

You can define the following start properties for a process:

Binding: The Binding property defines how a process is invoked and run. Select the REST/SOAP binding type to run the process by using a service URL.
Allow anonymous access: When selected, Process Designer lets anyone use the process. This means that access to the process is not tied to a specific user or to any user group.
Applies To: Do not change the default value.
Run On: Do not change the default value.

Input fields properties

You can add input fields of type Human Task Assignment. Additionally, you can add an input field of type Text to display the asset name on every task created in Data Governance and Catalog after you start the workflow.

The following table describes the input field properties in a process:

Property	Description
Input Format	Determines whether the input field can represent one or more fields, or the entire contents of the request.
Name	The name of the input field.
Type	The type of the input field. For custom workflow configuration, select Text or Human Task Assignment.
Description	Description for the input field.
Required	If the field is required for a process to run, select Required. When you configure workflows, Metadata Command Center renders the input fields as mandatory. Important: Informatica recommends that you make all input fields mandatory.

The following image shows a Start step with the AssetName input field: The Input Fields tab of the Start step with an AssetName input field of Text type highlighted.

The Input Fields tab of the Start step with an AssetName input field of Text type highlighted.

The Start step must have an allStakeHolders input field of Human Task Assignment type. This is required to control which stakeholder role can view the tasks created for an asset.

The following image shows a Start step with the allStakeHolders input field: The Input Fields tab of the Start step with an allStakeholders input field of Human Task Assignment type highlighted.

The Input Fields tab of the Start step with an allStakeholders input field of Human Task Assignment type highlighted.

Advanced properties

You can configure advanced properties to define fault handling and tracing for a process.

You can configure the following advanced properties:

Suspend on Fault

By default, Process Server terminates a process when an uncaught fault occurs. You can configure Process Designer to suspend individual processes on uncaught faults.

If you select the Suspend on Fault option, Process Server suspends the process when an uncaught fault occurs. If you do not select the Suspend on Fault option, Process Server terminates the process if a fault occurs and the process does not explicitly handle the fault.

If the process is in the suspended state, review and identify error conditions. Then, you can then retry or complete the activity. For example, you can catch error conditions during employee or customer onboarding. After you resolve all the errors, the process moves out of the suspended state and continues from the faulted step.

If you select the Suspend on Fault option, Process Designer uses full persistence.

Note: These process-specific properties work in conjunction with other exception management settings that you specify in the Application Integration Console.

For more information about managing and correcting faults, see Monitor.

Tracing Level

You can configure one of the following tracing levels to determine the type of run-time logging for a process:

•None
•Terse
•Normal
•Verbose

The tracing level that you configure in Process Designer maps to the persistence level and logging level in Process Developer as listed in the following table:

Tracing Level	Persistence Level	Logging Level
None	Brief	None
Terse	Brief	Fault
Normal	Brief	Execution with Service Data
Verbose	Final	Execution with Data

Note: When you configure the Normal and Verbose log levels, you can view the progress of the workflow ticket in the Application Integration Console.

Persistence Level
Logging Level: The Process Server logging level might be lower than the logging level that you set for an individual process. Regardless of the logging level that you set at the process level, the logging will not exceed the maximum process logging level specified for Process Server. The tracing level table illustrates the mappings between the logging level and the persistence level.

Adding process steps

Add steps to access data, services, and perform related orchestration activities.

When you add a step, you also define properties for that step.

Perform one of the following tasks to add a step to a process:

•Drag a step from the pallette on the left onto the canvas.
•Double click on the canvas and select a step from the Step Type list.

Milestone step

Use the Milestone step as a first step after the Start step in a process and as the last step to indicate the required action at the end of a process.

The following image shows a Milestone step:

The Milestone 1 Properties panel with the Ending Type set to Milestone: Send a Synchronous Response, HTTP Status, and a HTTP response header.

Name displays the name of the milestone step. You can edit this value.

Note: When you configure workflows, the other milestone properties are not needed. You can skip these properties.

Human Task step

Use the Human Task step to include a human decision within an Application Integration process. A human action is required for approvals. For example, you might want to add a Human Task step to a loan approval process.

Double-click the Human Task step and select the human task that was created in the human task asset.

Important: When you configure workflows, design processes with at least one human task.

The following image shows a Human Task step within an Application Integration process:

The Process Designer with a Start, Human Task, Decision, and End steps.

The following table describes the properties that you can configure in a Human Task step:

Property	Description
General	The name of the Human Task step. The human task name appears in Metadata Command Center and Data Governance and Catalog.
Human Task	Select the human task that you want to include within the Application Integration process.
Assignments	Assign values to the input fields.
Input Fields	Map the input field in the Start step to the human task input field.
Outcomes	Displays a list containing the outcomes that you defined in the human task asset. Note: Human tasks in the process must have at least one outcome.
Fault Handling	Optional. Select the Catch fields option to enable fault handling for the Human Task step. You can provide a name for the fault handler in the Fault Field Name field.

Map the Potential Owners and Stakeholders with the correct input fields for each human task in a process. If you don't map these correctly, you can't assign dynamic roles to human tasks when you configure workflows in Metadata Command Center.

Map the Stakeholders task role with the allStakeHolders input field for each human task in a process. Based on the roles you select in Metadata Command Center, ongoing tasks are visible to the respective stakeholders when the tasks are generated.

The following image shows a Human Task step with the correct mappings: The Assignments tab of a Human Task step with Potential Owners and Stakeholders mapped correctly and highlighted.

The Assignments tab of a Human Task step with Potential Owners and Stakeholders mapped correctly and highlighted.

For information about creating a Human Task asset, see Creating human tasks.

Decision step

A Decision step allows a process to take different paths depending on the value of the field.

The following table describes the properties in a Decision step:

Property	Description
Name	The name of the Decision step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Decision	The process takes a decision based on the fields and paths you define here. Select a field name from the list of fields you define under Start > Fields. Enter conditions and values that you want the Decision step to base a decision on. The conditions available depend on the field that you select. For example, if you select a field of type Simple > Text, the following conditions are available: - Equals - Starts With - Ends With - Starts with any of - Contains Important: If multiple outcomes of a human task have common text, Informatica recommends that you use the EQUALS operator in decision-making steps when you create workflow paths. For example, assume that Outcome1 and Outcome2 of a human task are labelled as Approver1 and Approver2. If you include the CONTAINS operator in the decision step with the value "Approver," the navigation of the workflow path at run time can become unpredictable. Instead, if you use the EQUALS operator with a specific value, the workflow operates seamlessly. You can enter text values against the conditions you select. You can add multiple conditions to a Decision step. Each condition is a potential data path. For each path that you add, a corresponding branch appears on the UI. Drag branches to rearrange the order in which the branches appear on the UI. Most Decision steps have an Otherwise path. This path handles execution if no data meets the conditions in your tests.

Property

Description

Name

The name of the Decision step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.

Decision

The process takes a decision based on the fields and paths you define here.

Select a field name from the list of fields you define under Start > Fields.

Enter conditions and values that you want the Decision step to base a decision on.

The conditions available depend on the field that you select.

For example, if you select a field of type Simple > Text, the following conditions are available:

- Equals
- Starts With
- Ends With
- Starts with any of
- Contains

Important: If multiple outcomes of a human task have common text, Informatica recommends that you use the EQUALS operator in decision-making steps when you create workflow paths. For example, assume that Outcome1 and Outcome2 of a human task are labelled as Approver1 and Approver2. If you include the CONTAINS operator in the decision step with the value "Approver," the navigation of the workflow path at run time can become unpredictable. Instead, if you use the EQUALS operator with a specific value, the workflow operates seamlessly.

You can enter text values against the conditions you select.

You can add multiple conditions to a Decision step. Each condition is a potential data path.

For each path that you add, a corresponding branch appears on the UI. Drag branches to rearrange the order in which the branches appear on the UI.

Most Decision steps have an Otherwise path. This path handles execution if no data meets the conditions in your tests.

Evaluating Paths

A process evaluates conditions based on the criteria you specify. Ensure that you construct paths with non-intersecting conditions.

For example, you create a Data Decision step with the following paths:

•Path 1: Field less than or equal to 100.
•Path 2: Field less than or equal to 75.
•Path 3: Field less than or equal to 25.
•Path 4: Otherwise

If the integer field for which the Data Decision step was created has a value of 25, the Data Decision step takes path 1. This is because 25 is less than 100 and path 1 is the first option.

To ensure that the Data Decision step follows the "Field less than or equal to 25" path, re-create the paths with the following criteria:

•Path 1: Integer between 0 and 25
•Path 2: Integer between 26 and 75.
•Path 3: Integer between 76 and 100.
•Path 4: Otherwise

Important: The process evaluates conditions in a top-down manner. Ensure that the Otherwise branch is the last path.

Jump step

When you add a Jump step, you set some properties.

The following table describes the properties in a Jump step:

Property	Description
To	The target of the jump. Select from a list of available steps. More than one step can jump to the same target step. To see how many Jump steps have a particular step as their target, place the cursor over the arrow next to the target step.

End step

An End step indicates the end of the process. When execution reaches this step, the process completes.

Name displays the name of the end step. You can edit this value.

Note: When you configure workflows, the other End step properties are not needed. You can skip these properties.

Validating a process

When you create a process, you can use the Validation panel to verify if there are validation errors and view the error details.

1Click the Validation icon in the toolbar as shown in the following image:

The Validation icon in Process Designer that is used to open the Validation panel.

The Validation panel appears on the right pane. In the Validation panel, errors are grouped based on the tabs where they occur.

2Click the arrow corresponding to a tab name as shown in the following image:

A list of errors that occur in the tab is displayed.

3Click an error row.

The cursor moves to the erroneous field. Take the required corrective action to resolve the error.

As and when you correct errors, the error list in the Validation panel is refreshed.

Saving and publishing a process

After you create a process, save and publish the process to configure workflows.

In Process Designer, click Save to save the process, and then click Publish.

After you publish a process, you can view the published process and use the process to configure workflows in Metadata Command Center. To publish a process, the process must be successfully validated. No asset must be in an invalid state. Associated workflows become outdated if you modify a published process or human task step. Reconfigure the outdated workflow in Metadata Command Center with a valid and published process to start the workflow.

Important: You can select only published processes when you configure workflows in Metadata Command Center.

Updating a published process

If you want to make changes to an existing published process, Informatica recommends that you make a copy of the existing process, make the necessary changes, and then publish the process. If you do this, existing workflows that use the process are not impacted.

Republishing a process without making any changes at the process or asset level does not affect the existing workflow configuration in Metadata Command Center. If you rename and publish a process with or without other changes, existing workflows configured in Metadata Command Center that use the process become invalid. If you modify a process after publishing, the process becomes outdated and makes the existing workflow configuration in Metadata Command Center invalid.

Important: If you modify a published process, existing tickets follow the previously published process regardless of whether you publish the modified process or not. When you open the corresponding workflow in Metadata Command Center, an error appears to indicate that the workflow configuration is invalid. Resolve or cancel all existing tickets before reconfiguring the new process changes for the workflow.