hi @hkszlq . The value that you see inside the broker in your screenshot there is a sequence number the Persistent pipeline automatically assigns. I believe it corresponds to IMessage.ADMessageId. IMessage.ADMessageId Property
You can’t/shouldn’t rely on this number or use it for anything other than acknowledging messages. It’s just for “internal” broker-to-API use. It is shared across all queues/consumers/Message VPNs on the broker, so don’t try to infer anything from it.
If you (the application) needs a message ID of some sort, for sequencing or uniqueness or whatever, your publisher should insert either a SequenceNumber (Long) or a ApplicationMessageId (String). Those are the usual candidates for adding some identifiers to your published messages.
Tks for your reply.
We have obtained all the message attribute values. ADmessageID is not the messageid displayed on the management site. I don’t know the reason.
Because according to the test case, we need to obtain this messageID.
The JMS MessageID is a field in the JMS header generated by JMS Producers. As such it is considered ‘meta’ data and part of the payload of Solace messages. It is not visible in the broker management interfaces. It is not the ADMessageId.
In general the ADMessageID should not be extracted and in future releases of the API it may be deprecated. This number is not useful on it’s own and may or may not match the message ID displayed in the broker, depending on the transport characteristics.
In .NET the JMS MessageID is known as the ‘ApplicationMessageId’.
@Ragnar said:
The JMS MessageID is a field in the JMS header generated by JMS Producers. As such it is concerted ‘meta’ data and part of the payload of Solace messages. It is not visible in the broker management interfaces. It is not the ADMessageId.
In general the ADMessageID should not be extracted and in future releases of the API it may be deprecated. This number is not useful on it’s own and may or may not match the message ID displayed in the broker, depending on the transport characteristics.
In .NET the JMS MessageID is known as the ‘ApplicationMessageId’.
string ApplicationMessageId { get; set; }
Thank you Ragnar.
Can’t I get the value of MessageID in the picture?
I’m sorry to say that table is misleading. There is no relationship between ApplicationMessageId (aka JMS MessageId) and the ‘ADMessageId’. The ApplicationMessageId is whatever string that is set by the publishing applications. The JMS API has the ability to auto-generate this field.
While the broker does generate a unique ID for each message stored on the broker, that messageId, which you see in the broker admin interface, is not available through the APIs.
The ADMessageId in CSCSMP is simply a transport acknowledgment number and internal to the API/broker protocol and not useful. This is why in a future release it will be deprecated, as the application simply calls ‘IMessage.ack()’ to remove a message from the broker and does not need to know the transport acknowledgement number.
excuse me. I have one more question for you, why can’t be assigned to the correlationId attribute in the request response mode, the code has already given the value, but the value is always: #SOL1
Hello. I’ve been away and you may have solved this already.
The CorrelationID in request/response is used to map the response to the original request. solClient_session_sendRequest automatically sets this to a easy to parse but unique string (#SOLnnn) for each request. Then the sending session can easily and quickly, which is the important part, scan all incoming messages for the response to the request.
_solClient_session_sendReply automatically retrieves the correlationId from the request message, and the reply-to topic, and populates the reply message with these values so the reply get to the right place.
The application cannot override correlationId, and if it were able to do so, request-reply would not work.
If you send multiple messages, you should see that value increase, the autogenerated Correlation ID. It’s not always #SOL1.
You can actually override/set the correlation ID if you want, but I think it gets overwritten if you use the convenience feature ISession.SentRequest().