The asynchronous job interface uses comprehensive XML data sets that can be transferred to eCircle in various ways.
Together with that XML, other mass data like recipient lists, attachments or images may be transferred.
Unlike other API's, this API works within group context.
The data you need to transfer may be heavy too, for emails you may want to transfer huge address lists to us. The messages may contain images or attachments wich need to get to us first, before a message to the recipient is constructed. For this purpose, you may put your data, the XML as well as the binary data together into a package before you sent it to us.
This package may be a simple zip-File, or, more suitable for automation, a mime-Package that is transferred via the SOAP-with-Attachments mechanism.
See GroupJobPackage for a detailed discussion of the various XML parts and how they are related within each other in package.There is a API Test-Page to manually exercize with the rather complex XML object. In eC-Messenger 5.2ff you can find this page, when setting up a SOAP-ControlMessage-Activity (Administration->Activity->Time Based-> New "SOAP Control"->"Test your Message") Note the in the authentication of such a async message, the eC-M' sysname is to be used, NOT the http access url (as it is in the synchronous SOAP interface)
http://<your-domain-at-ecircle>/eC-MessageService. There is currently no WSDL available. There is some Java Sample Code
If accepting the package fails on our side, a protocol error may be given. For a SOAP transfer, a message is syntactically checked still while a connection to the sender is established. This is not the case for FTP transfers, where processing only starts after the whole package was transferred, so only FTP related errors may show up.
Further processing such a package leads to a controlResultMessage, that contains an attribute processing-result whichmay have the following states:
A simple way for a caller to check the completion of the processing is to verify that the control-result message that is sent to the success-report-address- contains a processing-result=”COMPLETE” -Attribute in its top-Level Node .
It is possible to use the same addresses for both, success-report-address and failure-report-address. Up to 10 addresses may be scheduled for each node.
[#1] You'll have to HTTP POST your message to this location, in case you'll want to check this access point. A http GET (as done with your browser) will only lead to an AXIS Error. A POST will respond with a proper SOAP fault, similiar to this one..
<soapenv:Envelope> <soapenv:Body> <soapenv:Fault> <faultcode>ns1:Client.NoSOAPAction</faultcode> <faultstring>no SOAPAction header!</faultstring> <detail> <ns2:stackTrace> no SOAPAction header! at org.apache.axis.transport.http.AxisServlet.getSoapAction(... ...