Skip to Content

I have recently got the requirement from one of my customers to implement an IDOC to JMS and viceversa interface using distributed destinations. At first sight this seems to be a quite simple requirement to fulfill. However, the JMS adapter will not work properly with distributed destinations unless you apply the correct syntax, in this blog I’ll show you how to do it.

What is a distributed destination?

A distributed destination is a set of destinations (queues or topics) that are accessible as a single, logical, transparent destination to a client.

Why use a distributed destination instead of a standard physical queue?

The answer to that question is simpler than what you should expect, namely for fail-over and load-balancing purposes. Business Services that use distributed destinations are more highly available than business services that use standard destinations because most JMS providers (e.g. SAP WAS) allow load balancing and failover for member destinations of a distributed destination within a cluster. Once properly configured, JMS producers and consumers are able to send and receive messages through the distributed destination. The JMS provider then balances the messaging load across all available members of the distributed destination. When one member becomes unavailable due a server failure, traffic is then redirected towards other available destination members in the set.

The screenshot below shows the configuration as done for a JMS receiver communication channel in the integration directory.

jms_adapter.JPG

The most important detail to notice here is the syntax used in the JNDI Server Address. t3://<your_jms-server:jms_port>, <your_jms-server:jms_port>

As you can see in the syntax above, you have to name the server node (where the distributed destination lives) and the corresponding ports (where the physical queue’s have been defined).

With this setup any Sender /Receiver JMS adapter will now be able to send and receive messages via distributed queue’s. This scenario is depicted in the figure below.

distributed_queue.JPG

That concludes the blog for today, many thanks for reading my blog!

To report this post you need to login first.

7 Comments

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

  1. Bernd Eckenfels
    Hmm.. this is a clustered JNDI setup, it is not directly related to a JMS feature. Of course if you have multiple JMS brokers registering at the different JNDI nodes it would result in distributed JMS, but arent the JNDI treees usually synchronized between cluster nodes?
    (0) 
    1. Roberto Viana Post author

      This configuration will not work for MQ as it uses a different approach for load balancing. You just need to put there one MQ destination.

      (0) 
      1. Jens Schwendemann

        Thanks for clarification. Do you, by chance, have information about how MQ handles load balancing / what would be our best option to have failover when connectiong PI <-> MQ? I know there’s the sledge hammer approach with OS Clusters like HACMP. Do we have other options, though?

        Thanks and kind regards

        Jens

        (0) 
  2. Alejandro Ferrara

    Hi Roberto.

    I Have two questions:

    1- Is necessary the prefix  t3:// for doing the configuration?

    2- In PRD landscape we have more than one combination of <IP>:<port> for sender/receiver JMS destination. The configuration for my case must be (assuming  that prefix is necessary) t3://<jms_server1>:<port1>,<jms_server2;port2> and so on ?

    Thanks in advance.

    Alejandro.

    (0) 

Leave a Reply