Java Messaging Service – Part 7 – Service JMS rule

December 10, 2024 Code Vault Curators

This is the final article in JMS series. It is going to be a short article on service JMS rule.

It is recommended to visit the previous article on JMS series, specially on JMS listener.

What is Service JMS rule?

– It is part of Integration services category and gets invoked from JMS listener rule.

– This rule is mainly responsible for Parsing/Mapping the incoming message, processing the message using service activity.

Business scenario: Let’s say an Banking organization XYZ uses different application to process the loans. A java application maintains the loan status. Whenever the loan status changes to Inactive, the Java application needs to send the message to all the interested parties. Pega is used as the customer servicing application and it is one of the interested parties for the loan Status. The Pega application needs to refresh the loan status in its data table.

Message format is fixed- <10 digit loan number><one space character><3 char status code>

Sample message – 7637473637 INA

The architecture team decided to use Java Messaging Service as the preferred solution for the business scenario. So the source application creates a single message and sends to a JMS Topic that can be consumed by one or more subscribers.

In the previous article, we created a JMS listener.

Here we will create a service JMS rule.

How to set up Service JMS?

Step 1: Create three Integration class layers

OW3HD2-Int-ProcessLoanStatusChange

OW3HD2-Int-ProcessLoanStatusChange_Request

OW3HD2-Int-ProcessLoanStatusChange_Response

Step 2: Create the Integration properties.

6 new properties –

– 2 Page level properties Request, response that points to request, response class

– 2 single value properties for InputMessage and Output Message under request and response context respectively.

– 2 more single value property to hold the parsed request values – LoanNumber, LoanStatusCode in the request class.

Step 3: Create the parsing rule

Since the message format is always fixed, I am going to use the Map structured rule.

Visit the article to know more about Map structured rule.

Integration Mapping – Map structured rule in Pega

Step 4: Create the service activity to call the parsing and do the processing.

Step 4.1: Create a new activity in the Integration main class

Step 4.2: Add a new method Map-Structured and refer the newly created map structured rule.

For this tutorial, I am not going to do the real processing of updating loan status change.

Step 4.3: Set the response message into .Response.pyLabel

Final step.

Step 5: Create a new Service JMS rule.

Records -> Integration services -> Service JMS -> Create new

Specify the right service package name and customer class

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

There are three main tabs.

Service
Request
Response

a. Service tab

I am not going to talk much about the service tab. It is the same reusable form in all the service types (REST, SOAP, FILE etc). Please visit my previous posts for more information! Specify the right class name and the service activity.

b. Request tab –

This is exactly the replica of connect-JMS rule. So please check the configuration explanation from the link

In short, we have three blocks of configurations.

Message headers – To map the predefined JMS headers.

Message properties – To provide additional information. Properties can be used to identify if the message is rightly intended to the recipient.

Message data –

Here from hawtio, we are going to send one block of body as message data. So I am not using the Message Key. In real time scenarios, you should always use the message Key when there are multiple message data attributes.

Also to use Message Key, you need to use Map message in Request type.

I am mapping the request data into .Request.InputMessage.

Note: Service activity is parsing the message data inside the activity. You can also use the parsing directly here in the Map to field.

c. Response tab –

Again this is standard for most for the service rules. As I promised, I want to keep the error handling for services in a separate post (a reusable post so that I can link in other service posts ;))

For now, please check the help for more details on each error condition. In the current scenario, I am going to use the default condition, so the response is always sent.

Message type as text and map the value from .Response.pyLabel, which we set from activity.