Where do i find all mappings between Solace proprietary fields and standard protocols like JMS,MQTT

Options
Robert
Robert Member Posts: 58 ✭✭

Solace has build a solution which supports multiple protocols. To be able to do that a mapping is needed between internal (proprietary) message fields and fields defined as part of the standard related to protocols like MQTT, JMS.

JMS:

Message (Java(TM) EE 7 Specification APIs) (oracle.com)

I search for something like that (not as part of blog) being mentioned in core documentation.

Inside a Solace Message, Part 2: Using Header Properties - Solace

It should cover all mappings (this blog only mentions some). So best would be an overview of all solace message fields and mapping towards each protocoll.

MQTT:

MqttMessage (MQTT v3 Client API) (ibm.com)

RDP (to http header):

That mapping exists documented here:

Solace REST HTTP Message Encoding Chapter: Solace-Specific HTTP Headers

With some problems:

  • Why header field is called Solace-Message-Id and not as named in solace Solace-Application-Message-Id (that name is used on the solace API and everywhere else)
  • Mappings are missing - e.g. why is replication message group id missing ? That field is best for deduplication. ReplicationGroupMessageId (Solace Messaging API for Java v10.16.0) It as well shows that there are internal multiple message ids and if not naming clear you have to guess that Solace-Message-Id is filled with ApplicationMessageId. :-)

Looking forward for your help and view on that topic.

Best Answer

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 527 admin
    #2 Answer ✓
    Options

    Hi @Robert. As far as I know, I don't think there is an official master list of what you're looking for. But I did make up an Excel spreadsheet for my own similar purposes a while ago, and will included here if it helps?

    A few things:

    • JMS is not a protocol, but a Java programming API standard. But there should be a pretty good 1-to-1 mapping of JMS headers to Solace headers.
    • MQTT has very few standard headers... v5 has more than v3.1.1 though. My spreadsheet didn't consider MQTT, (or AMQP), maybe I'll go research those too and update it
    • RDPs / REST Messaging: you found the best page in our docs, I've looked through that lots too... as you noted, there are some discrepancies, and some missing headers, and there are internal JIRA Issues raised against these. Not sure when they'll be fixed.


Answers

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 527 admin
    #3 Answer ✓
    Options

    Hi @Robert. As far as I know, I don't think there is an official master list of what you're looking for. But I did make up an Excel spreadsheet for my own similar purposes a while ago, and will included here if it helps?

    A few things:

    • JMS is not a protocol, but a Java programming API standard. But there should be a pretty good 1-to-1 mapping of JMS headers to Solace headers.
    • MQTT has very few standard headers... v5 has more than v3.1.1 though. My spreadsheet didn't consider MQTT, (or AMQP), maybe I'll go research those too and update it
    • RDPs / REST Messaging: you found the best page in our docs, I've looked through that lots too... as you noted, there are some discrepancies, and some missing headers, and there are internal JIRA Issues raised against these. Not sure when they'll be fixed.


  • Robert
    Robert Member Posts: 58 ✭✭
    Options

    @Aaron exactly that is what i look for and is needed as it would show even gaps on mapping of solace fields to RDP and target http header like ReplicationGroupMessageId.

    I will raise a feature request to make this mappings transparent and public.

    They are essential to understand and as mentioned by mixing in Solace sometimes between internal names and solace public names you loose control on what data goes in which field on interface level.

    I would include MQTT as well then. Any mapping is needed when different interfaces are exposed by Solace. JMS, RDP (REST) and MQTT are part of that list.

    Again mainy thanks for sharing and working on that and let's hope it is soon part of public documentation.