How does one preserve the JMS message / properties when using an interface?

[Louis Pace]

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

[Ed Shaw]

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

[Louis Pace]

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

[Community Manager]

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

[Louis Pace]

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

[Community Manager]

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

[Louis Pace]

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

[Community Manager]

No problems, say hi to Aaron.

0

[Author]

Posts