Content-Type becomes null when bridging messages from Broker A to Broker B via Apache NiFi

[#1]

During testing of the Enterprise Message Bridge implemented using Apache NiFi, it was identified that the Content-Type header becomes null when messages are routed from Message Broker A to Message Broker B.

The bridge is designed to enable message flow between the two brokers using Apache NiFi as the intermediary integration layer. However, while validating message headers at the destination broker, the Content-Type attribute is not being preserved and is received as null.

This behavior was observed during message inspection at the consumer side connected to Broker B.

May I know how to preserve message Content-Type attribute/properties ? 

Using : ConsumeJMS and PublishJMS
Protocol: AMQP 1.0

[#2]

 @oka Welcome to the Cloudera Community!

To help you get the best possible solution, I have tagged our NiFi experts @MattWho @mburgess  who may be able to assist you further.

Please keep us updated on your post, and we hope you find a satisfactory solution to your query.

[#3]

@oka 

Can you share more details about your Apache NiFi version and dataflow configuration?

1. Full Apache NiFi version
2. PublishJMS processor configuration
3. Sample FlowFile metadata/attributes of a FlowFile queued to the PublishJMS processor (exclude any sensitive values).
4. Which FlowFile contains the attribute string you expect to be sent to JMS endpoint

These details can be helpful in evaluating your setup and possible issue/solution.

Thank you,

Matt

[#4]

1) 2.2.0
2) However, I didn’t notice any content-type or content-encoding attributes in the FlowFile within consumeJMS.

JMSXDeliveryCount
1
filename
576fb206-3a78-4330-b85e-2c7215f57702
jms.messagetype
TextMessage
jms.source.destination
q/mal/test/dev/test-abc
jms_deliveryMode
2
jms_destination
t/mal/test/dev/test-abc/v1/test
jms_expiration
0
jms_messageId
ID:AMQP_NO_PREFIX:a25814dd-3135-4733-8378-bd8348f4ebbb
jms_priority
4
jms_redelivered
false
jms_timestamp
1777010201098
path
./
uuid
576fb206-3a78-4330-b85e-2c7215f56602

[#5]

I noticed that the Content-Type and Content-Encoding headers are missing after using ConsumeJMS. Is this expected behavior? Since I’m implementing a message bridge, I’d like to preserve and pass along the same Content-Type and Content-Encoding values to the target broker. How can I achieve this?

[#6]

@oka 

I believe your issue is that "-" is not a valid character in the JMS specification.
https://stackoverflow.com/questions/30022453/how-to-set-content-type-header-for-jms-message

While the "-" is valid for AMQP messages.
There is a ConsumeAMQP processor but I see it only supports AMQP version 0.91

You don't have a issue connecting but just sound like these specific headers are ignored since they contain that invalid JMS character.

There is an existing Apache NiFi jira (https://issues.apache.org/jira/browse/NIFI-14670) for adding AMQP 1.0 support to the AMQP processors; however, it is open and unassigned.

Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

[#7]

I’m able to connect to the message broker and successfully consume messages. However, I’ve noticed that some information—specifically contentType and contentEncoding—is missing. From what I understand, these fields are often treated as “private” since the Qpid JMS client does not provide a public API to set them directly.

As I’m building an enterprise bridge using Apache Nifi, I want to preserve the original contentType and contentEncoding values when republishing the same message to another broker. May I know how to do it?