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.
Assignment Step
Use the Assignment step to set a value to a field. To create an Assignment step, click a process, and then select Assignment from the Design canvas. Then, from the Assignments properties panel, click the Add icon to assign Name and Assignment values.
The following image shows an Assignment step:
To add a field, click the Add icon, and then add the following information for each field:
Name
This is the fully-qualified field name. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Assignments
This is the source from which the field takes values. The fields you see depend on the data type you defined under Start > Properties > Input Fields or Temporary Fields.
For example, if you define the data type in the Input Fields as Date or Time, the following options appear for that field in the Assignment step:
- Specific date
- Days from today
- Days before/after
- Field
- Formula
If you define the data type as Integer or Text, you see the following options to specify the value of the field:
You can also map the fields automatically including complex process objects configured in the input fields or temporary fields in the process.
To map the fields automatically, add the fields and click AutoMap.
You must ensure that you have meaningful field names to find the most accurate field matches. If the field name that you want to match contains some random text, Application Integration does not recognize the field name and the mapping field remains empty.
Application Integration matches the best possible fields based on the field name and data type that are configured in the process. Informatica does not guarantee exact field matches. After the fields are mapped, you must manually verify if the mappings are correct and update as needed.
Service Step
When you add a Service step, you set some properties.
The following sections describes the Service step properties:
General
Property
Description
Step Type
The Service step.
Name
A descriptive name for the service. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Service
Property
Description
Service Type
The connection, process, or system service options that you add to the process. When you select the Process or the Connection option as the service type, a Select button appears. Click Select to browse and select from a list of processes or connections.
When you select the System Service option for the service type, you can select an action from a list of system service actions.
Note: You must have an existing item to add to a process. You cannot create a task when you create a process.
For more information about the list of supported actions for system service, see System Service Actions.
When you add a service to a Service step, corresponding Input Fields are created.
Input Fields
The Input Fields section shows the names of input fields that are most often used when using this kind of step. For Service steps that create objects, the input fields shown are the fields that are most frequently needed when the object is created. If you do not need a field and it is optional, you can delete it. You can choose additional input fields from the list.
Based on the service type configured in the Service step, you can also map the fields automatically with the fields configured in the input fields or temporary fields. You can also map the complex process objects configured in the process.
To map the fields automatically, on the Input Fields tab, click AutoMap.
You must ensure that you have meaningful field names to find the most accurate field matches. If the field name that you want to match contains some random text, Application Integration does not recognize the field name and the mapping field remains empty.
Application Integration matches the best possible fields based on the field name and data type that are configured in the process. Informatica does not guarantee exact field matches. After the fields are mapped, you must manually verify if the mappings are correct and update as needed.
Use the delete icon to remove a field. This removes input fields that you do not want to pass to the Service step. Some fields are required and cannot be deleted.
Fault Handling
Fault handling in Process Designer is based on the Business Process Model and Notation (BPMN) 2.0 specification, which defines the concept of a boundary event. The boundary events catch faults associated with specific steps, rather than the overall process scope. This means you can handle faults at the step level, not the process level. (Developers can also use Process Developer to define a fault handler on the process scope.)
Visibility of Faults in Application Integration Console
When fault handling is enabled in a process, you can view the error marker on the step and some basic fault information in the Application Integration Console Processes list.
Timer Events
Use Timer Events to perform an action based on a schedule. You can specify whether you want the event to run At specific time or After a delay.
The following image shows a configured timer event:
Select Interrupting if you want the timer to interrupt the Service step. When you set an interrupting timer, the Service Step task is interrupted and the process only runs the task on the timer set
Message Events
Specify messages for use with message providers and correlation. You can add multiple instances of the same message event to the Service step.
Subprocess Step
A Subprocess step embeds one process within another process. When the Subprocess step executes, the embedded process executes.
When you have a process that contains numerous steps, consider splitting the orchestration logic across multiple smaller processes. You can then simplify the design by using the Subprocess step to embed the smaller processes in the parent process. This not only leads to modular design, but also helps with faster loading when you open the process for editing.
The Subprocess step name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
You can define the Input and Output associated fields for the Subprocess step, if any, based on the embedded process.
You can also map the subprocess fields automatically with the fields configured in the input fields or temporary fields including complex process objects in the process.
To map the fields automatically, on the Input Fields tab, click AutoMap.
You must ensure that the subprocess contains meaningful field names to find the most accurate field matches. If the field name that you want to match contains some random text, Application Integration does not recognize the field name and the mapping field remains empty.
Application Integration matches the best possible fields based on the field name and data type that are configured in the process. Informatica does not guarantee exact field matches. After the fields are mapped, you must manually verify if the mappings are correct and update as needed.
The following image shows the JMS Dequeue subprocess properties:
Iteration Rule
The iteration rule applies when the selected process in the Subprocess step has the Applies To field set to an object type.
You can configure the subprocess to run on a single object or on all objects in a specified list.
If you select Run on a single object, the subprocess runs on the specific object it receives as input. When execution completes, the subprocess passes control to the step that follows in the subprocess.
If you select Run on each object in list until, you also choose an event that controls the subprocess execution.
You can select one of the following values to define the event that controls the subprocess execution at run time:
•Field: Available for both the options, Run on a single object and Run on each object in list until, that is, when a single object or a list of objects is passed to the subprocess based on the selected Run choice. It contains the process objects or the salesforce connection fields available in the Connection Properties and Input Parameters.
•Query: Available only when you select the Run on a single object option. You can define a WHERE condition that selects the object passed to the subprocess.
•List: Available only when you select the Run on each object in list until option. You can define a WHERE condition that selects the objects passed to the subprocess.
The following image shows the iteration rule 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 and exception management. For example, you might want to add a Human Task step to a loan approval process.
To include a human task into a process, drag and drop the Human Task step from the palette to the canvas. Double-click the Human Task step and select the human task that was created in the human task asset.
The following image shows a Human Task step within an Application Integration process:
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.
Human Task
Select the human task that you want to include within the Application Integration process. The tab displays all the settings that were defined in the human task asset such as the task description, task priority, input fields, output fields, and assignments. The tab also displays whether the task is skippable or not.
Assignments
Select from the asset, field, or formula options corresponding to the Task Role field and assign a value to the field. By default, the Asset option is selected and the users and roles that were configured during task creation are retained. You can use the Field or Formula option to override the users and roles that were defined in the human task asset.
Enter the values in the input fields for the human task.
Outcomes
Displays a list containing the outcomes that you defined in the human task asset.
Fault Handling
Select the Catch Faults 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.
Note: The Human Task step is available for preview. Preview functionality is supported for evaluation purposes but is unwarranted and is not supported in production environments or any environment that you plan to push to production. Informatica intends to include the preview functionality in an upcoming release for production use, but might choose not to in accordance with changing market or technical circumstances. Note that if you are working on a preview POD, all data is excluded from SOC 2 compliance coverage. For more information, contact Informatica Global Customer Support.
Overriding assignments in human tasks
When you use a Human Task step in a process, you can override the users and roles that were defined in the human task asset using a formula or field. You can also use the Expression Editor to create simple expressions that only contain a field or complex expressions that include nested functions.
To override the assignments, perform the following steps:
1Click the Assignments tab.
The tab displays the users and roles that were defined in the human task asset.
2Click the Value From field to select the asset, field, or formula. Perform one of the following steps:
- Asset: Select the Asset option to retain the users and roles that were defined in the human task asset.
- Field: Select the Field option to select a field and override the value.
- Formula: Select the Formula option to use a formula to override the value. Use the Expression Editor to create a formula with expressions.
Create Step
Use the Create step to add new object instances. For example, if you work with an Account object, you can use the Create step to add a new account.
The Create step name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
The following image shows a Create step for the Account object:
To create new objects:
1Choose the Input Fields tab and select all the fields that you will be adding to the object. Some are required; others are optional.
2For each field name, set its source to one of the following values: Content, Field, or Formula.
You can also add an object by using the AutoMap option. For example, if you want to create an Account object in Salesforce, you can select the Salesforce connection and account object on the Create tab and select AutoMap on the Input Fields tab.
Application Integration matches the best possible fields based on the field names and assign as the input fields. Informatica does not guarantee exact field matches. After the fields are mapped, you must manually verify if the mappings are correct and update as needed.
Using Reference Fields
Note that:
•If you do not include a reference field on the Input Fields tab for the object you are creating, Process Designer uses the value of the current object at runtime.
•Reference fields for the Applies To object are set if they are not set explicitly in the Input tab.
•When the content of a reference field is set to empty, it is not included in the create statement. (This prevents problems that might occur when explicitly setting a field to empty or null could violate data constraints.)
Receive Step
A Receive step can be defined in processes that make a Service and wait for some event data before the process can continue. For example, if the order process includes a step to request more credit information when the order is above a certain threshold, then a Receive step allows you to handle the blocking receive call.
The Receive step name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
The output of a Receive step is available to be used later in the process, similar to output fields in Service steps.
For the Correlation Assignments, select the fields you are correlating with the incoming message event. You can use these assignments to cancel further execution of a request (interrupting) or to provide status (non-interrupting).
When you add a Wait step, you set some properties.
The following table describes the Wait step properties:
Property
Description
Name
The name of the Wait step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Wait
Properties that determine when and for how long the process pauses. You can choose from the following options:
- At a specific time
- After a wait period
Pause at a specific time
Select this option to pause the process at a particular time. Enter the Time you want the process to pause at, and optionally, a Delay. The Delay value can be an integer or a field that you define.
The following image shows the At a Specific Time option:
For example, set the process to pause at 1:00 am after three days. 1:00 am is the Time and three days is the Delay.
After a wait period
Select this option to pause the process after a period. The period begins when the process reaches the Wait step. Enter the Wait Period that you want the process to pause for. The Wait Period value can be an integer or a field that you define.
For example, set the process to pause for one hour from the time that the process reaches the Wait step.
The following image shows the After a wait period option:
Milestone Step
Use the Milestone step to specify one of two actions when the process ends.
The following image shows a Milestone step:
You can configure the following Milestone step properties:
Name
Displays the name of the milestone step. You can edit this value.
Ending Type
You can select one of the following values:
Milestone: Send Synchronous Response
Sends a synchronous reply to the original request. The reply has all the output fields defined in the Process Properties dialog. If a synchronous reply was already sent, no action occurs. This is not an error as it allows background and batch work to occur. You can have additional steps after a Milestone step to send a synchronous message, and then continue executing.
Note: If you insert a Milestone step into a Parallel Paths step, the Ending Type field must be set to Milestone: Send a Synchronous Response.
End of Process
No further action occurs when the process ends.
The default value is Milestone: Send Synchronous Response.
HTTP Status
Displays the HTTP response status code. The default value is 200 OK. You can edit this value.
HTTP Response Headers
Specifies the HTTP response headers and values that the REST API associated with the process must return after the process runs.
For example, you can configure a response header to return the organization ID. You can consume the header value that the process returns in downstream applications.
You can configure a response header to return a lookup value. Based on the lookup value that the process returns, you can make a decision and perform further processing in downstream applications.
You can configure the X-XSS-Protection HTTP response header to enable additional security for a REST API in various browsers.
Enter X-XSS-Protection as the header name and 1; mode=block as the value.
The X-XSS-Protection header enables cross site scripting (XSS) filtering. If the browser detects an XSS attack, it will not render the page.
You can add multiple response headers to the process by configuring the name and value for each header. The header name must be unique and cannot contain the following characters:
( ) < > @ , ; \\ / [ ] ? = { } _
The header name must also not contain non-English characters. If you want to provide a non-English character in the header value, you must encode the text in the Base64 format. The downstream application must decode the text to get the original content. You can add the values manually or enter a formula.
A process uses the following default HTTP response headers:
- access-control-allow-credentials
- cache-control
- content-encoding
- content-type
- date
- expires
- keep-alive
- status
- strict-transport-security
- transfer-encoding
- vary
- x-frame-options
- x-http-status
- x-instanceid
You cannot override the names and values of the default headers.
After the process runs, the API returns the HTTP response headers that you configured. You can view the response headers on the My Processes page in Application Integration or on the Processes page in Application Integration Console.
End Step
An End step indicates the end of the process. When execution reaches this step, the process completes.
You can configure the following End step properties:
Name
Displays the name of the end step. You can edit this value.
Ending Type
You can select one of the following values:
Milestone: Send Synchronous Response
Sends a synchronous reply to the original request. The reply has all the output fields defined in the Process Properties dialog. If a synchronous reply was already sent, no action occurs. This is not an error as it allows background and batch work to occur. You can have additional steps after a Milestone step to send a synchronous message, and then continue executing.
If you set the value as Milestone: Send a Synchronous Response, you see an option to select the next step.
End of Process
No further action occurs when the process ends.
The default value is End of Process.
HTTP Status
Displays the HTTP response status code. The default value is 200 OK. You can edit this value.
HTTP Response Headers
Specifies the HTTP response headers and values that the REST API associated with the process must return after the process runs.
For example, you can configure a response header to return the organization ID. You can consume the header value that the process returns in downstream applications.
You can configure a response header to return a lookup value. Based on the lookup value that the process returns, you can make a decision and perform further processing in downstream applications.
You can configure the X-XSS-Protection HTTP response header to enable additional security for a REST API in various browsers.
Enter X-XSS-Protection as the header name and 1; mode=block as the value.
The X-XSS-Protection header enables cross site scripting (XSS) filtering. If the browser detects an XSS attack, it will not render the page.
You can add multiple response headers to the process by configuring the name and value for each header. The header name must be unique and cannot contain the following characters:
( ) < > @ , ; \\ / [ ] ? = { } _
The header name must also not contain non-English characters. If you want to provide a non-English character in the header value, you must encode the text in the Base64 format. The downstream application must decode the text to get the original content. You can add the values manually or enter a formula.
A process uses the following default HTTP response headers:
- access-control-allow-credentials
- cache-control
- content-encoding
- content-type
- date
- expires
- keep-alive
- status
- strict-transport-security
- transfer-encoding
- vary
- x-frame-options
- x-http-status
- x-instanceid
You cannot override the names and values of the default headers.
After the process runs, the API returns the HTTP response headers that you configured. You can view the response headers on the My Processes page in Application Integration or on the Processes page in Application Integration Console.
Throw Step
You can use a Throw step to construct an error payload.
The following table shows the properties in a Throw step:
Property
Description
Name
Required. A descriptive name for the Throw step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Code
Required. A string value that contains the name of the faultInfo payload.
Detail
Optional. A string value that contains the faultInfo detail.
Reason
Optional. The faultInfo reason detail, which can be type $any.
Loop Step
A Loop step runs the steps configured within the loop until a certain condition is satisfied.
The following table describes the properties in a Loop step:
Property
Description
Name
The name of the Loop step. The name can contain only alphanumeric characters, hyphens (-), underscores (_), spaces, and Unicode characters.
Loop
Properties that determine the steps to run within the loop until a certain condition is satisfied. You can select one of the following options:
- While
- Repeat Until
Type
You can select one of the following options:
While
In the While loop, the process enters the loop only if the loop condition is satisfied. The While loop executes an activity repeatedly until its condition evaluates to false.
In contrast to the Repeat Until activity, the While loop might not execute the contained activity at all.
Repeat Until
In the Repeat Until loop, the process enters the loop but exits only when the loop condition is satisfied. The Repeat Until loop executes an activity repeatedly until its condition evaluates to true.
In contrast to the While activity, the Repeat Until loop executes the contained activity at least once.
Looping Criteria
You can select one of the following options:
Formula
You can create a condition using an XQuery function. You can also evaluate simple and complex expressions directly in the Loop step with no dependency on the prior steps.
Field
Select an input field, output field, or temporary field from the list of fields.
Enter the condition and value that you want the Loop step to base the step execution on.
The conditions available depend on the field you select.
For example, if you select a field of type Simple > Number, the following conditions are available:
▪ Equals
▪ Not equal to
▪ Less than
▪ Less than or equal to
▪ Greater than
▪ Greater than or equal to
▪ Is set
▪ Is not set
You can enter a value against the condition you select.
Note: You must set an initial value for the fields used in the loop condition. Otherwise, the loop becomes infinite.
Loop step example
You create a Loop step with the following properties:
Type: While
Looping Criteria: Field with value temp
Condition: Less than with value set to 5
You have a temp field with the initial value set to 1, and the temp field is configured to increment by 1 using the Assignment step within the Loop step.
The following image shows the While option with the looping criteria set to field in the Loop step:
In this case, when you run the process, the subprocess runs four times until the temp value reaches 4, and then the process comes out of the loop and runs the subsequent steps.
For the same process, if you create a loop with the following properties:
Type: Repeat Until
Looping Criteria: Formula with $temp.temp >5
The following image shows the Repeat Until option with the looping criteria set to formula in the Loop step:
In this case, when you run the process, the subprocess runs five times until the temp value reaches 5, and then the process comes out of the loop and runs the subsequent steps.
Rules and guidelines for using Loop step
Consider the following rules and guidelines when you use the Loop step in a process:
•You cannot use the Jump step within the Loop step. You cannot use the Jump step from inside the loop to outside or from outside the loop to inside.
•If you use the Receive step inside the Loop step, you must use a Milestone step after the Receive step within the Loop step to send a synchronous reply to the request.
•You cannot use the End step and Throw step within the Loop step.
•It is recommended that you use the modern view to edit a process that contains a Loop step. When you use the Loop step in a process and switch between the modern view and classic view, you might encounter issues. For more information, see the Informatica Knowledge Base article 000221431.
Note: The loop construct feature is available for preview. Preview functionality is supported for evaluation purposes but is unwarranted and is not supported in production environments or any environment that you plan to push to production. Informatica intends to include the preview functionality in an upcoming release for production use, but might choose not to in accordance with changing market or technical circumstances. Note that if you are working on a preview POD, all data is excluded from SOC 2 compliance coverage. For more information, contact Informatica Global Customer Support.
Decision Step
A Decision step allows a process to take different paths depending on the value of the field.
You can configure the following Decision step properties:
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, formulae, and paths you define here.
Use one of the following option to specify the path:
- Field. Select an input field, output field, or temporary field from the list of fields you defined under the Start step.
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:
▪ Contains
▪ Equals
▪ Starts with
▪ Ends with
▪ Starts with any of
- Formula. Open the formula editor to create a complex expression.
You can define a path and set appropriate conditions. You can also evaluate simple and complex expressions directly in the Decision step with no dependency on the prior steps.
When you select the Formula option and define the expression, the following conditions are available:
▪ Contains
▪ Equals
▪ Starts with
▪ Ends with
▪ Starts with any of
▪ Not equal to
▪ Less than
▪ Less than or equal to
▪ Greater than
▪ Greater than or equal to
However, you must select the appropriate conditions based on the return type of the functions used in the expression.
The following table describes the supported and unsupported conditions based on the return types:
Return type
Supported conditions
Unsupported conditions
String and Boolean
Contains
Equals
Starts with
Ends with
Starts with any of
Not equal to
Less than
Less than or equal to
Greater than
Greater than or equal to
Number and Integer
Contains
Equals
Starts with
Ends with
Starts with any of
Not equal to
Less than
Less than or equal to
Greater than
Greater than or equal to
None
DateTime
Contains
Equals
Starts with
Ends with
Starts with any of
Not equal to
Less than
Less than or equal to
Greater than
Greater than or equal to
Default is Field.
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.
A Decision step can lead to another Decision step. For example, a branch could run if an annual income exceeds $100,000. The next decision test along the same path could test if the city is Boston, or otherwise. Using this technique, you use Boolean AND logic because you base the test for the second condition on the true branch of the first condition. In this example, you use the Decision step to set the condition "Annual Revenue exceeds $100,000 AND city is Boston".
Similarly, to support Boolean OR logic, you can add a test for the second condition on any branch.
Parallel Paths Step
When you add a Parallel Paths step, you set some properties.
The following table describes the properties in a Parallel Paths step:
Property
Description
Name
The name of the Parallel Paths step. The name can contain only alphanumeric characters, underscores (_), spaces, and Unicode characters.
Parallel Paths
The paths that you want the process to run in parallel.
Note: When you use a Parallel Paths step, all the steps in all the branches will not start at the same time. There will be a time lag in the start time of the steps in all the paths. The execution of branches varies based on the steps used in each branch.
When more than one branch is running in sequence, if one branch pauses for a specific time, instead of waiting for the steps to complete in that branch, the process starts running steps from another branch in parallel. For example, if you have a Wait step in a branch and the process is paused for a specific time, the steps in a different branch starts running in parallel.
Click Add to add a new branch.
You can add multiple steps to each branch. To add steps to a branch, drag and drop a step from the pallette on the left.
When you use the Jump step in conjunction with the Parallel Path step, you can only jump to another step on the same Parallel Path branch.
Keep in mind the following restrictions when you use the Jump step and the Parallel Path step together:
- If you are in a Parallel Path step, you cannot jump to a step on another branch of the same Parallel Path step.
- If you are in a Parallel Path step, you cannot jump to any step outside the Parallel Path step.
- If you are outside a Parallel Path step, you cannot jump to any step inside the Parallel Path step.
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.
When you use the Jump step in conjunction with the Parallel Path step, you can only jump to another step on the same Parallel Path branch.
Keep in mind the following restrictions when you use the Jump step and the Parallel Path step together:
- If you are in a Parallel Path step, you can't jump to a step on another branch of the same Parallel Path step.
- If you are in a Parallel Path step, you can't jump to any step outside the Parallel Path step.
- If you are outside a Parallel Path step, you can't jump to any step inside the Parallel Path step.
- You can't jump to any step from the fault path. You must merge the fault path back to the main process path to add the Jump step.
- You can't jump to a step inside the fault path if you are outside the fault path.
Use the following best practices when you use the Jump step in a process:
- Instead of using a Jump step from an outside flow to a step inside the fault path, design the process by replacing the Jump step with the same flow as in the fault path.
- If you use a Jump step for iteration purposes and it points to a Service or a Subprocess step with fault handling, enclose the Service or Subprocess step with fault handling inside another Subprocess step.
