Protocol Metadata and Payload Encoding Interactions

Solace PubSub+ supports a wide range of Open Protocols such as AMQP, JMS and MQTT. The PubSub+ event broker translates all messages from a protocol-specific message to SMF messages when it receives them. The event broker then translates the messages back from SMF messages to a protocol-specific message when it sends them to an application. Each protocol has different rules for how the protocol-specific information is translated to SMF when the event broker receives a message using an Open Protocol, and from SMF when an event broker sends a message using an open protocol. The following sections show the interoperability between open protocols and SMF. These interactions are captured as:

• Payload Conversions
  • AMQP
  • MQTT
  • JMS
  • HTTP/REST/RDP
  • Kafka
• Metadata Conversions
  • AMQP
  • MQTT 5.0
  • MQTT 3.1
  • JMS
  • HTTP/REST Messaging
  • RDPs
  • Kafka

Payload Conversions

SMF supports a wide range of payload attachment types that help describe the type of data stored in the message:

Solace Message Type	Description
Binary Attachment - Unstructured Bytes	Unstructured Bytes may be used to transport any kind of data
Binary Attachment - Text	Text is any kind of human-readable text data
Binary Attachment - Stream	See Using Structured Data for more information
Binary Attachment - Map	See Using Structured Data for more information
Binary Attachment - Object	JMS supports serializing objects to message payloads
XML Attachment	Some APIs support accessing the “XML” attachment of a message

The Solace messaging APIs support optional end-to-end message payload compression. Message payload compression is not compatible with non-SMF protocols, such as AMQP, HTTP, Kafka and MQTT.

AMQP

From AMQP to SMF, a message may be interpreted as Binary Attachment - Text if any of the following conditions are met:

