Java Messaging Service – Part 4 – Connect JMS in Pega

December 10, 2024 Code Vault Curators

In this blog article, we will see all the configuration points in a Connect-JMS rule that can put a message into ActiveMQ JMS provider.

You will see there are two Connector rules to support Messaging Service – Connect-JMS and Connect-MQ.

Connect-MQ – Is a specific implementation of messaging service that supports IBM Websphere MQ standard. We already know IBM WebSphere is one of the JMS providers.

If I speak more technically, then the java classes that gets invoked from Connect-MQ corresponds to ibm.mq classes. You cannot use this for other JMS providers like ActiveMQ, RabbitMQ

Connect-JMS – It is a generic implementation of messaging service that supports the Open standard JMS API. Almost all of the JMS providers including IBM adhere to JMS API standard and hence you can always use Connect-JMS over Connect-MQ.

Note: Current Connect-JMS supports JMS 1.0 and 1.1 features.

Important note: Pega also claims that development effort on Connect-MQ rules are stopped and advise us to use JMS rules instead.

This is the 4th article in JMS series. It is recommended to visit the previous article on JMS series in order.

https://myknowtech.com/tag/jms

What is a Connect-JMS rule?

– It is part of Integration connector category

– Using this rule, we can connect to any external system that uses Java Message Service API. Pega can act as a Message producing system and use the Connect-JMS to send the message to the destination path in the JMS providing system.

How to configure Connect-JMS rule?

We don’t have a wizard for the Connect-JMS Integration. So we will create the rules manually.

Business Requirement – Whenever Loan status changes (for example to Inactive – INA) then a message should be sent to the Queue – FirstQ in the ActiveMQ broker. Message body format should be <LoanNumber>{single space}<StatusCode>. Every message should have identifier attribute source system name, so that the subscribers/consumer can easily consume the right message.

Sample message – 4123672652 INA

Step 1: Create Integration class layers.

I am going to have three Integration abstract classes on the Organization level

OW3HD2-Int-LoanStatusChangeEvent

OW3HD2-Int-LoanStatusChangeEvent_Request

OW3HD2-Int-LoanStatusChangeEvent_Response

Step 2: Create the Integration properties.

4 new properties – 2 Page level properties Request, response that points to request, response class and 2 single value properties for Message and SourceSystem under request context.

For now, I didn’t configure any consumers, so for response, I am going to keep empty.

Step 3: Create a new Connect-JMS rule

Records -> Integration Connectors -> Connect-JMS -> Create New

What are the configuration points in a Connect-JMS rule?

There are 3 main tabs in a Connect-JMS rule.

Service
Request
Response

Service tab

There are 5 blocks in the service tab. We will see one by one and its usage.

Service properties

Resource name resolution – You have 2 options to refer the JNDI resources for Pega-JMS provider connection.

Direct JNDI Lookup – You can refer a JNDI server instance name.

The JNDI server instance will look like this.

You can connect to JMS provider JNDI server instance to directly look up the available connection factory and destinations.

We saw in the previous post that ActiveMQ do not facilitate JNDI server, and so this option is not applicable for us.

Use Resource reference option

Connection factory – In the picklist you should see all the specified connection factory in the deployment descriptor file we did in the previous post. Select the right connection factory for active MQ connection.

This guarantees that our configuration in the deployment descriptor file is good J

JMS Producer model –

It is a Pega data instance, that holds the message settings for the JMS connector rule.

Pega has defined it as single instance so that the same producer model can be referenced in multiple Connect-JMS rule. Reusability.

How to create a new producer model?

Step 1: Create a new Producer model instance

Records -> Integration Resources -> JMS producer model -> Create New

Step 2: Specify the configuration points in the producer model instance.

Persistent – this is based on the JMS provider settings. You can either save the message in the database or just in memory till the message is retrieved or expired. If you restart the server, then the queue is cleared

I am going to keep it unchecked.

Priority – Just recall the message format we saw in the previous article. Copy pasting the content from previous post.

JMS Message Objects

JMS message is used by the JMS clients. JMS message is divided into three parts

1. Message Header

Predefined fields which are used by the clients and producers to identify and send messages. Predefined headers are – JMSDestination, JMSMessageID, JMSReplyTo etc.

Eg: JMSDestination refers to the queue/topic name where message gets delivered.

Visit the link for more details on the predefined Message headers – https://docs.oracle.com/cd/E19798-01/821-1841/bnces/index.html

2. Message properties

Here we can set some additional custom properties with the JMS message. Mostly we use these properties to uniquely identify or select messages in the queue/topic.

3. Message Body

Currently the JMS API defines five message formats.

Priority is one of the message header and can contain the value range between 0(lowest) to 9(highest).

Expiration – You can specify the number in milliseconds. If the message is not consumed before the expiry time then JMS destroys the message. This is also JMS message header.

If you want the message to never expire, leave it empty.

Domain – We know from the introduction post, that JMS supports two messaging domain.

Point-To-Point – One Producer and one consumer. It uses queues as destination.

Publish/Subscribe – One producer to multiple consumers. It uses topics as destination.

Here is my final configuration in the producer model instance.

Specify the producer model instance in the Connect-JMS rule.

Authentication –

Here you can specify authentication profile instance. If the JMS provider instance expects authentication from the message producing system, then use the authentication profile.

Request –

You can specify the request destination configuration.

Destination name – use the picklist to view all the destination path specified in the deployment descriptor file. Use the right destination name for the FirstQ.

Request message –

As we saw before, as per the JMS specification the supported message types are listed. In our scenario, we are going to use Text message type.

Response –

You can specify the response destination configuration. The destination name goes in as JMSReplyTo header field.

For response destination, you can use two options.

a) Dynamic destination – The JMS provider creates a temporary queue to hold the response message.

b) Destination name – If you don’t use dynamic destination and you expect response, then you can specify a destination queue name created in the JMS provider system.

Response timeout – You can specify the number in seconds till when the connection waits for a response. If not, then it gives a timeout error.

Error Handling –

This is the default configuration you will find in all the connector rules.

Request tab

We know that there are three block in the JMS request message – headers, properties and data.

Headers –

Pega by default supports two message header configurations in the request tab. We already saw other header values like expiry, priority from Producer model instance.

JMSCorrelationID – Use to tag one message with another. Specially for tagging the response message with the request message

JMSType – defines the message type.

For now, I am going to use both as empty.

Message properties

These are custom properties set by the message producing system. As per our requirement, we need to tag each message with the producing system. I am setting the property – SourceSystem.

You can add as much as you want.