To address why it retries sometimes and at other times requires manual retry, in the workflow there is a ResponseXSLT step. You will need to create a custom XSLT to handle the errors you get back from ECC or the corresponding system. If the error code is classified as a SYS_ERROR it will retry, if it classified as an APP_ERROR it will not. The standard Response XSLT has an example for error code 469 or when the connection to ECC fails. Any other error will result in SYS_ERROR thus no retry.
You can see the error code in the response XSLT in the Document Trace Response.
Does your code which inserts the transaction into SAPMEINT utilize the standard Enqueuer logic or is it custom? If you do, you may have the retry limit hard coded rather than looking at the workflow to identify it as the standard Enqueuer does. We had a similar issue utilizing a web service.
We also see the 2/1 sometimes if there is more than one dispatcher running or if there is still one running in the background which you can not see. For example, if you stop the dispatcher mid-job it will continue running in the background until all of the records are processed and because there is no indicator in the MEINT database to identify whether a record is currently being processed if you restart the dispatcher it wil process the record again since the previous job has not updated it yet.
