Home Forums Integration Channels How does one preserve the JMS message / properties when using an interface?

Viewing 7 reply threads
  • Author
    Posts
    • #10173
      Louis PaceLouis Pace
      Participant

      Suppose a channel is listening to a message queue. The channel has a single bound service. The service does not have an interface. Then the message that the service receives is a “MessageQueue”, with this’body containing the payload and other properties are available as attributes of the MessageQueue message.

      However, if the channel has an interface, then the service receives the contents of this’body, and all of the other properties seem to be lost. Is there any way to retain the full message received from the queue?

      0
    • #10181
      Ed ShawEd Shaw
      Keymaster

      Louis,

      Interfaces are a convenience method for the “simple” case.  When using an interface, the payload you will receive into the service is “pre-parsed” and all of the header information is discarded.

      If you need access to the JMS properties (or HTTP, TCP, UDP… header properties for other channel types) you should not use an Interface, receive the message into your service, extract the header information you need, then use script to parse the body.

      Thanks,

      Ed

       

      0
    • #10189
      Louis PaceLouis Pace
      Participant

      We thought that might be the case. Thanks, Ed!

      The difficulty is that we were trying to bind multiple services to a channel (as incoming messages may vary). It seems that doing so requires that each service has an interface. So, we will need a single “wrapper” service that is bound to the channel, which then parses the message and forwards it to a “child” service as appropriate.

      0
    • #10198
      Dhruv BassiDhruv Bassi
      Moderator

      Hi Louis,

      We had a similar implementation on another project. Quick summary below:

      • One channel listening to a queue and bound to a service
      • The service than parses the message, which has a separate header to determine message type, pay load(body) and other parameters
      • One channel per service/endpoint for different message types
        • If end points are same with different APIs/functions as a string, that can be appended and keep one channel

      The design was dependent on the integration guidelines by the enterprise architects.

      Depending on how flexible the system being integrated with or if a middle layer is present, different implementations are possible.

      Hope that helps

      Regards,

      Dhruv

      0
    • #10207
      Louis PaceLouis Pace
      Participant

      Hi, Dhruv! Great to hear from you!

      I’m not entirely sure I follow your suggestion. It sounds like you are using one channel to receive the message from the queue, with one service (with no interface) bound to that channel to parse the JMS properties, and then sending the payload to a different service? Perhaps sending the JMS information as arguments?

      0
    • #10216
      Dhruv BassiDhruv Bassi
      Moderator

      Hi Louis,

      Yes, its been a while 🙂

      You are correct in your understanding, 1 Channel to listen to a “queue” which has the message type and payload/body along with some parameters.

      Use the details available in that message to call subsequent services which can be bound to different channels/interface (if needed).  Interface also helps with error handling, however that can be achieved within the service try/catch

      0
    • #10225
      Louis PaceLouis Pace
      Participant

      That’s what Aaron and I decided to go with — one service bound to the channel to receive the message from the queue, parse it, and then dispatch it based on its contents. Thank you all for your help!

      0
    • #10234
      Dhruv BassiDhruv Bassi
      Moderator

      No problems, say hi to Aaron.

      0
Viewing 7 reply threads
  • You must be logged in to reply to this topic.