• amqp-value of type string or symbol is present OR
• The message annotation x-opt-jms-msg-type is set to 5 (TextMessage) OR
• The message content-type is set to one of:
  • text/*
  • application/xml
  • application/xml-dtd
  • application/*+xml
  • application/json
  • application/*+json
  • application/javascript
  • application/ecmascript
  where “*” is a wild card OR
• amqp-value of type null is present and one of the above conditions indicate that the message should be treated as text

Otherwise, the message is interpreted as Binary Attachment - Unstructured Bytes.

The event broker will interpret a received AMQP message as Binary Attachment - Object if the message annotation x-opt-jms-msg-type is 1, and the AMQP body is in a data section.

The following message types are not supported and results in rejected messages:

• x-opt-jms-msg-type of Message (0), MapMessage(2), or StreamMessage(4) is set
• amqp-sequence is set
• amqp-value of anything other than string, symbol, null or binary is provided

The following table shows how message payloads are converted from SMF to AMQP. Payloads may be located in either the message’s Value component or the message’s Data component, in the first and only section. content-type may be set if not already set based on the message type.

Solace Message Type	Payload Location	Message annotation x-opt-jms-msg-type	Message Property content-type
Binary Attachment - Unstructured Bytes	data	3 (BytesMessage)	application/octet-stream if not already set
Binary Attachment - Text	value (type string, or null if empty string)	-	-
Binary Attachment - Stream	Not supported	-	-
Binary Attachment - Map	Not supported	-	-
Binary Attachment - Object	data	1 (ObjectMessage)	application/x-java-serialized-object if not already set
XML Attachment	value(type string)	-	-

MQTT

From MQTT 3.1 to SMF, the publisher application converts message payloads to Binary Attachment - Unstructured Bytes.

From MQTT 5.0 to SMF, Binary Attachment - Text is used if any of the following conditions are met:

• MQTT Payload Format Indicator (MQTT Spec 3.3.2.3.2) is set to 1
• MQTT 5.0 Content Type is one of:
  • text/*
  • application/xml
  • application/xml-dtd
  • application/json
  • application/javascript
  • application/ecmascript
  • application/*+xml
  • application/*+json

Otherwise, Binary Attachment - Unstructured Bytes is used.

The following table shows how message payloads are converted from SMF to MQTT, for both MQTT 3.1 and MQTT 5.0. If the payload cannot be converted, the event broker delivers the message with an empty payload.

Solace Message Type	Payload Present?	MQTT 5.0 Payload Format Indicator
Binary Attachment - Unstructured Bytes	Yes	0
Binary Attachment - Text	Yes	1
Binary Attachment - Stream	No	0
Binary Attachment - Map	No	0
Binary Attachment - Object	No	0
XML Attachment	Yes	1

If both an XML Attachment and Binary Attachment are present, the event broker drops both payloads.

JMS

This section provides an overview of the process for converting JMS message payloads to SMF. While JMS is not a protocol, it has unique mappings within the JMS layer that require handling during conversion. For information, see Creating JMS‑Compatible Messages With Other APIs.

The following table shows how message payloads are converted from JMS to SMF:

JMS Message Type	Solace Message Type
BytesMessage	Binary Attachment - Unstructured Bytes
TextMessage	XML Attachment or Binary Attachment - Text, depending on the setXml setting in the connection factory (default true). SolConnectionFactory (Solace JMS API v10.23.0)
StreamMessage	Binary Attachment - Stream
MapMessage	Binary Attachment - Map
ObjectMessage	Binary Attachment - Object

The following table shows how SMF is converted to JMS:

Solace Message Type	JMS Message Type
Binary Attachment - Unstructured Bytes	BytesMessage
Binary Attachment - Text	TextMessage
Binary Attachment - Stream	StreamMessage
Binary Attachment - Map	MapMessage
Binary Attachment - Object	ObjectMessage
XML Attachment	TextMessage

If both an XML Attachment and Binary Attachment are present, the XML payload is interpreted as a TextMessage.

HTTP/REST/RDP

When using REST messaging, the Content-Type header dictates whether the event broker interprets the message as Binary Attachment - Text or Binary Attachment - Unstructured Bytes. When set to:

• text/*
• application/xml
• application/xml-dtd
• application/*+xml
• application/json
• application/*+json
• application/javascript
• application/ecmascript

where “*” is a wild card, the event broker interprets the message as text. If no Content-Type is specified, Content-Type is set to an unknown value, or Content-Encoding is present and not set to identity, the event broker interprets the message as Binary Attachment - Unstructured Bytes.

For more information, see Message Encoding Considerations.

The following table shows how message payloads are converted from SMF to REST (REST response, or RDP message). The Content-Typeheader on the HTTP response is set to the event’s “HTTP Content Type” metadata field if the event’s metadata field is set. Otherwise, a default may be used. If the payload cannot be converted, the event broker delivers the message with an empty body.

Solace Message Type	Payload Present?	Default Content-Type
Binary Attachment - Unstructured Bytes	Yes	application/octet-stream
Binary Attachment - Text	Yes	text/plain
Binary Attachment - Stream	No	-
Binary Attachment - Map	No	-
Binary Attachment - Object	No	-
XML Attachment	Yes	text/xml

Kafka

Solace’s integrated Kafka bridge allows a PubSub+ event broker to send and receive data from a Kafka cluster.

When converting message payloads from Kafka to SMF, the broker converts Kafka messages to SMF messages with Binary Attachment - Unstructured Bytes payloads.

When converting message payloads from SMF to Kafka, the event broker only delivers messages if they have supported payloads as per the following table. All message payloads are converted to Kafka bytes.

Solace Message Type	Message Delivered
Binary Attachment - Unstructured Bytes	Yes
Binary Attachment - Text	Yes
Binary Attachment - Stream	No
Binary Attachment - Map	No
Binary Attachment - Object	No
XML Attachment	Yes

Metadata Conversions

There are a number of metadata fields that can be set on SMF messages. Each protocol has a different set of supported parameters. The PubSub+ event broker translates all messages from a protocol-specific message to SMF messages when it receives them. The event broker then translates the messages back from SMF messages to a protocol-specific message when it sends them to an application.

AMQP

This section contains the following information:

• AMQP to SMF Conversions
• Non-Configurable Fields for AMQP Messages
• SMF to AMQP Conversions
• Non-Retrievable Fields for AMQP Messages

AMQP to SMF Conversions

The following table shows how metadata is converted from AMQP to SMF:

AMQP Field	SMF Field	Default	Notes
Messaging Property Field message-id	Application Message ID	-	AMQP Spec 3.2.4 Properties Can be any of long, UUID, string, binary, and is converted to string when translating between protocols.
Messaging Property Field subject	Application Message Type	-	AMQP Spec 3.2.4 Properties
Messaging Property Fields application-properties	User Property	-	AMQP Spec 3.2.5 Properties All simple types supported and converted where necessary.
Performative Transfer Field batchable	ACK Immediately	False	AMQP Spec 2.7.5 Transfer
Messaging Property Field correlation-id	Correlation ID	-	AMQP Spec 3.2.4 Properties Can be any of long, UUID, string, binary, and is converted to string when translating between protocols.
Messaging Header Field durable	Delivery Mode	Nonpersistent	AMQP Spec 3.2.1 Header False = nonpersistent, True = persistent
Performative Attach target OR if not set: Messaging Property Field to	Destination	Not Set, Required	AMQP Spec 2.7.4 Attach AMQP Spec 3.2.4 Properties If the topic is set per-message, this is known as “anonymous relay”
Performative Attach target capability Or in anonymous relay Messaging annotation message-annotation x-opt-jms-dest Or from prefix of queue:// or topic:// in Messaging Property Field to	Destination Type	Defaults to Queue	AMQP Spec 2.7.4 Attach AMQP Spec 3.2.3 Message Annotations AMQP Spec 3.2.4 Properties
Message Property Field absolute-expiry-time	Expiration	0	AMQP Spec 3.2.4 Properties
Message Property Field content-type	Http Content Type	-	AMQP Spec 3.2.4 Properties
Message Property Field content-encoding	Http Content Encoding	-	AMQP Spec 3.2.4 Properties
Message Property Field group-id	Partition Key	-	AMQP Spec 3.2.4 Properties
Message Header Field priority	Priority	4	AMQP Spec 3.2.1 Header
Message Property Field reply-to	Reply To Topic	-	AMQP Spec 3.2.4 Properties
Message Property Field creation-time	Sender Timestamp	-	AMQP Spec 3.2.4 Properties
Message Header Field ttl	Time To Live	0 (Unlimited)	AMQP Spec 3.2.1 Header

Non-Configurable Fields for AMQP Messages

The publishing application cannot set the following fields on AMQP messages:

SMF Field	Default
Deliver to One	False
DMQ Eligible	True
Eliding Eligible	False
Response Message	-
Sender ID	-
Sequence Number	-

SMF to AMQP Conversions

The following table shows how metadata is converted from SMF to AMQP:

SMF Field	AMQP Field	Notes
Application Message ID	Messaging Property Field message-id	AMQP Spec 3.2.4 Properties Can be any of long, UUID, string, binary.
Application Message Type	Messaging Property Field subject	AMQP Spec 3.2.4 Properties
User Property	Messaging Property Fields application-properties	AMQP Spec 3.2.5 Properties All simple types supported and converted where necessary. SMFMessage, Map, Stream and Destination types are not supported
Correlation ID	Messaging Property Field correlation-id	AMQP Spec 3.2.4 Properties
Delivery Count	Message Header Field delivery-count	AMQP Spec 3.2.1 Header
Delivery Mode	Messaging Header Field durable	AMQP Spec 3.2.1 Header False = nonpersistent, True = persistent
Destination	Messaging Property Field to	AMQP Spec 3.2.4 Properties
HTTP Content Type	Message Property Field content-type	AMQP Spec 3.2.4 Properties
HTTP Content Encoding	Message Property Field content-encoding	AMQP Spec 3.2.4 Properties
Partition Key	Message Property Field group-id	AMQP Spec 3.2.4 Properties
Priority	Message Header Field priority	AMQP Spec 3.2.1 Header
Reply To Topic	Message Property Field reply-to	AMQP Spec 3.2.4 Properties
Redelivered	Message Header Field delivery-count	AMQP Spec 3.2.1 Header A nonzero value indicates that this might be a duplicate delivery.
Sender Timestamp	Message Property Field creation-time	AMQP Spec 3.2.4 Properties
Time To Live	Message Header Field ttl	AMQP Spec 3.2.1 Header

Non-Retrievable Fields for AMQP Messages

The following SMF fields are not available to AMQP clients:

• Discard Indication
• Replication Group Message ID
• Response Message
• Sender ID
• Sequence Number

first-acquirer is not implemented and is always false.

MQTT 5.0

This section contains the following information:

• MQTT 5.0 to SMF Conversions
• Non-Configurable Fields for MQTT 5.0 Messages
• SMF to MQTT 5.0 Conversions
• Non-Retrievable Fields for MQTT 5.0 Messages

MQTT 5.0 to SMF Conversions

The following table shows how metadata is converted from MQTT 5.0 to SMF:

MQTT Field	SMF Field	Default	Notes
Content Type	Application Message Type	-	MQTT 5.0 Spec 3.3.2.3.9 Content Type
User Property	User Property	-	MQTT 5.0 Spec 3.3.2.3.7 User Property MQTT 5.0 only supports string values
Correlation Data	Correlation ID	-	MQTT 5.0 Spec 3.3.2.3.6 Correlation Data
QoS	Delivery Mode	Not Set, Required	MQTT 5.0 Spec 3.3.1.2 QoS QoS 0 = Direct QoS 1 = Persistent QoS 2 = Persistent
Topic Header	Destination	Not Set, Required	MQTT 5.0 Spec 3.3.2.1 Topic Name As with SMF, the topic can be prefixed with _P2P/QUE/<queue> to publish to a queue.
Content Type	Http Content Type	-	MQTT 5.0 Spec 3.3.2.3.9 Content Type
User Property JMSXGroupID	Partition Key	-	MQTT 5.0 Spec 3.3.2.3.7 User Property
PUBLISH Response	Response Message	-	MQTT 5.0 Spec 3.3.4 Response
Message Expiry Interval	Time To Live	0 (Unlimited)	MQTT 5.0 Spec 3.3.2.3.3 Message Expiry Interval

Non-Configurable Fields for MQTT 5.0 Messages

The publishing application cannot set the following fields on MQTT 5.0 messages:

SMF Field	Default
Application Message ID	-
ACK Immediately	False
Deliver to One	False - Shared subscriptions can be used for deliver-to-one functionality
DMQ Eligible	True
Eliding Eligible	False
Expiration	-
Http Content Encoding	-
Priority	4
Reply To Topic	-
Sender ID	-
Sender Timestamp	-
Sequence Number	-

SMF to MQTT 5.0 Conversions

The following table shows how metadata is converted from SMF to MQTT:

SMF Field	MQTT Field	Notes
Application Message Type	Content Type	MQTT 5.0 Spec 3.3.2.3.9 Content Type
User Property	User Property	MQTT 5.0 Spec 3.3.2.3.7 User Property All simple types converted to strings on egress. SMFMessage, Map, Stream, Destination and byte array types are not supported
Correlation ID	Correlation Data	MQTT 5.0 Spec 3.3.2.3.6 Correlation Data
Delivery Mode	QoS	MQTT 5.0 Spec 3.3.1.2 QoS QoS 0 = Direct QoS 1 = Persistent QoS 2 = Persistent
Destination	Topic Header	MQTT 5.0 Spec 3.3.2.1 Topic Name
Partition Key	User Property JMSXGroupID	MQTT 5.0 Spec 3.3.2.3.7 User Property
Reply To Topic	Response	MQTT 5.0 Spec 3.3.4 Response
Redelivered	DUP	MQTT 5.0 Spec 3.3.1.1 DUP
Time To Live	Message Expiry Interval	MQTT 5.0 Spec 3.3.2.3.3 Message Expiry Interval

Non-Retrievable Fields for MQTT 5.0 Messages

The following SMF fields are not available to MQTT 5.0 clients:

• Application Message ID
• Delivery Count
• Discard Indication
• HTTP Content Type
• HTTP Content Encoding
• Priority
• Response Message
• Replication Group Message ID
• Sender ID
• Sender Timestamp
• Sequence Number

MQTT 3.1

This section contains the following information:

• MQTT 3.1 to SMF Conversions
• Non-Configurable Fields for MQTT 3.1 Messages
• SMF to MQTT 3.1 Conversions
• Non-Retrievable Fields for MQTT 3.1 Messages

MQTT 3.1 to SMF Conversions

The following table shows how metadata is converted from MQTT 3.1 to SMF:

MQTT Field	SMF Field	Default	Notes
QoS	Delivery Mode	Not Set, Required	MQTT 3.1.1 Spec 3.3.1.2 QoS QoS 0 = Direct QoS 1 = Persistent QoS 2 = Persistent
Topic Header	Destination	Not Set, Required	MQTT 3.1.1 Spec 3.3.2.1 Topic Name As with SMF, the topic can be prefixed with _P2P/QUE/<queue> to publish to a queue.

Non-Configurable Fields for MQTT 3.1 Messages

The publishing application cannot set the following fields on MQTT 3.1 messages:

SMF Field	Default
Application Message ID	-
Application Message Type	-
User Property	-
ACK Immediately	False
Correlation ID	-
Deliver to One	False - Shared subscriptions can be used for deliver-to-one functionality
DMQ Eligible	True
Eliding Eligible	False
Expiration	-
Http Content Type	-
Http Content Encoding	-
Partition Key	-
Priority	4
Response Message	-
Reply To Topic	-
Sender ID	-
Sender Timestamp	-
Sequence Number	-
Time To Live	0 (Unlimited)

SMF to MQTT 3.1 Conversions

The following table shows how metadata is converted from SMF to MQTT 3.1:

SMF Field	MQTT Field	Notes
Delivery Mode	PUBLISH QoS	MQTT 3.1.1 Spec 3.3.1.2 QoS QoS 0 = Direct QoS 1 = Persistent or non-persistent
Destination	Topic Header	MQTT 3.1.1 Spec 3.3.2.1 Topic Name
Redelivered	PUBLISH DUP	MQTT 3.1.1 Spec 3.3.1.1 DUP

Non-Retrievable Fields for MQTT 3.1 Messages

The following SMF fields are not available to MQTT 3.1 clients:

• Application Message ID
• Application Message Type
• User Property
• Correlation ID
• Delivery Count
• Discard Indication
• HTTP Content Type
• HTTP Content Encoding
• Partition Key
• Priority
• Response Message
• Reply To Topic
• Replication Group Message ID
• Sender ID
• Sender Timestamp
• Sequence Number
• Time To Live

JMS

This section contains the following information:

• JMS to SMF Conversions
• Non-Configurable Fields for JMS Messages
• SMF to JMS Conversions
• Non-Retrievable Fields for JMS Messages

JMS to SMF Conversions

The following table shows how metadata is converted from JMS to SMF:

JMS Field	SMF Field	Default	Notes
JMSMessageID	Application Message ID	-	JMS 1.1 3.4.3 JMSMessageID Must have prefix “ID:”
JMSType	Application Message Type	-	JMS 1.1 3.4.8 JMSType
JMS Property	User Property	-	JMS 1.1 3.5 Message Properties Any property not prefixed with JMS including JMSX and JMS_
JMSCorrelationID	Correlation ID	-	JMS 1.1 3.4.5 JMSCorrelationID
Message Delivery Mode	Delivery Mode	Direct	JMS 1.1 4.7 Message Delivery Mode
Message Property JMS_Solace_DeliverToOne	Deliver to One	False	JMS 1.1 3.5 Message Properties
Destination	Destination	Not Set, Required	JMS 1.1 4.2.1 Destination Working with Destinations
Message Property JMS_Solace_DeadMsgQueueEligible	DMQ Eligible	True	JMS 1.1 3.5 Message Properties
Message Property JMS_Solace_ElidingEligible	Eliding Eligible	False	JMS 1.1 3.5 Message Properties
JMSExpiration	Expiration	Not set or current time + time-to-live if TTL is specified	JMS 1.1 3.4.9 JMSExpiration Set automatically if Time-To-Live is set as current time + Time-To-Live
Message Property JMS_Solace_HTTPContentType	Http Content Type	-	JMS 1.1 3.5 Message Properties
Message Property JMS_Solace_HTTPContentEncoding	Http Content Encoding	-	JMS 1.1 3.5 Message Properties
JMS Property JMSXGroupID	Partition Key	-	JMS 1.1 3.5.9 JMS Defined Properties
JMSPriority	Priority	4	JMS 1.1 3.4.10 JMSPriority
Message Property Solace_JMS_Prop_IS_Reply_Message	Response Message	-	JMS 1.1 3.5 Message Properties
JMSReplyTo	Reply To Topic	-	JMS 1.1 3.4.6 JMSReplyTo
Message Property JMS_Solace_SenderId	Sender ID	-	JMS 1.1 3.5 Message Properties
JMSTimestamp	Sender Timestamp	-	JMS 1.1 3.4.4 JMSTimestamp
Message Property JMS_Solace_TopicSequenceNumber	Sequence Number	-	JMS 1.1 3.5 Message Properties
Message Time-To-Live	Time To Live	0 (Unlimited)	JMS 1.1 4.8 Message Time-To-Live

Non-Configurable Fields for JMS Messages

The publishing application cannot set the following fields on JMS messages:

SMF Field	Default
ACK Immediately	False

SMF to JMS Conversions

The following table shows how metadata is converted from SMF to JMS:

SMF Field	JMS Field	Notes
Application Message ID	JMSMessageID	JMS 1.1 3.4.3 JMSMessageID
Application Message Type	JMSType	JMS 1.1 3.4.8 JMSType
User Property	JMS Property	JMS 1.1 3.5 Message Properties Any property not prefixed with JMS including JMSX and JMS_
Correlation ID	JMSCorrelationID	JMS 1.1 3.4.5 JMSCorrelationID
Delivery Count	JMS Property JMSXDeliveryCount	JMS 1.1 3.5.9 JMS Defined Properties
Delivery Mode	JMSDeliveryMode	JMS 1.1 3.4.2 JMSDeliveryMode
Destination	Destination	JMS 1.1 4.2.1 Destination
Discard Indication	Message Property JMS_Solace_MsgDiscardIndication	JMS 1.1 3.5 Message Properties
HTTP Content Type	Message Property JMS_Solace_HTTPContentType	JMS 1.1 3.5 Message Properties
HTTP Content Encoding	Message Property JMS_Solace_HTTPContentEncoding	JMS 1.1 3.5 Message Properties
Partition Key	JMS Property JMSXGroupID	JMS 1.1 3.5.9 JMS Defined Properties
Priority	JMSPriority	JMS 1.1 3.4.10 JMSPriority
Response Message	Message Property Solace_JMS_Prop_IS_Reply_Message	JMS 1.1 3.5 Message Properties
Reply To Topic	JMSReplyTo	JMS 1.1 3.4.6 JMSReplyTo
Redelivered	JMSRedelivered	JMS 1.1 3.4.7 JMSRedelivered
Sender ID	Message Property JMS_Solace_SenderId	JMS 1.1 3.5 Message Properties
Sender Timestamp	JMSTimestamp	JMS 1.1 3.4.4 JMSTimestamp
Sequence Number	Message Property JMS_Solace_TopicSequenceNumber	JMS 1.1 3.5 Message Properties
Time To Live	Message Time-To-Live	JMS 1.1 4.8 Message Time-To-Live

Non-Retrievable Fields for JMS Messages

The following SMF fields are not available to JMS clients:

• Replication Group Message ID

HTTP/REST Messaging

This section contains the following information:

• HTTP to SMF Conversions
• Non-Configurable Fields for HTTP Messages
• SMF to HTTP Conversions
• Non-Retrievable Fields for HTTP Messages

For more information on how to use Solace REST Messaging, see Open APIs & Protocols - REST.

HTTP to SMF Conversions

When you send messages with HTTP messaging, use the following conversion table:

HTTP Field	SMF Field	Default	Notes
HTTP Header Solace-Message-ID	Application Message ID	If you use request-reply messaging or microgateway mode, the default is a unique value prefixed with ID:Solace-. Otherwise, the default is unset.	Solace REST Usage of HTTP Headers
Any header not already in use is passed through transparently, or converted into JMS_Solace_HTTP_field_<fieldName> when consumed by non-HTTP clients	User Property (Microgateway mode)	-	Only string value types are supported
HTTP header in the form Solace-User-Property-{name}: {value};type={type} is converted in to a property with name {name}. If no type information is present, string value type is used.	User Property (Microgateway or messaging mode)	-	Solace Message Custom Properties
HTTP Header Solace-Correlation-ID	Correlation ID	If you use request-reply messaging or microgateway mode, the default is a unique value prefixed with ID:Solace-. Otherwise, the default is unset.	Solace REST Usage of HTTP Headers
HTTP Header Solace-Delivery-Mode	Delivery Mode (Microgateway mode)	Direct	One of [Direct | Non-Persistent | Persistent]
HTTP Header Solace-Delivery-Mode	Delivery Mode (Messaging mode)	Persistent	One of [Direct | Non-Persistent | Persistent]
Destination is encoded into the REST request path as per HTTP Request-Target	Destination	Not Set, Required	HTTP Request-Target If using Microgateway mode, only publishing to topics is allowed. In Messaging mode, the destination may be prefixed with /TOPIC or /QUEUE in the request target.
HTTP Header Solace-DMQ-Eligible	DMQ Eligible	False	[true|false]
HTTP Header Content-Type	Http Content Type	-	Solace REST Usage of HTTP Headers
HTTP Header Content-Encoding	Http Content Encoding	-	Solace REST Usage of HTTP Headers
HTTP Header Solace-User-Property-JMSXGroupID	Partition Key	-	Solace REST Usage of HTTP Headers
If in messaging mode, HTTP Header Solace-Reply-To-Destination may be used to set the reply to topic of the message. In addition, Solace-Reply-Wait-Time-In-ms may be used to set the message as a request reply message with an auto generated reply-to topic that points back to this HTTP client. In Microgateway mode, all messages are implicitly request-reply messages with a default timeout of 30 seconds. Solace-Reply-Wait-Time-In-ms can be used to change the default.	Reply To Topic	-	Value: /[QUEUE/TOPIC]/<destination string>
HTTP Header Solace-Timestamp	Sender Timestamp	-	Solace REST Usage of HTTP Headers
HTTP Header Solace-Time-To-Live-In-ms	Time To Live	0 (Unlimited)	Solace REST Usage of HTTP Headers

Non-Configurable Fields for HTTP Messages

The publishing application cannot set the following fields on HTTP messages:

SMF Field	Default
ACK Immediately	-
Application Message Type	-
Deliver to One	False
Eliding Eligible	False
Expiration	-
Priority	4
Response Message	-
Sender ID	-
Sequence Number	-

SMF to HTTP Conversions

If your application expects a response, for instance in Microgateway mode or when you use request-reply (as set via Solace-Reply-Wait-Time-In-ms), the following table shows how to convert the response to an HTTP response:

SMF Field	RDP Field	Notes
Application Message ID	HTTP Header Solace-Message-ID	Solace REST Usage of HTTP Headers
User Property (Microgateway mode)	Any property of the form JMS_Solace_HTTP_field_<fieldName> is set as an HTTP header with name <fieldName>. Any other user properties is sent as Solace-User-Property-{name}.	All value types are converted to strings SMFMessage, Map, Stream, Destination and byte array types are not supported
User Property (messaging mode)	HTTP header in the form Solace-User-Property-{name}: {value};type={type}	Solace Message Custom Properties SMFMessage, Map, Stream, Destination and byte array types are not supported
Correlation ID	HTTP Header Solace-Correlation-ID	Solace REST Usage of HTTP Headers
Delivery Mode	HTTP Header Solace-Delivery-Mode	Solace REST Usage of HTTP Headers
HTTP Content Type	HTTP Header Content-Type	Solace REST Usage of HTTP Headers
HTTP Content Encoding	HTTP Header Content-Encoding	Solace REST Usage of HTTP Headers
Partition Key	HTTP Header Solace-User-Property-JMSXGroupID	Solace REST Usage of HTTP Headers
Sender Timestamp	HTTP Header Solace-Timestamp	Solace REST Usage of HTTP Headers
Time To Live	HTTP Header Solace-Time-To-Live-In-ms	Solace REST Usage of HTTP Headers

Non-Retrievable Fields for HTTP Messages

The following SMF fields are not available to HTTP clients:

• Application Message Type
• Delivery Count
• Destination
• Discard Indication
• Priority
• Response Message
• Reply To Topic
• Redelivered
• Replication Group Message ID
• Sender ID
• Sequence Number

RDPs

This section contains the following information:

• SMF to HTTP Request Conversions
• Non-Retrievable Fields for RDP Messages
• HTTP Response to SMF Conversions
• Non-Configurable Fields for RDP Messages

SMF to HTTP Request Conversions

When delivering messages from SMF to a REST Delivery Point, the following table shows how an SMF message is converted to an HTTP Request message. Some fields are also accessible through substitution expressions which can be used to determine the RDP request target or request headers.

SMF Field	RDP Field	Substitution Expression	Notes
Application Message ID	HTTP Header Solace-Message-ID	msgId	Solace REST Usage of HTTP Headers
Application Message Type	-	msgType	-
User Property (Microgateway mode)	Any property of the form JMS_Solace_HTTP_field_<fieldName> is set as an HTTP header with name <fieldName>. Any other user properties is sent as Solace-User-Property-{name}.	-	All value types are converted to strings SMFMessage, Map, Stream, Destination and byte array types are not supported
User Property (Messaging mode)	HTTP header in the form Solace-User-Property-{name}: {value};type={type}	-	Solace Message Custom Properties SMFMessage, Map, Stream, Destination and byte array types are not supported
Correlation ID	HTTP Header Solace-Correlation-ID	correlationId	Solace REST Usage of HTTP Headers
Delivery Mode	HTTP Header Solace-Delivery-Mode	-	Solace REST Usage of HTTP Headers
Destination	-	topic	-
HTTP Content Type	HTTP Header Content-Type	-	Solace REST Usage of HTTP Headers
HTTP Content Encoding	HTTP Header Content-Encoding	-	Solace REST Usage of HTTP Headers
Partition Key	HTTP Header Solace-User-Property-JMSXGroupID	partitionKey	Solace REST Usage of HTTP Headers
Sender ID	-	senderId	-
Sender Timestamp	HTTP Header Solace-Timestamp	-	Solace REST Usage of HTTP Headers
Sequence Number	-	sequenceNumber	-
Time To Live	HTTP Header Solace-Time-To-Live-In-ms	-	Solace REST Usage of HTTP Headers

Non-Retrievable Fields for RDP Messages

The following SMF fields are not available to RDP clients:

• Delivery Count
• Discard Indication
• Priority
• Response Message
• Reply To Topic
• Redelivered
• Replication Group Message ID

HTTP Response to SMF Conversions

RDP messages may be responded to, and automatically forwarded to, the Reply-To topic. The event broker always treats RDP response messages as direct messages.

The following table shows how the HTTP response is converted to an SMF message:

REST Field	SMF Field	Default	Notes
HTTP Header Solace-Message-ID	Application Message ID	-	Solace REST Usage of HTTP Headers
HTTP header in the form Solace-User-Property-{name}: {value};type={type}	User Property	-	Solace Message Custom Properties SMFMessage, Map, Stream, Destination and byte array types are not supported
HTTP Header Solace-Correlation-ID	Correlation ID	-	Solace REST Usage of HTTP Headers
HTTP Header Content-Type	Http Content Type	-	Solace REST Usage of HTTP Headers
HTTP Header Content-Encoding	Http Content Encoding	-	Solace REST Usage of HTTP Headers
HTTP Header Solace-User-Property-JMSXGroupID	Partition Key	-	Solace REST Usage of HTTP Headers
HTTP Header Solace-Timestamp	Sender Timestamp	-	Solace REST Usage of HTTP Headers
HTTP Header Solace-Time-To-Live-In-ms	Time To Live	0 (Unlimited)	Solace REST Usage of HTTP Headers

Non-Configurable Fields for RDP Messages

The publishing application cannot set the following fields on RDP response messages:

SMF Field	Default
ACK Immediately	N/A, all responses are direct messages
Application Message Type	-
Delivery Mode	Direct
Deliver to One	False
Destination	Automatically set to Reply-To destination
Destination Type
DMQ Eligible	N/A, all responses are direct messages
Eliding Eligible	False
Expiration	-
Priority	4
Response Message	True
Reply To Topic	-
Sender ID	-
Sequence Number	-

Kafka

This section contains the following information:

• Kafka to SMF Conversions
• Non-Configurable Fields for Kafka Receivers
• SMF to Kafka Conversions
• Non-Retrievable Fields for Kafka Senders

Kafka to SMF Conversions

The following table shows how metadata is converted from Kafka to SMF by way of a Kafka Receiver. For more information, see Configuring SMF Topic Generation in Kafka Receivers.

Kafka Field	SMF Field	Default	Notes
Kafka header	User Property	-	All Kafka headers are binary blobs and converted to byte arrays
Topic is configured through the Kafka receiver’s topic-binding local-topic	Destination	Not Set, Required	Prefixes may be used to publish to queues
Partition Key	Partition Key	-	-
Timestamp	Sender Timestamp	-	-

Non-Configurable Fields for Kafka Receivers

The following fields cannot be set through Kafka receivers:

SMF Field	Default
Application Message ID	-
Application Message Type	-
ACK Immediately	False
Correlation ID	-
Delivery Mode	Persistent
Deliver to One	False
DMQ Eligible	True
Eliding Eligible	False
Expiration	-
Http Content Type	-
Http Content Encoding	-
Priority	4
Response Message	-
Reply To Topic	-
Sender ID	-
Sequence Number	-
Time To Live	0 (Unlimited)

SMF to Kafka Conversions

The following table shows how metadata is converted from SMF to Kafka via a Kafka Sender:

SMF Field	Kafka Field	Notes
User Property	Kafka header	All simple types are converted to a binary blob and attached as Kafka headers on the message. Note that custom Kafka headers are not possible.
Sender Timestamp	Timestamp	-

For information about accessing SMF fields through substitution expressions, see Substitution Expressions Overview.

Non-Retrievable Fields for Kafka Senders

Kafka senders cannot use the following fields:

Some of the fields below can be retrieved for use in the Kafka partition key through the use of substitution expressions. For more information, see Substitution Expressions Overview.

• Application Message ID
• Application Message Type
• Correlation ID
• Delivery Count
• Delivery Mode
• Destination
• Discard Indication
• HTTP Content Encoding
• HTTP Content Type
• Partition Key
• Priority
• Redelivered
• Reply To Topic
• Replication Group Message ID
• Response Message
• Sender ID
• Sequence Number
• Time To Live

Messages are always set to “at least once” delivery guarantee in Kafka.