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 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.
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/public/soap/
/active-bpel/odata/repository/v4/OdataRepository/Execute
/activebpel-cert/services/
/activebpel-cert/odata/repository/v4/OdataRepository/Execute
/process-engine/public/rt/
/process-engine/services/
/process-engine/public/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.
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 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 batch size
Set the maximum number of suspended processes to terminate in a single run. You can set the batch size to control the overload on the system work manager thread pool.
Default is -1. A value of -1 means that is no limit 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.
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 Thread Pool Max
Set the maximum number of execution threads that the engine can spawn simultaneously. Default is 300. A value of -1 means that there is no maximum number of threads.
This property does not appear if Process Server is configured to use an application server Work Manager.
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.
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.
This property does not appear if Process Server is configured to use an application server work manager.
Work Manager Threads For Alarms Max
Set the maximum number of threads that 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.
