Pass Custom Header Fields to JMS

  • 11 March 2022
  • 3 replies

I want to pass custom header fields along with the JMS message to JMS producer.
I just found the way to include headers which start with: jms.header.*

That would be so far file but i don’t like that it takes over the jms.header. prefix in the header field.
I want to be able to steer what name the parameter has as often fields are defined on enterprise with
certain meanings and these name will not include jms.header.*

So what i expected was:

will turn to:
MyCustomHeaderField Property

but it turned into:

3 replies

Userlevel 4

@robert.bernhard Thank you for detailed explanation. I will share this feedback with our product management team.

@Rishi Then i would say it is not a good design and i will explain why:

  • Custom Properties are used to carry certain information along with the message.
    (Similar to http header fields)
    That means you must be able to set what is agreed in your enterprise or with your systems
    you integrate with.
  • Prefixing any property with jms.header does not make sense as nobody will have
    a standard property defined with jms.header in front.
    Even if you have multiple pipelines 1 publisher with streamsets as JMS producer and another as JMS consumer would get cascading jms.header.jms.header….

Option 1:
Just cut off the prefix of jms.header and just use a signal that this property should be published.
Sure that can not be done anymore as it would break backwards compatibility with the ones who 
already use current prefix.
Maybe: jms.header.skip could be used which then removes this part.

Option 2:
Best would be more flexibility to tell which headers to publish and consumer by just providing the
names and not making use of this prefix. That event supported with wild cards or regex to support
best flexibility.

I hope my explanation makes sense.



Quick Win:
Set on publisher:
Set on message:

Option 2:

Jms Headers to Publish/Consume:


Userlevel 4

@robert.bernhard I think this is working as expected.  the idea was to have some sort of identifier which allow end user to differentiate which headers are coming from where and hence the prefix.