You can configure an email or a custom service to run when a process stops because of a fault.
The Alert Service is available for processes that run on a Secure Agent or the Cloud Server.
To receive alerts, set the Suspend processes on uncaught fault property described in Server Properties or enable this option for processes defined in Process Designer.
Alert services are specific to the Cloud Server or the Secure Agent you select on the Application Integration Console. When you use Informatica Cloud, you can configure one Alert Service for the Cloud Server, and one for each Secure Agent to receive alerts.
You can choose one of two options when you configure an Alert Service:
•Send Email. Use this option to send an email to a single specified recipient when the suspended or faulting process state occurs. You must configure an Email Service before you use this option.
•Custom Service. Use this option to deploy a custom process. For example, you can deploy a process that notifies an administrator of a process fault. You can create a custom service in the following ways:
- If you use the Process Developer, specify the service name that appears in the PDD file used with the custom service in the Service field. This service name appears on the Service Definitions page of the Application Integration Console. For details on how to define a custom alert service, see the Process Developer help.
- If you use the Process Designer, create a process and do the following steps:
1Set the Start Event to Event.
2Next to Event Source Name, select System Events, and then Runtime Alert Service.
Note: With the Process Designer, you can define more than one process with a start event of Runtime Alert Service. However, you configure one process with the Alert Service.
Select Enable Alert Service to use the Alert Service and click Update to save your changes.
Email Service
You can configure an email service to use, for example, in connection with an alert service triggered when processes are suspended on an uncaught fault. The email service settings enable you to send an email to a specified administrator.
If you execute processes designed with Process Designer, you can use Application Integration Console to configure one email service to use for processes that run on a Secure Agent and another email service for your organization's processes that run on the Cloud Server. You can then use the Send Email option when you define an Alert Service to send notifications when a process is suspended on an uncaught fault.
To define an email service, configure the following properties:
Property
Description
Enable SMTP Service
Select to enable the email service after you have configured all the properties.
Host
Enter the email server’s DNS name such as mail.mydomain.com or an IP address such as 192.168.1.1.
Port
Enter the port to use for communication between the Process Server and the email server. The default value is 25.
Authentication Type
Select password-based authentication or OAuth authentication.
To create the email connection using password-based authentication, configure the following properties:
Property
Description
Username
Required. Enter the name used to log in to your email server, usually the account name. This field is optional depending on whether the SMTP server requires credentials.
For example: notifyme@mydomain.com
Password
Required. Enter and confirm the password for the user name.
Security
(Optional). Select a security protocol, if desired:
- TLS (Transport Layer Security)
- SSL (Secure Sockets Layer)
Ensure that you configure the port to enable the appropriate security transport.
To create the email connection using OAuth authentication, configure the following properties on the connection creation page:
Property
Description
Authorization URL
Required. Enter the OAuth authorization URL for the email service that is used to authorize the user request.
For example: https://login.microsoftonline.com/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/oauth2/v2.0/authorize
Token Request URL
Required. Enter the OAuth token request URL that handles token requests.
For example: https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/v2.0/token
The refresh token expires in 90 days. The user must authenticate again and publish the connection before the token expires.
Client ID
Required. Specify the identifier value from the OAuth provider.
Client Secret
Required. Enter the client secret to connect to the email application.
Scope
Required. Specify the scope. The scope in OAuth authentication limits an application's access to a user's account. You can select multiple scopes for a single client. To enter multiple scopes, separate each value with a space.
For a Microsoft Outlook email account, enter the following scope:
Indicates the current status, the name of the user who authorized, and the last time when the authorization was completed.
Authorize Access
Click to initiate the authorization workflow using OAuth.
Test the configuration, and then save it.
Shell Service
The Shell Service option enables you to define processes that include a shell command in a Service Call step, for processes that run on a Secure Agent.
After you enable the shell service, create a process with a Service step and add the shell command as a system service.
Messaging Service
You only see this tab if you have selected a Secure Agent.
Use this page to configure parameters for one or more JMS Messaging Services so that Process Server can establish connections to the JMS provider.
Use the Action list to control the messaging service's execution. First, select the Manager Name in the list and choose the Action (Start, Stop, Restart, Delete). Then, click Execute.
Setting Up a Messaging Service
To set up a messaging service, click Add and enter the following properties:
Default JMS Provider
For the provider selected in JMS Provider Type, enable this provider as the default, if desired. You can select one provider as the default, if you are setting up multiple services.
JMS Provider Type
List of configuration templates that contain some pre-defined default settings for the type of JMS provider being used. Theoretically, any provider that provides JNDI access to JMS resources can be used. If the specific provider is not on the list, you can select Other JMS to populate the configuration with some commonly used, generic JNDI properties.
Connection Factory Name
The JNDI name of the JMS connection factory.
Connection User
Include user credentials when creating connections on the connection factory. With providers hosted by an application server, this is usually not required since authentication takes place when accessing objects through the JNDI context. MQ Series is one provider that requires connection credential.
Connection Password
Password for the above user.
Send Empty Credentials
For MQ Series, when connecting to a remote queue manager when authentication is not enabled. You need to send empty strings ("") as username/password on the connection or it will fail with a security exception.
Maximum Total Connections
Each JMS Manager maintains an internal pool of connections to enhance performance when interacting with a remote JMS provider.
Sets the maximum number of active connections allowed at any one time. This includes connections used for asynchronous listeners configured under Queues and Listeners and Topics and Listeners as well as those used for invoke activities. If the maximum is reached, clients must wait until a connection is returned to the pool.
Setting the maximum value to -1 indicates that the manager may create as many connections as needed, with no upper limit so clients never have to wait. Change this value from the default of -1 if more connections are being created than the JMS provider can handle.
This value should be set to one of the following:
- -1 (unlimited)
- A number higher than the total number of listeners for both queues and topics and plus some connections for invokes
Maximum Free Connections
Sets the number of unused connections the manager retains at any one time. If a connection is returned to the pool, and there are already the maximum free connections sitting idle, the connection is closed. This allows the total number of connections from the pool to shrink and grow as necessary. Setting the maximum free connections to 0 prevents the Process Server from holding onto connections. Each client receives a newly created connection.
Ensure that the free connections value is lower than the value for Maximum Total Connections.
Delivery Mode
This setting controls whether or not the JMS provider persists messages to storage for all processes. An individual process can have a different persistence setting, which overrides this setting.
Enable this setting to persist messages in the event of a JMS failure. When this mode is enabled, Process Server instructs the JMS provider to ensure that a message is not lost in transit in case of a JMS provider failure. It is logged to stable storage.
Note that persistent delivery requires that your JMS provider be configured with storage. Also, there is usually a performance hit with persisting messages.
The default is disabled, which means the messages are sent with non-persistent delivery mode. This mode does not require any knowledge of how a provider is configured for storage.
Time to Live (ms)
Specifies the amount of time for which an unconsumed message remains on a queue. If a message will become obsolete after a certain period, you might want to set the time to live period. The expiration of obsolete messages conserves storage and computing resources.
Default is 0, which means that the default for the provider is used. Typically, this means that messages never expire and remain on the queue forever.
If you configure the time to live period and invoke a process by using the REST endpoint. If the HTTP message is not consumed within the time to live period, the request fails. You see the HTTP error 503 Service Unavailable with the following error message:
Message discarded having exceeded the defined TTL.
Priority (int)
Specifies a non-negative integer for a message handling priority. Default is 0, which means that the default for the provider is used. An individual process can specify a priority, which overrides this setting.
JMS defines a 10-level priority value with zero as the lowest and nine as the highest. Clients should consider 0-4 as gradients of normal priority and 5-9 as gradients of expedited priority. Priority is set to four, by default.
Initial Context Properties
The set of name-value pairs used to establish a connection to the server hosting the JMS resources for access via JNDI lookup.
As an example, by selecting "BEA Weblogic" as the provider type, a set of default initial context properties that are generally used by WebLogic clients is displayed. Update the values for the URL, username, and password to match your environment.
Queues and Listeners
To enable connectivity with external clients and services over JMS, configure connections to an external JMS server.
- Queue Name/ Topic Name (required). Descriptive name for the configuration
- JNDI Location (required). Location name used for JNDI lookups
- Listener Class (required). Message listener class name. The listener class is responsible for dispatching messages to Process Server.
If you are deploying processes created with Process Developer, use the listener class name:
If needed, you can create a custom listener class that extends the default listener class to include custom behavior. Specify the custom listener here.
- Listener Count (required). Number of connections to keep open. When the server starts, the JMS manager creates instances of this class that serve as asynchronous consumers on the destination. Each asynchronous consumer has its own connection to the JMS server. The number of consumers and connections created is controlled by the listener count.
- Default Service (optional). Specifies the name of the BPEL service to use when the target service cannot be determined from the addressing headers or message properties.
Note: One alternative to specifying a service is to include the JMS message property JmsTargetService = “myRoleServiceName” in the incoming message. Another alternative is to include a service name as a query parameter in a wsa:To header in a myRole partner link (for example, <destination JNDI name>?<servicename>). These scenarios are for receiving XML messages over JMS.
- Run-As Identity (optional). Specifies an identity for a JMS request. The identity is a role-based or group membership. If not specified, the request runs anonymously. Using this property is analogous to specifying an identity for a message-driven bean in ejb-jar.xml. Use this option if you want the JMS listener to invoke processes that have been secured with the Allowed Roles restriction in the Process Deployment Descriptor (pdd). Another use case is using the aeRunAs header for Human Task (B4P) operations. This case allows you to specify a RunAs Identity with the abTrust security role.
- Tenant Context Applicable for a MultiTenant-licensed server.
- XA Transaction (optional). If enabled for a supported platform, and if required setup has been performed, indicates that a JMS read from the queue and the process engine should participate in the same transaction. For a discussion, see Enabling XA Transaction Handling.
- Rollback on Error: Select Rollback on Error if you want to decline messages that encounter an exception, or failed messages, and move to the next message. For example, the exception could be because of an authentication failure.
If you select Rollback on Error, you must configure how the message server handles failed messages. For example, you can configure the message server to redeliver failed messages 10 times. Or, you can configure the server to move failed messages to a dead letter queue and decide what to do with them at a later point.
For example, add the following policy entry to configure Apache ActiveMQ server to move failed messages to a dead letter queue:
Here, if the original queue is userIDs, the dead letter queue that Apache ActiveMQ server creates is DLQ.userIDs.
The Rollback on Error option does not apply to messages that were delivered to target processes. A message is considered successfully processed if it invokes a target process, even if the process fails.
For new queues and listeners, the Rollback on Error option is selected by default.
Topics and Listeners
This section is where the listeners that receive messages on behalf of the Process Server are configured. At a minimum, a single listener bound to a JNDI location on the server is needed to dispatch incoming messages to the server.
If more destinations are required to service requests, new definitions can be added by selecting Add Queue or Add Topic.
Websphere Users
If you select IBM WebSphere as a provider, and Process Server is running on WebSphere, the Queue and Topic configuration tables are not shown.
Configuration of Queue and Topic listeners is not available with the WebSphere JMS provider. WebSphere JMS explicitly forbids creating asynchronous consumers outside of a message-driven bean deployment when running on a WebSphere server.
Process Server provides a sample application for a message-driven bean deployment.
Enabling XA Transaction Handling
When you are using JMS transport for inbound requests, the only way to absolutely guarantee an exactly once message delivery is to use a Distributed (XA) transaction surrounding commits of process state to the Process Server database and the read of the JMS message from the queue. Without an XA transaction, it is possible, although extremely rare, to receive a duplicate request if the server goes down at the precise moment when the inbound receive was committed to the Process Server database, but the JMS transaction has not been committed. In this case, the message remains on the queue and may be retried, resulting in a duplicate process request.
You can enable Distributed (XA) Transaction handling for a JMS Messaging Service if your processes require it. Enabling this feature requires several manual steps, outlined below in Required Setup.
Note: XA transactions can be relatively expensive, so you may see an adverse affect on performance if you choose to enable them.
Using distributed transactions, Process Server can retrieve a message from a message queue and update the database in a single transactional unit adhering to the ACID (Atomicity, Consistency, Isolation and Durability) criteria. This feature guarantees that messages processed from JMS are processed once and only once.
Supported Platforms
XA Transaction processing is supported on all Process Server application servers that include a JTA transaction manager. Te only one that does not is Apache Tomcat.
All Process Server databases (MySQL, DB2, Oracle, and SQLServer) are supported.
Note: Some databases do not enable XA support by default, and this support needs to be enabled by a database administrator. Consult your database documentation to determine if and how XA transactions are enabled.
Required Setup
Follow these guidelines to set up XA transactions:
1Ensure that your database is configured to support XA transactions.
2Create a separate JDBC datasource that supports XA transactions. Consult the documentation for your database and application server for datasource configuration details. By default, Process Server looks for a datasource whose JNDI name is jdbc/ActiveVOSXA.
Note: Process Server uses a separate datasource configuration for XA transactions since mixing XA and non-XA transactions within the same connection pool can often cause problems.
3Set up an XA-aware JMS connection factory that enlists with the JTA transaction manager hosted by the application server. Consult the documentation for your JMS provider for details. Specify this connection factory on the JMS Messaging Service page of the Application Integration Console.
4Check the XA Transaction box in the Messaging Service window that appears when you create a new messaging service.
Datasource Service
You only see this service if you have selected a Secure Agent.
Many processes interact with relational databases. The Datasource Service lets you create a "pool" of open connections between all of the application's current users. The number of users actually performing a request at any given time is usually a very small percentage of the total number of active users. Also, only when the request is being processed is there a need for a database connection. Here, you create a service that logs into the DBMS, and handles user account issues.
Enter the following properties to configure a datasource service:
After you make changes, you click Test Connection to make sure that the connection is defined and configured correctly.
Standard Properties
The standard properties are:
Name
The name of the service you are defining or editing
Driver Class
The fully qualified Java class name of the JDBC driver to be used.
JNDI Path
The JNDI name to where this Datasource is bound.
Password
The connection password passed to the JDBC driver when establishing a connection.
URL
The connection URL passed to the JDBC driver when establishing a connection.
Username
The connection username passed to the JDBC driver when establishing a connection.
Advanced Properties
The advanced properties are:
Default Transaction Isolation
The default state of connections created by this pool, which is one of the following:
- NONE
- READ_COMMITTED
- READ_UNCOMMITTED
- REPEATABLE_READ
- SERIALIZABLE
Initial Size
The initial number of connections that are created when the pool is started.
Max Active
The maximum number of active connections that can be allocated from this pool at the same time. If this value is negative, there is no limit.
Max Idle
The maximum number of connections that can remain idle in the pool without extra ones being released,. If this value is negative, there is no limit
Max Wait (ms)
The maximum number of milliseconds that the pool waits for a connection if there are none available. A value of -1 means to wait indefinitely.
Min Evictable idle Time (ms)
The minimum amount of time an object may sit idle in the pool before it is eligible for eviction by the idle object evictor (if an evictor exists.
Min Idle
The minimum number of connections that can remain idle in the pool without extra ones being created. A value of zero means that none will be created.
Number Tests per Eviction Run
The number of objects to examine during each run of the idle object evictor thread (if it exists).
Pooling Statements
Enable prepared statement pooling for this pool
Test on Borrow
When checked, objects are validated before being borrowed from the pool. If the object cannot be validated, it is dropped from the pool, and an attempt is made to borrow another.
Test on Return
When checked, objects are validated before being returned to the pool.
Test While Idle
When checked, objects are validated by the idle object evictor (if one exists). If the object cannot be validated, it is dropped from the pool.
Time Between Eviction Runs (ms)
The number of milliseconds to sleep between runs of the idle object evictor thread. If this value is not positive, no idle object evictor thread runs.
Validation Query
The SQL query that will validate connections from this pool before returning them to the caller. If specified, this query must be an SQL SELECT statement that returns at least one row.
Custom Connection Properties
Use this section to add other properties that connection requires. This information is sent to the JDBC driver when the service is creating a connections. Click the Add button to add a row into which you enter the property's name and value.
