So I have a workflow set up to send an outbound message containing information regarding the opportunity that was edited. I have it set up to send a message every time an opportunity is edited and the opportunity stage name is 1 of 4 possible values. The problem is, it's sending the message three to 4 times after it is edited and saved. I have a test account in salesforce that I am testing with to see the results. I looked in the outbound message log and am seeing this as the reason that some of the messages are failing because of an "org.xml.sax.SAXParseException: Premature end of file." error. Does anyone know why this would be happening? Perhaps it is trying to send over a field that is halting compilation? I am nit sure. Does any have any ideas? Thanks!
Best Answer
The error message indicates that the salesforce server started parsing the soap/xml response from your outbound messaging listener, but it got the end of the response data before it got the the valid end of the xml structure. As indicated in the other answers link, this can be for many reasons which you'll need to work through, a bug in your listeners code (like not flushing a buffer, or a problem with exception handling), an issue with an intermediate device (your network firewall or reverse proxy).
The retry link in the outbound messaging monitoring page can help you trigger a message when you can monitor your end. (tools like wireshark & soapscope can help you monitor the http back and forth to you server).
Finally, its worth understanding that OM is an "at least once" delivery service, what this means is that the server will attempt to keep delivering the message until your service has correctly acknowledged the message and importantly that the salesforce server has completed handling your ack. (It will eventually give up after 24 hours) There are numerous failure scenarios where the salesforce service will decide to resend the message, even if your server sent a valid ack, and you need to design your listener with this in mind. (e.g. keep track of successfully processed message ids, and don't do processing on messages Ids you've already received, or implement your listener such that its idempotent).