Messaging service overview
You can integrate a Java Messaging Service (JMS) with Pega Platform to communicate with other applications, or have other applications communicate with Pega Platform, without requiring a direct synchronous integration between systems.
Pega Platform supports synchronous or asynchronous messages between JMS publisher and receiver clients. Both clients use a connection factory as a message broker for messages before sending, as part of the following process:
- The connection factory establishes a connection between the JMS provider (such as Apache ActiveMQ) and Pega Platform as a JMS publisher or receiver client.
- A publisher client creates and sends the message.
- A JMS destination, such as a queue or topic, relays the messages.
- A receiver client consumes the message.
Pega Platform supports messaging service configurations such as the following use cases:
Communicate with applications that do not use other integrations with Pega Platform.
For example, after your application resolves a case, Pega Platform can send a confirmation message to another application that is required in the process. By using a point-to-point JMS model with Pega Platform configured as the publisher client, you can send a JMS message to that application after your case is resolved.
Send and receive information with other applications as a background process.
For example, you can send notifications to separate systems about routine maintenance. As a publisher client, Pega Platform can send a message to a destination that states that maintenance has started before your instance of Pega Platform disconnects from the internet.
Implement a scalable mode of communication between a dynamic number of applications and their components.
For example, client profile updates usually require the syncing of additional external systems of record (SOR). In a publisher/subscriber JMS model, you can automate changes to the remote SORs that reflect changes that you make to the client profile.
Pega Platform provides the requisite forms for every element of a JMS model for you to seamlessly integrate JMS with your applications. You can configure Pega Platform to act as a publisher of messages or as a receiver of messages, based on the combination of forms that you use.
For more information about how to configure Pega Platform as a JMS publisher client, see Configuring Pega Platform as a Java Messaging Service publisher.
For more information about how to configure Pega Platform as a JMS receiver client, see Configuring Pega Platform as a Java Messaging Service receiver.
Types of messaging service models
Pega Platform supports two messaging service models to integrate with other applications and their components through messaging: the point-to-point model and the publisher/subscriber model. When you integrate Pega Platform as a receiver client, the type of model that you created outside of Pega Platform determines how Pega Platform ingests the messages.
For more information about choosing a point-to-point or a publisher/subscriber model, see Configuring Pega Platform as a Java Messaging Service publisher.
- Point-to-point model support
The point-to-point (P2P) model is a one-to-one model in which one publisher client sends a message to one receiver client. The publisher client sends messages to the message broker queue. The receiver client receives messages from the same queue, then sends a read receipt back to the message broker queue. The queue delivers messages to the receiver in the order that is sent by the publisher client.
Pega Platform can act as either a message publisher or receiver, depending on the associated forms that you use to configure your JMS model. For more information, see Configuring Pega Platform as a Java Messaging Service publisher and Configuring receiver.
- Publisher/subscriber model support
The publisher/subscriber model is a one-to-many model in which a single publisher client sends messages to a topic that then delivers the message to multiple subscribed receiver clients. A publisher client creates a topic, which is a type of a message producer. Multiple message receiver clients subscribe to the topic. When a publisher client sends a message, the receiver client that is subscribed to the topic ingests the message. The topic does not hold messages in a queue; instead, receiver clients can only ingest messages from a topic after they subscribe, and the topic otherwise discards the message.
You can select which model you want to use in the JMS Producer Model rule. For more information, see JMS Producer Model form - Completing the Model tab.
Synchronous and asynchronous messaging
Synchronous messaging involves a JMS publisher client that sends a message and then waits to receive a receipt when the receiver client ingests the message, before sending another message. Asynchronous messaging keeps the message in the queue or topic regardless of whether the message publisher receives a read receipt from the message receiver. For more information about configuring synchronous and asynchronous messaging in your JMS model, see JMS Service form.
Message service resources
When you configure Pega Platform as a message publisher client in your JMS model, you initialize and configure JMS resources in a system that references Pega Platform forms. JMS integration requires this system parameter setting to specify details for your JMS resources that are required to communicate with other applications within the JMS model outside of Pega Platform.
Pega Platform integrates these JMS resources through the associated JMS forms. Depending on the type of client as which you want Pega Platform to function, refer to the following table to know what to select for the appropriate JMS-related forms.
|Publisher client||Receiver client|
JMS resources include the connection factories and destinations that are required to fill Pega Platform forms.
The types of JMS resources that you can use to integrate your JMS model with Pega Platform depends on your type of system deployment.
|External system type||Form||Pega Cloud Services support||On-premises and client-managed cloud support|
|External JNDI Server||JNDI Server form||Not available||✔|
|Internal JNDI Server||
(Pega Cloud Services only) Request an internal JNDI server for usage in your messaging service model.
JMS Connector Service FormResource references are JMS resources (such as connection factory) referenced directly from the Pega Platform web and context XML files. Refer to your JMS provider documentation for how to add the resources to an XML file.
Pega Platform must reference several types of JMS resources when publishing or receiving messages. JMS resources are hosted on a JNDI server or on another resource reference. Pega Platform then uses these resources through an associated ruleform. These JMS resources include the following elements:
- Destinations: Pega Platform uses queues or topics as destinations when sending messages. Queues or topics act as the delivery method for both Java Service Messages for point-to-point and publisher/subscriber models, respectively.
- Connection factories: Pega Platform uses connection factories to enable connections with other JMS clients. JNDI servers and other resource references use connection factories to enable connections with other JMS clients.
For more information about where to enter the destination and resource references for your JMS model in Pega Platform, see JMS Service.Pega Platform objects used in JMS Integration
JMS integration with Pega Platform requires the use of data objects to map messages for either publishing or receiving. These objects include the following Pega Platform resources:
- Pega Platform as a publisher client:
- Clipboard: Pega Platform sends messages that are mapped within a page or property in the Clipboard.
- XML Stream: Pega Platform sends messages that are mapped in the XML stream.
- Pega Platform as a receiver client:
- Clipboard: Pega Platform as a JMS receiver client maps the message to the Clipboard page or property as they are ingested from an external publisher client.
- XML Stream: Pega Platform as a JMS receiver maps the message to the XML stream as they are ingested from an outside publisher client.