1In Application Integration, click New to open the New Asset window.
2Select Processes > Process, and then click Create.
The Process Designer opens.
The following image shows the Start Properties panel:
3Enter the required properties.
4Optionally, to view or edit the process properties, click the Start step.
5Click Save.
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.
You can select one of the following values:
- REST/SOAP: Select the REST/SOAP binding type if you want to run the process by using a service URL. When you select this option, you can use the Allowed Groups and the Allowed Users fields to define the user groups and users who can run a published process as an API. If you do not want to assign any user, you can select the Allow anonymous access option.
- Event: Select the Event binding type if you want the process to be invoked when the specified event occurs. For example, a process can be invoked upon an event such as arrival of a file in a file system. The Event Source Name field is available where you can select an event source.
Default is REST/SOAP.
Allowed Groups
The groups that have access to the process service URL at run time. If the users in the group also have the Run privilege, they can invoke the process service URL.
Use the Allowed Groups field when you want a group of users to have access to a service URL. For example, you have a group called 'Order Approvers'. If you enter Order Approvers in the Allowed Groups field, all users within the group will have access to the service URL.
The following image shows the Order Approvers group added to the Allowed Groups field:
You can enter more than one group in the field.
You can configure the Allowed Groups and the Allowed Users fields. If a user falls into either the Allowed Groups or the Allowed Users category, the user will have access to the service URL.
If you configure the Allowed Groups or the Allowed Users field, and select the Allow anonymous access option, the entered group or user details disappear.
If you select the Allow anonymous access option, the Allowed Groups and the Allowed Users fields are not available for edit.
If you do not configure the Allowed Groups or the Allowed Users field, or do not select the Allow anonymous access option, no service URL is available for the process. However, you can call the process as a subprocess.
If you want the process to appear in API Manager, you must either select the Allow anonymous access option, or configure the Allowed Groups or the Allowed Users field. For more information about managing APIs, see the API Manager help.
If a process uses the Allowed Groups or the Allowed Users fields, you can use one of the following ways to invoke the process through a REST client such as Postman:
- Use basic authentication, and enter the user name and password.
- Use session ID in the HTTP header to invoke the process without providing the user name and password.
For example, to invoke a process service URL using Postman, authenticate the GET request in one of the following ways:
- Use basic authorization and specify the Informatica Intelligent Cloud Services user name and password.
To get the SESSION-ID, use the Platform REST API version 3 login resource. For more information about the login resource, see REST API Reference.
Allowed Users
The users that have access to the process service URL at run time. If the users also have the Run privilege, they can invoke the process service URL.
Use the Allowed Users field when you want a specific user to have access to the service URL.
The following image shows the user jsmith in the Allowed Users field and the group Order Approvers in the Allowed Groups field:
In this process, users in the Order Approvers group and the user jsmith will have access to the service URL.
You can enter more than one user in the field.
If you configure the Allowed Groups or the Allowed Users field, and select the Allow anonymous access option, the entered group or user details disappear.
If you select the Allow anonymous access option, the Allowed Groups and the Allowed Users fields are not available for edit.
If you do not configure the Allowed Groups or the Allowed Users field, or do not select the Allow anonymous access option, no service URL is available for the process. However, you can call the process as a subprocess.
If you want the process to appear in API Manager, you must either select the Allow anonymous access option, or configure the Allowed Groups or the Allowed Users field. For more information about managing APIs, see the API Manager help.
If a process uses the Allowed Groups or the Allowed Users fields, you can use one of the following ways to invoke the process through a REST client such as Postman:
- Use basic authentication, and enter the user name and password.
- Use session ID in the HTTP header to invoke the process without providing the user name and password.
For example, to invoke a process service URL using Postman, authenticate the GET request in one of the following ways:
- Use basic authorization and specify the Informatica Intelligent Cloud Services user name and password.
To get the SESSION-ID, use the Platform REST API version 3 login resource. For more information about the login resource, see REST API Reference.
Only accepts HTTP authorization requests from the API Gateway
Select this option to enable OAuth2 authentication for the process and configure the API to accept only HTTP authorization requests from the API Gateway.
To invoke the API from the API Gateway, the following users must complete configuration tasks:
API provider
The API provider must perform the following tasks:
1Create a managed API for the process in API Manager and enable OAuth2 authentication for the managed API.
2Create an OAuth2 client in API Manager, and generate the client ID and client secret.
3Send the Informatica Intelligent Cloud Services OAuth 2.0 server URL and the client credentials to the API consumers.
API consumers
API consumers must perform the following tasks:
1Authenticate against the Informatica Intelligent Cloud Services OAuth 2.0 server and use the OAuth 2.0 client credentials to generate an OAuth 2.0 authorization token.
2Use the OAuth 2.0 authorization token to invoke the API.
For more information about creating an OAuth2 client and invoking an API with OAuth2 authentication, see the API Manager help.
Note: You can use the Only accepts HTTP authorization requests from the API Gateway option only for processes that run on the Cloud Server. Processes that use the Only accepts HTTP authorization requests from the API Gateway option can also be scheduled and run with one or more process inputs.
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.
If you select the Allow anonymous access option, the Allowed Groups and the Allowed Users fields are not available for edit.
If you configure the Allowed Groups or the Allowed Users field, and select the Allow anonymous access option, the entered group or user details disappear.
If you do not configure the Allowed Groups or the Allowed Users field, or do not select the Allow anonymous access option, no service URL is available for the process. However, you can call the process as a subprocess.
If you want the process to appear in API Manager, you must either select the Allow anonymous access option, or use the Allowed Groups or Allowed Users fields. For more information about managing APIs, see the API Manager help.
Applies To
The type of object associated with the process. The objects that display in this list are the process objects you defined separately or generated in a defined connection. Drill down the list to see process objects and connections, and then select one of these items. Select a process object only if the process will be embedded in another process.
Note: To change the Applies To property of a published process, you must first unpublish the process. Then, change the Applies To property and republish the process
There are two special values:
- Any: Choose Any if you do not want to associate the process with a specific object. When you select this option, the process does not automatically have access to an object's fields.
Use this object type when a process creates a new object and does not access information within existing objects.
- Home (Salesforce): Select Home if you want a process to be visible from Home or any initial location where users launch all processes, regardless of the object type.
Note: If you directly invoke a process, the Applies To setting must be either Any or a specific object in a service, but not a process object.
Run On
Use this list to specify where the process must run. You can select Cloud Server, a specific agent, or a Secure Agent group.
If a process uses a connector that is event based, ensure that you run the process on the same agent that the connector runs on.
When the process is in the published state, the Run On list is disabled. To enable the Run On list, you must first unpublish the process. Then, change the Run On field value, and republish the process.
If you include a Human Task step in a process, you must run the process on Cloud Server.
Input Field Properties
The input fields available for a process are those contained in the object(s) to which the process applies. This is specified in the Applies To property (on the Start tab).
The Input field values are available in all steps of the process. You must define a name and type for the input field category for use 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. When you select Whole Payload, the input field represents the entire content of the request. For example, if you have a customer process object, its contents might be:
"customer": {"name" :"Joe Smith", "street":"3 Main St", "city":"Shelton", "state":"CT"}}
If you check this option, the following would be posted:
{"name" :"Joe Smith", "street":"3 Main St", "city":"Shelton", "state":"CT"}
Name
The name of the input field.
Type
The type of the input field. For example, select Date, Date Time, Time, Integer, or Text.
You can also add an input field of a simple type, custom type, or connection defined type. To do this, select More types, and then in the Edit Type dialog box, select the Category as Simple Types, Custom Types, or Connection defined Types.
Description
Description for the input field.
Required
If the field is required for a process to execute, check Required.
In JSON syntax, a root container is not required. If the payload is XML, however, the root element is required. When it sends XML, Process Designer always adds a root node. If the payload is XML, Process Designer always adds a root node when it sends the request.
The output fields available for a process are those contained in the object(s) to which the process applies. This is specified in the Applies To property (on the Start tab).
The Output field values are set when the process executes and are then available in the steps that follow. Define output fields only for use in an embedded process. These output fields do not appear in lists until the values are returned from an embedded process. You define a name and type for the output field category for use in a process.
Property
Description
Output Format
Determines whether the output field can represent one or more fields of the response, or the entire contents of the response. When you select Whole Payload, the output field represents the entire content of the response.
Name
The name of the output field.
Type
The type of the output field. For example, select Date, Date Time, Time, Integer, or Text.
You can also add an output field of a simple type, custom type, or connection defined type. To do this, select More types, and then in the Edit Type dialog box, select the Category as Simple Types, Custom Types, or Connection defined Types.
The temporary fields available for a process are those contained in the object(s) to which the process applies. This is specified in the Applies To property (on the Start tab).
The temporary field values will be used in all of the current process's steps. However, a temporary field's value is not available to an embedded process. You define a name and type for the temporary field category for use in a process:
Property
Description
Name
The name of the temp field.
Type
The type of the temp field. For example, select Date, Date Time, Number, Percent, Time, Currency, Integer, or Text.
You can also add a temp field of a simple type, custom type, or connection defined type. To do this, select More types, and then in the Edit Type dialog box, select the Category as Simple Types, Custom Types, or Connection defined Types.
Description
Description for the temp field.
Initial Value
The initial value for the temp field. Default is 0 if the data type is Number, Percent, Currency, or Integer.
If needed, you can define one or more message events for this process.
For each message, you can define the following properties (similar to Start events):
Property
Description
Input Fields
Specify the field name.
Select the type for each input field. For example, select Date, Date Time, Time, Integer, or Text.
You can also add an input field of a simple type, custom type, or connection defined type. To do this, select More types, and then in the Edit Type dialog box, select the Category as Simple Types, Custom Types, or Connection defined Types.
If the field is required for the message to be valid, select Required.
If this field is used for a correlated message receive event, select Use for Correlation.
Output Fields
Specify the field name.
Select the type for each output field. For example, select Date, Date Time, Time, Integer, or Text.
You can also add an output field of a simple type, custom type, or connection defined type. To do this, select More types, and then in the Edit Type dialog box, select the Category as Simple Types, Custom Types, or Connection defined Types.
Binding
Select REST/SOAP or Event, depending on how this message is called.
Allowed Users/Groups
Enter the users and groups who can access this message.
Allow Anonymous Access
When checked, anyone can use this message without any authentication.
Note: If you enable this option, Process Designer ignores any limits you set with Allowed Users/Groups.
Input format is Whole payload
The input field can represent the entire contents of the request contained in this message.
Output format is Whole payload
The output field can represent the entire contents of the response. The way in which this changes a payload is the same as for an input field.
When you design a process, you can use message events in connection with the Receive step to interact with a process after the process has started execution. For example, you might want to:
•Query the status of a process
•Update data or provide control to the process
Based on one or more input parameters that uniquely identify the process, the process engine matches the correlated message events with their intended business process instances.
For example, a purchase ordering process might have an OrderId property. Messages can store the value of OrderId in different parts of the order process using different names and you associate a specific process instance with a unique OrderId. When a message arrives with the correlated OrderId, it is dispatched to the correct process instance. You can create as many correlation sets as you need.
Correlation matches incoming messages with their intended business process instances, so business processes can support asynchronous request/response patterns. (By comparison, synchronous calls need not rely on correlation because the message context is maintained on the stack or across a TCP connection.)
You define message events at the process level. A message event can be either interrupting or non-interrupting.
Before You Use Correlation
Take these steps before you define a set of correlated message receive events:
•Identify the Process Designer steps that need to be correlated. They should share one or more pieces of common data.
•Define a property that identifies the piece of common data.
•Define a correlation set of data so you can implement this in Process Designer.
Message Event Design Guidelines
When you define correlated message events, note that:
•For each message event you define in the process properties, at least one input field should be designated as Use for Correlation. If this Input field is a Reference type (a process object), also specify a path to a simple-typed field (with a choice of "field" or "formula").
•You can use event inputs and outputs as fields in the process but they are available only downstream of the Receive step (similar to outputs of Service steps).
•If you use multiple message event definitions and two input parameters in different message events have the same name, they should have the same type and same correlation path, if the input parameters are used for correlation. This ensures that you can have a single correlation value for a step.
You also specify whether it is interrupting or non-interrupting.
With an interrupting message event:
•The event terminates the step.
•The event path can merge with main path.
•The event path must have a milestone, which serves as the reply to the message event receive step.
With a non-interrupting message event:
•The process does not wait for the message event.
•The event path must end with an end step, which serves as the reply to the message event receive step.
Client Interaction to Invoke a Message Event
You can invoke a message event similar to a process, but using a different endpoint. For example, the endpoint to start a process might be:
…/active-bpel/public/rt/00000I/OrderProcessor
To invoke a specific message event, you would use an endpoint similar to:
To learn more about concepts related to correlated message events, also see the Process Developer Guide.
Advanced Properties
You can configure advanced properties to define fault handling, tracing, and Cross-Origin Resource Sharing (CORS) support 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
Persistence Level
Regardless of the tracing level that you configure, Process Server uses full persistence in the following situations:
- When you select the Suspend on Uncaught Fault option
- When a process includes a timer such as a Wait step, a message event, or a receive event
- When one process invokes another process to provide subprocess coordination.
For more information about different persistence levels, see Monitor.
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.
For more information about different logging levels, see the Administrator online help.
Automatic reset of tracing levels
In a process that is configured to run on the Cloud Server, if you set the tracing level to Verbose or Normal, the tracing level will be reset to Fault by the server, if necessary. This automatic reset feature helps in reducing the process execution time caused by the run-time logging.
Note: The automatic reset of tracing levels feature is in technical preview. Technical preview functionality is supported but is unwarranted and is not production-ready. Informatica recommends that you use in non-production environments only. Informatica intends to include the preview functionality in an upcoming GA release for production use, but might choose not to in accordance with changing market or technical circumstances. For more information, contact Informatica Global Customer Support.
Enable CORS
By default, API consumers can invoke a process from the domain that is part of the service URL. API consumers can use the GET, POST, PATCH, PUT, and DELETE verbs to invoke a process.
Select the Enable CORS option to enable Cross-Origin Resource Sharing (CORS) support for a process. You can also specify the allowed domains and allowed verbs for CORS support.
In the For Domains field, specify additional allowed domains from which API consumers can invoke the process. Enter the wildcard character (*) to enable CORS for all domains. Enter a comma-separated list of domains to enable CORS for specific domains. For example, enter the following phrase to enable CORS for the abc.domain.com and xyz.domain.com domains:
abc.domain.com,xyz.domain.com
If you enable CORS but leave the For Domains field blank, you can invoke the process only from the domain that is part of the service URL.
In the For Verbs field, specify the allowed verbs that API consumers can use to invoke a process from the domains that you specified in the For Domains field. Enter a comma-separated list of verbs to enable CORS for specific verbs. For example, enter the following phrase to enable CORS for the POST, PUT, and GET verbs:
POST,PUT,GET
Default is all verbs.
API consumers can invoke the process with all verbs from the domain that is part of the service URL.
Notes
Use the Notes tab to add information that you or other developers might need. The Notes you enter display only at design time. The guide or process users or consumers do not see the notes. For example, you might add a reminder about something that needs to be done before you deploy a process or guide.
Updating field values for processes
You can use the update resource to update the values for the following fields for existing processes:
You can update fields for a single process or multiple processes. To update the processes using the update resource, you must be assigned the Admin, Deployer, Designer, or Operator role.
You can add the process and fields that you want to update as input data in a REST client such as Postman. The input data consists of the Global Identifier/Global Unique Identifier (GUID) of the process and a key-value pair of deployments to be updated. For more information about GUID, see the lookup resource and finding assets resource in REST API Reference in the Data Integration help.
To update the field values, use the following URL:
You can use the login resource to get the INFA-SESSION-ID. For more information about the login resource, see REST API Reference in the Data Integration help.
If the fields are successfully updated, you receive the following response:
{ "status": { "$t": "SUCCESS" } }
If you enter an invalid Secure Agent, you receive the following response:
Rules and guidelines for updating fields in a process
Consider the following rules and guidelines when you use the update resource to update the fields in a process:
•You must set either the Allowed Users/Allowed Groups or Allow anonymous access field at a time. Otherwise, an error occurs.
•You must set either the HTTP authorization request from the API Gateway or the Allow anonymous access field at a time. Otherwise, an error occurs.
•In the HTTP authorization request from the API Gateway and Allow anonymous access field, you must specify the value as true or false. If you specify any other value such as yes or no, an error occurs.
•In the Tracing Level field, you must specify one of the following values: None, Terse, Normal, or Verbose. Otherwise, an error occurs.
•If you set the HTTP authorization request from the API Gateway value to true, you must specify the value for the Run On (runtime environment) field as Cloud Server. If you specify the run on value as Secure Agent, an error occurs.
•If you want to update the runtime environment value for a published process, you must first unpublish the process.
