Implement inbound integration

What you'll be learning:

  • How to create a WDX-compliant web service client from a custom WSDL file

  • How to associate a workflow script with an integration message instead of a form submission

  • How to use the trace statement in a workflow script

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?