Properties

Summary

Server Properties

Allow proxy user in process invocations

A process can have a policy assertion (called Run as User) that enables a named user to be a process initiator, as opposed to the normal process initiator with credentials or an anonymous user. If desired, you can disable this property and the policy assertion is ignored. This setting applies to all new process instances and is enabled by default.

Auto create target path for Copy/To

Applies only to processes that are validated against the BPEL4WS 1.1 specification. For WS-BPEL 2.0 processes, this property can be added as an extension on a per process basis. Refer to the Process Developer Guide for more information.

This property determines if Process Server can create a location path for a non-existent node in a complex variable in a process instance document. When an assignment refers to a non-existent node (or to more than one node), the standard BPEL fault, bpws:selectionFailure, must be thrown, according to the BPEL specification.

Enabling this option allows selections to be created on-the-fly. This means an assign copy TO operation can refer to a non-existent node and assign a value to it. This option is disabled by default.

Contribution Cache

Setting this cache controls how many contributions are kept in memory. This cache avoids having to read the database too often. Generally contributions are small. However, the size depends on how many resources (that is, catalog entries) they contain and how many imports and exports they have.

Changing the default value depends on the number of deployed contributions and the amount of memory available. Default is 100 contributions. If a contribution is cached, it need not be looked up in the database. If you have more than 100, you may want to increase this value.

This cache setting doesn’t require much tuning and profiling the application server is probably required to determine if changing this value would improve performance.

This cache is not set in the Server Properties dialog. Instead, you will need to set this in the engine configuration file, which is aeEngineConfig.xml, which is contained in the activvos.war file.

Deployment Lock Timeout (seconds)

In a clustered environment, one machine acquires a deployment lock, and the other machines must wait until deployments are complete before starting .bpr deployments. If you have many machines in a Secure Agent cluster, you may need to increase the timeout value because each machine deploys many system .bprs upon start-up. Default is 120 seconds.

Deployment Plan Cache

A deployment plan corresponds to each deployed version of a process, including associated disposition of running processes. Process versions that are active can be cached for better engine performance. Default number of plans that are cached is 100. For details regarding versions, see Process Version Life Cycles.

Disable bpws:selectionFailure fault

Applies only to processes that are validated against the BPEL4WS 1.1 specification. For WS-BPEL 2.0 processes, this property can be added as an extension on a per process basis. Refer to the Process Developer Guide for more information.

This option allows an XPath query in the FROM clause of an assignment statement to return an empty node set. If it does, the target node for the assignment is deleted.

By default, this option is not enabled, and if the query string returns an empty selection from an assign copy FROM, the process throws a bpws:selectionFailure fault, which is the standard response described in the BPEL4WS specification.

Invoke Work Manager Thread Pool Max

Set the maximum number of execution threads that the Process Server can simultaneously initiate for process invocations. Default is 300.

Invoke Work Manager Thread Pool Min

Set the minimum number of execution threads that the Process Server allocates for process invocations. Default is 25.

Maximum HTTP Connections/Maximum HTTP Connections Per Host

If you have several HTTP Invokes within a process, the Invokes could spawn more than 100 connections. If this occurs, you should, you should increase the default maximum number of HTTP Connections value so that multiple threads are not suspended waiting to create a HTTP Connection. (You will see service call timeouts when this happens.)

Changes you make do not occur until you restart the server.

Message size limit

Sets the maximum size of the payload for a multi-part message that does not have attachments.

If you use the Informatica Cloud Server, you can set a maximum message payload size of 5 MB.

If you use a Secure Agent, the default value is 5 MB, but you can change set a higher or lower value.

Message TTL (seconds)

Specifies the amount of time between the time a message reaches the Process Server and the time when it is about to get dispatched to the target process. Default is 24 hours.

When you configure the message time to live (TTL) period and invoke a process by using the REST or SOAP endpoint, if the HTTP message is not dispatched within the message TTL period, the request fails. You see the HTTP error 503 Service Unavailable with the following error message:

Message discarded having exceeded the defined TTL.

The message TTL is applicable to the endpoints with the following entries:

• - /active-bpel/services/
• - /active-bpel/public/rt/
• - /active-bpel/rt/
• - /active-bpel/public/soap/
• - /active-bpel/soap/
• - /active-bpel/odata/repository/v4/OdataRepository/Execute
• - /active-bpel/tf/
• - /activebpel-cert/services/
• - /activebpel-cert/rt/
• - /activebpel-cert/soap/
• - /activebpel-cert/odata/repository/v4/OdataRepository/Execute
• - /process-engine/rt/
• - /process-engine/public/rt/
• - /process-engine/services/
• - /process-engine/public/soap/
• - /process-engine/soap/

