function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
jd510jd510 

Outbound Message NOT being sent

Hi All:

Do you know of any reason why an Outbound Message would NOT send.  I have a message that is sitting in the queue with 0 attempts.  Each time I hit 'Retry' it still says 0.

Any and all assistance is appreciated.

Thanks,
jd
SuperfellSuperfell
Are you still having this problem ?
jd510jd510
Yes, Outbound Messaging is still not working.  Do you have any idea why this is happening?  It just stopped working last week.

jd
SuperfellSuperfell
I looked last week when you posted and everything appeared ok. Have you logged a case with support ?
jd510jd510
Yes, I logged a case.

Thanks for looking into this issue.

jd
SuperfellSuperfell
What's the case# ?
jd510jd510
Case #: 01380630
jd510jd510
Hi Simon:

Can you offer some assistance?  I have been unable to get a clear answer as to why this behavior occurred and how to recover from it.

This issue has already caused us to miss our rollout date.

Thanks in advance,
jd
SuperfellSuperfell
I'm sorry you weren't able to get a satisfactory answer from support.

I don't think its explicitly called out anywhere in the docs, but the retry button in the queue page is not a synchronous retry, all it does is bump that message to the top of your queue, but does nothing to improve the scheduling of your queue overall.

Your endpoint seems to continuly respond with an explicit NACK, that's fine, but after a while we'll stop trying quite as hard to deliver the message, as you're likely to just NACK it again. Once your queue is in this condition, then under extreme circumstances, there can be a significant delay in the processing of your queue, however delivery will be attempted eventually.

If timelyness of the messages is a significant issue for your integration (and you should note that there's no guarantees on how long it will take to delivery the message) then your best bet is to have your listener do the minimal amount of processing possible before ack'ing the message, typically this is to put the message into a local queue. that way your endpoint never falls into the too many nacks category. You can then manage retries / message longevity etc however you wish.

Hope that clarifies some things, rather than adding to the confusion. Feel free to post any follow up questions here.


jd510jd510
Hi Simon:

Thank you for the information.  I was able to speak to someone at Salesforce today who also added clarity. 

My main concern now is recovery of a message if it is placed into this lower priority queue. It seems that it is possible for a message to remain in the lower priority queue past its expiration causing the message to be lost forever.  Do you have any suggestions for recovery, or notification  if the message is about to expire?

Thanks again,
jd
SuperfellSuperfell
The expiration checking is done only after a delivery attempt, so in the case where the next delivery time falls within the expiration window, but the actual delivery attempt is past the expiration window, the delivery attempt is still made.

For example, if you have a message that is 21:59 hours old and the delivery attempt fails, then the next delivery attempt would be for when its 23:59 old, however if because you're in the lower priority queue the delivery attempt isn't actually until 24:05, it will still be attempted at 24:05. Only if that attempt fails, putting the next delivery out of the expiration window would the message be abandoned.

sumpritsumprit
did you get reply / answer for this question. I have a similiar situation
prbprb
So was the problem a timeout here?   I don't see any error messages in my outbound message queue but they don't send.
There is no trace of any attempt at communication in our firewall logs.
How is it possible to have a lower priority in the queue?  I want them all to be high priority.