February 6, 2019 at 1:13 pm #10173
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
February 6, 2019 at 1:19 pm #10181Ed ShawKeymaster
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.
February 6, 2019 at 1:54 pm #10189
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
February 6, 2019 at 3:28 pm #10198
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
February 6, 2019 at 6:14 pm #10207
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
February 7, 2019 at 10:21 am #10216
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/catch0
February 7, 2019 at 11:04 am #10225
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
February 7, 2019 at 11:12 am #10234
No problems, say hi to Aaron.0
- You must be logged in to reply to this topic.