The intent of this blog is to showcase as to how the SAP PI based  AXIS message protocol can be leveraged to conenct to the legacy applications via an enterprise messaging system like TIBCO EMS and a synchronous communication can be achieved from a JMS queue which is inherently asyncronous in nature.

The scenario describes a general Cashbalancing scenario which a SAP banking related process triggers to get end of day cash balancing from the core banking based legacy application via a synchronous call.


It’s basically a very normal synchronous scenario with a query/response pattern.

1.    SAP Backend is doing a request through a synchronous interface.This request goes through the axis receiver channel and is delivered as a SOAP message to the JMS queue. The TIBCO EMS is making a synchronous call to the backend system and receives the response. The response message is put on the same queue (although a temporary dummy queue). We expect now this response message coming into the axis receiver channel on a separate JMS response queue into PI. Also before the message is delivered to the TIBCO based JMS queue ,it expects PI to add a custom message header to the message besides the standard header and while the response is coming back PI should again remove this header while passing it to the calling system.

Pl    Please  check the appropriate axis libraries are deployed to the PI server as shown below, without this AXIS related calls won’t be possible.

   axis JARS.png

Th    The requiredsda zip can be deployed  through the SAP NWDS deployment as follows.



     The configuration steps as required in the  receiver communication channels based on AXIS protocol are displayed as below.axis_rECEIVER_CHANNEL_CONFIGURATION.png

A    Adding Custom SOAP headers in addition to standard header.

      You can either write your own Axis handler that can insert an arbitrary SOAP header or use to insert arbitrary SOAP headers. The handler allows you to insert any number of non-nested or nested SOAP headers. See a sample receiver configuration for inserting the SOAP headers.

      The first sample configuration inserts two SOAP headers: one with name abc with fixed value ABC, and the other with name url with value of parameter transport.url of the Axis’s message context. When parameters name.n and namespace.n are set, this handler inserts the specified header with the element value given in parameter value.n. The second sample inserts the ebXML header whose element values are retrieved from the XI DynamicConfiguration header (ASMA). When parameters name.n and namespace.n are absent, the value given in parameter value.n is taken as the XML template for the header.



Directing the JMS response to the response queue which PI JMS sender is polling

There is a special property for the response message which describes how the response message is created. The available values are:

  1. empty: empty response is returned.
  2. jms : proper JMS response is returned.(this case)
  3. echo: the request message itself is returned.
  4. status : status of the message

You can add additional parameter in your channel configuration. For example:

  1. trp  response  empty(you can put also  jms,echo or status).

following value should be set in the module configuration in the  channel to tell TIBCO as to which queue it should use to put the response message back.

JMSReplyTo attribute should be automatically filled with the response queue that AXIS has generated, and queue name should be resp<queue name where response is to be sent  to>

Transport.jms.jmsReplyTo = respDummy.ES.CDX_PGMS_CashPoolingAccount.001.Request.GetCashBalance.001

where the assigment on the right side shows the name of the response queue where the message can be put. The same name of the queue can be used for the sender JMS adapter configuration to get the response message back.

Removing the Custom message header from the incoming response message.

Module parameter should be used for module key hdr  in the PI sender JMS adapter channel to strip the incoming message of the custom message header that TIBCO JMS meesage has added to it. Once done the same nessage comes with only stadard header and can be processed by PI and sent back to the calling system.

Message that can be seen in the TIBCO monitoring.

As can be seen in the TIBCO message queue that response message has been put inot the response queue which is being polled by PI sender JMS channel from where it can be picked up and further proceed by SAP PI sender channel.

2258 is the sender queue we are calling and delivering the message to.

2254 is the response queue created by AXIS where we are listening and response is returned.




To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Laurie Howard

    Hi Rohit,

    Good article. In our current project with have a very similar setup to the one you mention above. We have implemented the outbound synchronous  calls without much issue but have become stuck with inbound synchronous calls. Do you have an example of this configuration used with an inbound synchronous where Tibco are using temporary queues?

    In the project Tibco are using a temporary queue for each synchronous request to SAP, which it includes in the JMS header on the inbound request. In order for us to reply we need to add the queue name to the JMS header of the outbound. But with the usage of JMS and AXIS adapters we lose the inbound JMS header and therefore temporary queue name. Thus, we cannot add it to the outbound JMS.

    Any pointers would be greatly appreciated.



  2. Ankit Srivastava

    Hi Rohit,

    Thanks for sharing this information.

    Using this information, I am trying to push message to MQ through SAOP Axis receiver.

    I have Queue Manager name, Channel name, Queue name, host, port of server.

    Please let me know respective parameters of trp that above values should be mapped to in the module configuration.

    Best Regards,



Leave a Reply