Design > Designing Processes > Setting Process Properties

Setting Process Properties

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:

You can view the General tab in the process 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.
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.
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.
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.
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: 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.
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.

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.

For more information on fields, see Introduction to Data Types and Field Properties.

XML Payload

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.

For example, if the XML is wrapped:

<root>
<oAddressPO>
<Street>3 Enterprise Drive</Street>
<State>CT</State>
<Zipcode>6484.0</Zipcode>
<City>Shelton</City>
</oAddressPO>
<oAddressPO>
<Street>31 Enterprise Drive</Street>
<State>CT1</State>
<Zipcode>106484.0</Zipcode>
<City>Shelton1</City>
</oAddressPO>
</root>

If the XML is unwrapped:

<root>
<_1>
<Street>3 Enterprise Drive</Street>
<State>CT</State>
<Zipcode>6484.0</Zipcode>
<City>Shelton</City>
</_1>
<_2>
<Street>31 Enterprise Drive</Street>
<State>CT1</State>
<Zipcode>106484.0</Zipcode>
<City>Shelton1</City>
</_2>
</root>

Output Field Properties

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.
Description	Description for the output field.
Initial Value	The initial value for the output field.

For more information on fields, see Introduction to Data Types and Field Properties.

Temporary Field Properties

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.

For more information on fields, see Introduction to Data Types and Field Properties.

Messages Properties

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.

For more information on fields, see Introduction to Data Types and Field Properties.

Correlated Message Events

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:

…/active-bpel/public/rt/00000I/OrderProcessor/event/CheckOrderStatus

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
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.

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:

•Allowed Users/Allowed Groups/Allow anonymous access
•HTTP authorization requests from the API Gateway
•Run On
•Tracing Level

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:

<Informatica Intelligent Cloud Services URL>/active-bpel/asset/v1/update?assetType=Process

You can add the input data as shown in the following sample:

PUT <baseApiUrl>/active-bpel/asset/v1/update?assetType=Process
Content-Type: application/json
Accept: application/json
INFA-SESSION-ID: <Infa-Session-ID>
{
"processes": [
{
"guid": {
"$t": "<guidvalue>"
},
"deployment": [
{
"key": {
"$t": "Allow Anonymous Access"
},
"value": {
"$t": "true"
}
},
{
"key": {
"$t": "Run On"
},
"value": {
"$t": "cloud server"
}
},
{
"key": {
"$t": "Tracing Level"
},
"value": {
"$t": "normal"
}
}
]
}
]
}

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:

{
"status": {
"$t": "FAILED"
},
"errorDetails": {
"error": {
"$t": "Update failed for assets"
},
"failedAssets": {
"updateAssetFaultInfo": {
"xmlns": "https://com.informatica.icrt/2021/08/updateAssets.xsd",
"xmlns$aetgt": "https://com.informatica.icrt/2021/08/updateAssets.xsd",
"name": {},
"GUID": {
"$t": "<Incorrect guid value>"
},
"fault": {
"$t": "The Secure Agent is not valid. Specify a valid Secure Agent."
}
}
}
}
}

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.