Message with attachments size limit

Sets the maximum size of the payload for a multi-part message that has attachments.

If you use the Informatica Cloud Server, you can set a maximum message payload size of 5 MB. The maximum size for attachments is also 5 MB.

If you use a Secure Agent, the default message payload size is 5 MB and the default attachment size is 5 MB. You can change the default sizes to set higher or lower values.

Migrate running processes even on warning

If Migrate is selected as a deployment option on a contribution, running processes are migrated to the new process version. The server checks for compatibility between the old and new process plans and generates a warning in the Process Server Log if an incompatibility exists.

Be sure that the Process Server Log is set to at least Warning Level before any migration is attempted.

If this property is disabled (the default), and if a warning condition exists for one or more running process instances, a copy of each running process instance is created, and both the pre-migration copy and the new copy are suspended. Additionally, a warning code/message is added to the Process Server Log.

If this property is enabled, no copy of the running instance is made if a warning condition exists. The only action is that a warning code/message is added to the Process Server Log.

For details, see Migrating Running Processes when Warnings are Generated.

Process Count

Specifies the maximum number of processes in memory. Default is 250. Specifying 0 indicates no limit, but this is not recommended.

Process Idle Timeout

Specifies the number of seconds to wait until process state information is written to the database during idle processing times such as waiting for a reply from an invoked service. You can increase the timeout value to enhance engine performance. You can decrease the value to ensure the full process state is always in the database. Doing so avoids potential process recovery time in the event of a server failure. Default is 10 seconds.

Resource Cache

The number of WSDL files and other resources in stored cache. Default is 100. Modifying the cache size may improve engine performance. A value of -1 means unlimited caching, but this is not recommended.

Running processes suspension limit per run

Set the total number of running processes to suspend in a single scheduled run. You can set the limit to control the overload on the system work manager thread pool.

For example, the total number of running processes is 500, and you set the limit to 100. For the first scheduled run, only 100 running processes are suspended. The remaining 400 will have to wait until the next scheduled run.

Default is -1. A value of -1 means that no limit is set for suspending running processes, and all the running processes will be suspended.

Running processes suspension timer interval (minutes)

Set the time interval in minutes at which the running processes must be suspended.

Default is 1440 minutes. This means that after 24 hours, the running processes start suspending.

Screen Cache Size (MB)

Sets the size of the cache Process Server uses for storing screens used by guides. Guides can be large in size when they are published and generally not every single path in the guide is always executed. This cache holds the HTML for the most commonly used screens within a guide. This improves the time required to load a screen as the guide containing the screen need not be loaded.

Suspend long running processes after (days)

Running processes might stay in the Active Processes list indefinitely, if they are not otherwise resolved.

Enter the number of days to retain running processes, for example, 30 days. The running processes are suspended automatically after the retention period is reached.

Default is 0. This means that the running processes are never suspended. For processes running on the Cloud Server, this option is determined by Informatica.

Suspend process on invoke recovery

For invoke activities which do not complete due to the node failure, you can suspend the process upon recovery. The process is suspended at the pending invoke, and you can perform process exception management, if desired.

An individual process can override this setting with an entry in the PDD file.

Suspend process on uncaught fault

According to the WS-BPEL 2.0 specification, a process with an uncaught fault terminates.

Enable this option to suspend all processes on an uncaught fault to put them in a suspended-faulting state. You can then perform process exception management on the faulting process such as retrying or completing the faulting activity or scope.

An individual process can override this setting with an entry in the PDD file. See Exception Management Type.

See Process Exception Management.

Suspended processes termination limit per run

Set the total number of suspended processes to terminate in a single scheduled run. You can set the limit to control the overload on the system work manager thread pool.

For example, the total number of suspended processes is 500, and you set the limit to 100. For the first scheduled run, only 100 suspended processes are terminated. The remaining 400 will have to wait until the next scheduled run.

Default is -1. A value of -1 means that no limit is set for terminating suspended processes, and all the suspended processes will be terminated.

Suspended processes termination timer interval (minutes)

Set the time interval in minutes at which the suspended processes must be terminated.

Default is 1440 minutes. This means that after 24 hours, the suspended processes start terminating.

