Announcement Announcement Module
Collapse
No announcement yet.
MongoDB and message headers Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • MongoDB and message headers

    Hi,

    I'm confused by the MongoDB channel adapter implementations. As noted in the docs, they only store/read message payloads, but not headers. Is this a limitation of the current state of implementation and should/will be fixed? Or else what is the use case?

    Are headers meant to be transient, and only available within one application?

    Also: the message store implementation does store headers. Is a message store suitable for exchanging messages between two applications (by having a channel referencing an identical message store config in each application)?

    Our use case is: use spring integration to couple independent services within our application, and use a header to communicate a tenant id. We use MongoDB channel adapters atm. as we are in early development stage, already build on MongoDB and want to delay the decision on a real message broker implementation (and the setup effort that comes with it).

    Thanks
    Rainer

  • #2
    This is probably something that should be added as an option. The JMS outbound adapter has a configuration attribute 'extract-payload' (default is true), so we could offer a similar attribute on the mongodb adapter. Feel free to open a New Feature issue: https://jira.springsource.org/browse/INT.

    In the meantime, I suppose you could use a QueueChannel backed by a mongodb message store to distribute the objects, but it's a bit of an anti-pattern.

    Comment


    • #3
      I agree that the new feature request would make sense.

      Another option in the meantime would be to add a transformer that creates the structure you actually want to share via MongoDB. For example, you could create a Map that includes some of the headers as well as the payload (then a symmetrical "deserializing" transformer on the consuming side).

      Comment

      Working...
      X