I've coded up the MSMQ example that is included in the help file for eConnect, and had good success. The only issue that I could not figure out was what happens to the error messages. eConnect validates the documents that you send and kicks back a number of them.
Since MSMQ is disconnected (it's designed so that the SQL server can go down and the messages will queue and get processed when the server comes back up), where do the errors go? They always go to the eConnect event log on the server, but it seems onerous to monitor the server event log from a client for an error that may or may not show up.
Kevin Johnson, a modorater on the Partner message board, provides the answer:
The eConnect Incoming Service logs errors to the eConnect event log the same as an eConnect API call. It also routes the failed message to the deadletter queue that you have configured for the service. So monitoring the eConnect event log or the deadletter queue would be the only way to track failures when using the Incoming service.
FYI, the Incoming Service can add the error description to a failed message that is routed to the deadletter queue by ensuring that you include:
<eConnectProcessInfo>
<ProcReturnCode />
</eConnectProcessInfo>
in the XML you're passing to the Incoming Service. If your incoming XML contains this and the message fails, the same error description that goes to the event log is populated in the ProcReturnCode field of the XML sent to the deadletter queue allowing you see why the message failed.
Sample code below.