The processing of service requests is handled by service rules as appropriate for each service type.
There are some configuration aspects common across all Pega Platform integration services. This includes ensuring proper distribution of listeners across hosts and Pega Platform servers for the required level of redundancy. An unexpected failure may result in the loss of in-flight transactions and possibly the re-processing of messages.
Email service and listener
- For unexpected shutdowns, it is possible for email to have been processed (read) by the Pega Platform but not marked accordingly in the email server. This might result in duplicate processing of email messages either when a Pega Platform server is restored, or immediately if the message is processed by a listener on another Pega Platform server. In this scenario, logs should be reviewed for such duplication as required.
- For planned shutdowns, email listeners are marked for stopping and terminate when all inflight messages are processed. The time it takes for an email listener to stop depends on several factors, including the number of messages that the listener is configured to process at a time.
File service and listener
- Unexpected shutdowns are handled with built-in recovery features.
- For high availability, select the attempt recovery and lock temporary file names options during configuration. Additionally, file source locations should be common across Pega Platform servers, for example, on a redundant network drive.
- JMS service and listener - Enable durable subscriber for JMS services and use after message processing for acknowledgments.
- MQ service and listener - Use transacted messaging for IBM Websphere MQ services.
JMS MDB service - Use for e-tier deployments.
- Be sure to use container-managed transactions and durable subscribers.
- Consult the appropriate web application server vendor documentation for proper configuration of the JEE container for high availability.
HTTP, REST, SAP, SAPJco, SOAP, and Java services - Support the ability to perform asynchronous processing on child threads.
- For unexpected shutdowns, there is a slight possibility of unpredictable message processing.
- For planned shutdowns, route traffic away from the Pega Platform server and monitor requestor activity on servlets, including any batch requestors that might be in use.