So far, you've set up the integration messages that carry the data across your hopeful integration solution, and you've created an inbound endpoint on the Mobilengine side to welcome the arriving messages. Now you'll be putting the final element of your integration solution in place: the web service client that receives the integration messages from Rocky Jupiter, and sends them along to the Mobilengine Cloud.
Most of the heavy lifting has been done for you: you get the WSDL file that you can use to
set up the web service client. The WSDL is a generic type of web service service contract, a
collection of metadata relating to, in this particular case, the custom WDX web service
protocol and the details of the dacs
-es that you want your web service
client to handle.
Armed with the service contract for the web service client, you'll use an IDE to generate the service contract code for the web service client, and use the operations declared in the code.
The implementation that you set up will serve purely to test the integration solution,
nothin more: you'll write a dummy dacs
, and make the client send it across
the wire to the Cloud every time you manually start up the web service client. You'll need
some proof that the message really did reach the Cloud, so the final step is to set up a
workflow script that runs when a newTask dacs
arrives.
After that, you'll just start up the freshly minted web service client, see the contents of the incoming integration message show up in the Cloud log, and smile. Let's begin then, shall we?