System Work Manager Thread Pool Max

Set the maximum number of execution threads that the engine can spawn simultaneously. Default is 300.

If the number of threads being run is equal to this value, processes can fault as no threads are available when a node needs to broadcast information to other nodes. To be safe, you should create a secondary pool to be used by Process Server. This is done in the Application Integration Console. Process Server will only use threads in this pool when critical system work must be performed.

System Work Manager Thread Pool Min

Set the minimum number of execution threads that the engine allocates for its work manager. Default is 25. Specify enough execution threads to run the number of processes plus the number of simultaneous invokes that processes might execute.

Terminate suspended process after (days)

Suspended processes stay in the Active Processes list indefinitely, if they are not otherwise resolved.

Enter the number of days to retain suspended processes, for example, 30 days. The suspended processes are terminated automatically after the retention period is reached.

Default is 0. This means that the suspended processes are never terminated. For processes running on the Cloud Server, this option is determined by Informatica.

Unmatched Correlated Receive Timeout

Sets the number of seconds that the Process Server waits to match a correlated message to a message activity or an event activity if the message arrives before the activity becomes active. Set this value to avoid many unconsumed messages on the server.

Default is 30 seconds. If you enter an Unmatched Correlated Receive Timeout of 0 seconds, the Process Server discards all unmatched correlated messages when they arrive.

If the Process Server crashes, it recovers messages and continues to wait until a relevant consumer consumes the messages, or until a timeout occurs.

If the Process Server waits for a time that is longer than the value you specify, a timeout occurs. When a time out occurs, the Process Server adds a correlation violation error to the server log. This correlation violation error does not contain any message details. The correlation violation error contains a unique hash key called AeSecuredLogDatakey, a concatenation of the Engine ID, Plan ID, Queue ID, and Timestamp in milliseconds of when error occurred.

The following is a sample correlation violation error:

correlationViolation [AeSecuredLogDatakey=786000_123456_1000_1476434734123;tenant=ABCDEF; planId=123456;partnerLink=MessageEvent1EventPL;operation=Initiate]

To view message details such as the service name, operation name, and message parts, search for AeSecuredLogDatakey in the AeSecuredLogData table.

The correlation violation error contains the hash key and not the message details because the message details might contain secure information. This two-step method secures your data.

Validate input/output messages against schema

Validates the data used in service interactions against their associated schema.

Enable this option to validate data before execution starts. Disable this option for faster execution. This option is enabled by default.

Web Service Invoke/Reply Timeout

For performance reasons, a reply activity matching a receive, as well as synchronous invokes, are timed out if they do not execute within 10 minutes. If you are receiving timeout errors, you can specify a greater amount of time to wait before a process is timed out due to a reply or synchronous invoke activity not executing within 10 minutes.

Default is 600 seconds.

Work Manager Threads For Alarms Max

Set the maximum number of threads the engine will use from the work manager to dispatch work scheduled by an alarm in a process. If there are 100's of alarms firing concurrently, all of the threads in the work manager could be used just to dispatch the alarms. If you experience performance issues or deadlocks because the alarm manager is using all of the threads, you can increase this value. Default is 5.

Work Manager Threads For Process Migration Max

Increase the thread count if you have hundreds of processes to migrate. This count is on top of execution threads for the server. Default is 50 and affects the number of threads allocated for new receives. For details, see the server property above, Migrate running processes even on warnings.

Work Manager Threads Per Process Max

Set the maximum number of execution threads the engine can spawn simultaneously for an individual process. Default is 10.

Thread pool profile for event-based connections

Thread Pool Min

Set the minimum number of execution threads allowed in the pool. Default is 10.

Thread Pool Max

Set the maximum number of execution threads allowed in the pool. Default is 20.

Queue Size

Set the maximum number of asynchronous actions that can be queued by the Process Server. Default is 1000.

When the core threads are busy, and the queue is full, Process Server adds additional threads up to the maximum thread count to handle additional tasks. Subsequently, if the queue receives additional tasks, Process Server rejects the tasks.

For example, if you push 10 tasks, they will be handled by the 10 core threads. The Process Server adds any additional tasks to the queue. When the queue reaches 1000 and you try to push more tasks, Process Server adds up to 20 additional threads, which is the maximum number of threads that can be allocated to the tasks. After this, when the maximum pool size is reached and the queue is full, the Process Server rejects the tasks.

JMS Exception Listener

Logging