User bio
404 bio not found
Maine, USA
Member since Feb 18, 2016
Posts:
Replies:
Are you supplying a cache-control header in your response?
An error that would cause a suspended message should appear in the operation's error log. That would also have the session ID and a link to a trace of the message.
You could also query via SQL for a message header that starts with the string "Resent" in the Description field; that's the resent copy of the message but it will include the original message ID following the word "Resent." It will have the same session ID as the source message and both will show up in the trace.
A sample query:
SELECT ID, MessageBodyId, TargetConfigName, TimeCreated, Description
FROM Ens.MessageHeader
WHERE
ID >= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated >='2025-06-25 10:45:00.000' ORDER BY TimeCreated ASC)
AND
ID <= (SELECT TOP 1 ID FROM Ens.MessageHeader WHERE TimeCreated <='2025-06-26 00:00:00.000' ORDER BY TimeCreated DESC)
AND
TargetConfigName = 'To_Downstream_System'
AND
Description LIKE 'Resent%'
Certifications & Credly badges:


Global Masters badges:







Followers:
Following:
In a routing rule, temporary variables must be declared in the rule's general tab:
And in the rule proper, they must be prefixed with an "@" symbol wherever they're referenced:
The foreach as you've designed it will only set the values for tSendAbnormal and tSendNormal based on the contents of the last OBX segment in the message, since it keeps looping until it either hits the last segment or you've triggered a return based on a condition.
What, exactly, are your criteria for sending a message to the "Normal" transformation vs. the "Abnormal?" In a result message, some observations (OBX segments) may have abnormal flags while others won't. Would such a message qualify for both transformations?