Introduction
The main purpose of this document is to explain the workaround’s available for receiver JMS – MQ reconnecting issue
We recently faced this issue with JMS receiver communication channels which are frequently throwing error in case of network, connectivity issues or when MQ queue manager is restarted.we have implemented custom solution to fix this re-connecting issues in SAP PI.
In general MQ Queue Manager which would break all the connections that are idle for more than 10 minutes interval. JMS receiver channels unable to reconnect to WebSphere - MQ queue manager and every time we need to manually restart the communication channels in case of this issue.
Error
JMS channel fails to connect to MQ whenever any network problem occurs. This generates the following error
“MQJMS1016: an internal error has occurred. Please contact your system administrator.
Detail: java.lang.NullPointerException: in sending to destination queue: //TESTXXX”.
Root Cause
The main reason for this issue is that Queue Manager which would break all the connections that are idle for more than 10 minutes interval and whenever a network problem occurs the PI JMS channel goes down.
This problem is caused due to a limitation in all versions of Websphere MQ including 6.x that has been acknowledged by IBM. Websphere MQ diverges from the JMS specification and other JMS products in its behavior of notifying the JMS connection exception listener. (javax.jms.ExceptionListener).
When only a javax.jms.QueueSender object is created from a javax.jms.Session object associated with a javax.jms.Connection object, errors/drops in the connection do not invoke the associated exceptionlistener set on the connection object. Instead an exception is encountered only when the next JMS message (javax.jms.Message) is sent through the JMS sender.
However, when a MessageListener (asynchronous) is created on a Session object associated with a JMS Connection, WSMQ informs the connection's ExceptionListener immediately.At present there are no permanent solutions to this problem,only workarounds are available.
Work around 1 – Set Additional JMS parameter in the receiver JMS communication channel
The DEPRECATED workaround involved creating a new session and a dummy javax.jms.QueueReceiver and dummy javax.jms.MessageListener on the connection object. This forces MQ to invoke the connection's exception listener. Since this solution entails a higher resource cost, it can be activated only by an explicit additional JMS parameter specific in the channel configuration.
This workaround was previously available by setting the additional JMS parameter WSMQ.ForceConnectionExceptionHandling = true in the JMS receiver communication channel.
However, analysis and feedback from customers revealed that this solution suffers from SEVERE performance issues due to the underlying behavior of the WebSphere MQ provider, and hence is NOT RECOMMENDED for moderate-to-heavy use - when large number of messages sent on a JMS receiver communication channel. Hence, this solution is now DEPRECATED and WITHDRAWN.
For example, instead an error is thrown when the first message is sent from XI to the queue through the invalid JMS connection object.
Please refer SAP Note: 0000948016
https://websmp230.sap-ag.de/sap/support/notes/convert2pdf/0000948016?sap-language=EN
Work Aorund 2 – Setup Batch Jobs
The following steps to be carried out to implement the batch jobs
- ABAP program for Batch jobs
- Program Variants
- Batch Job activation using JMS communication Channel
- Channels to be in “External” control
- HTTP Destinations for START
- HTTP Destinations for STOP
An alternative solution will be available only from XI 30 SP20, XI 70 SP12. The new solution sets up a poll job that regularly polls the JMS connection in order to determine whether the connection is valid or invalid. The poll job sends non-persistent messages with a small expiry period to a temporary queue available on that connection. The connection is determined as broken when message-send to the temporary queue fails. The poll job runs every 90 seconds is activated by the means of an additional parameter in the JMS channel configuration. The resource cost of this poll job is a new TCP socket connection between client and server (behavior of MQ provider).
ABAP program code
ABAP report ‘ZRESTART_JMS_RCVR_CHANNEL’ which takes HTTP Destination as input and triggers Connection Test for the same. For every receiver jms channel, two variants are created that would pass the StartChannelHTTP Destination and StopChannelDestination respectively. Finally, a batch job is created with two steps. First step is to call the Report with Stop variant and second step to call the Report with Start Variant. It’s scheduled to be executed a periodic intervals.
Refer the below link
HTTP Destinations
We will be creating HTTP Destinations “START_MQ_RESPONSE” and “STOP_MQ_RESPONSE” in SAP PI. We have developed a custom ABAP report “ZRESTART_JMS_RCVR_CHANNEL” which takes HTTP Destination as input and triggers Connection Test for the same.
For every Receiver JMS channel, two HTTP destinations will be created.
1) To start the particular JMS receiver channel.
HTTP Destination : START_MQ_RESPONSE
Connection Type : H
Target Host : Enter host name of SSAP PI system p80sap130.corpusers.net
Service No : Service number of SAP PI
PathPrefix : /AdapterFramework/ChannelAdminServlet?party=*&service=*&channel=START_MQ_RESPONSE &action=start
2) To stop JMS receiver channel
HTTP Destination : STOP_MQ_RESPONSE
Connection Type : H
Target Host : Enter host name of SSAP PI system p80sap130.corpusers.net
Service No : Service number of SAP PI
PathPrefix :/AdapterFramework/ChannelAdminServlet?party=*&service=*&channel=STOP_MQ_RESPONSE &action=stop
Variants:
For every receiver JMS channel, two variants are created that would pass the StartChannelHTTP Destination and StopChannelDestination respectively. Finally, a batch job is created with two steps.
1) First step is to call the Report with Stop variant.
Variant : START_PO_MQ
Program Name : ZRESTART_JMS_RCVR_CHANNEL
RFC Destination value: START_MQ_RESPONSE
2) Second step to call the Report with Start Variant.
Variant : STOP_PO_MQ
Program Name : ZRESTART_JMS_RCVR_CHANNEL
RFC Destination value: STOP_MQ_RESPONSE
Batch Job:
A batch job in SAP is a scheduled background program that usually runs on a regular basis without any user intervention. Batch jobs are provided with more allocated memory than the ones that are done in the foreground. They are used to process high volumes of data that would normally consume long-term memory if run in the foreground, as well as for running programs that require less user interaction.
Batch job “ZRESTART_JMS_REC” is created with two steps. First step is to call the Report with Stop variant and second step to call the Report with Start Variant. It’s scheduled to be executed a periodic intervals.
- Go to t code SM36 --> provide job name and then press enter.
As shown in the above screenshot, you can also define batch jobs using define job using wizard.
- Provide the program name and variant, and press save
- Then provide the frequency of the batch job and save again, it will then schedule the batch job.
Refer the below links to schedule batch job.
http://****************/Tips/ABAP/BackgroundJob/FactoryCalendar.htm
Batch job name: ZRESTART_JMS_REC
Frequency – 20 minutes
Job Activation
The connection-test poll job can be activated by setting the JMS additional parameter CONNECTION_TEST_POLL= true in the JMS receiver communication channel.
Restart Mechanism
There is a restarting mechanism that restarts PI JMS communication channels every twenty minutes. This requires the channel to be in state 'External'. In case the JMS channel is in another state, 'Manually' or 'Automatically' it will not be restarted by the restarting mechanism.
We need to do similar setup for all the JMS receiver communication channels, to schedule re-start mechanism for the JMS receiver to avoid connectivity issues.
Testing
ABAP report ‘ZRESTART_JMS_RCVR_CHANNEL’ which takes HTTP Destination as input and triggers Connection Test for the same.
1) Go to SE38 and enter the program name --> F8.
2) Specify RFC destination and press F8.
3) Select the check box “Accept All further cookies” and Click Yes.
4) Result
We have successfully implemented the solution for JMS-MQ receiver reconnecting issue and we are able to reconnect to MQ automatically without any manual intervention.
Note : We have implemented this solution in SAP PI 7.0 release 7.2, SP 016.
- SAP Managed Tags:
