You need to sign in to do that
Don't have an account?
jd510
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
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
jd
Thanks for looking into this issue.
jd
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
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.
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
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.
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.