CODEWITHSUNDEEP
muleesb
Rajeun
Rajeun

Reputation: 721

receiving an input file dynamically and put my mule application in listening

Scenario: - An application want to send a push to a list of device. - so she sends information to my mule application which must be listening to the arrived information. - My application will send this information via web service to the application which will send the push and then my application will wait for a response which is a json file with content: success: 0/1 failed: 0/1, - according to this answer my mule application will send email which i take from the database, if the device concerned didn't receive the push.

I have done the last part of this scenario. from the receipt of the answer of the push. Now I have some questions about the first part:

  1. I guess that the application sends a json file that contains a list of information of each device. How processed the list of information devices. I must loop on the contents of the json file. any example of this?
  2. How to put my application in listening for the arrivals request for sending push? is the http connector sufficient? if so how to configure the path variable.

I'm using mule 3.5.0 CE, Thank you in advance.

Upvotes: 0

Views: 65

Answers (1)

Burhan Khalid
Burhan Khalid

Reputation: 174748

Lets break this down, to the various components:

  1. Sender Application - this is the service that needs to communicate with the devices.

  2. Device Controller - this is the application that talks to the hardware devices.

  3. Proxy - this is what you are developing on the Mule ESB. It will connect to both the Sender Application, and the Device Controller and transfer the request from Sender to Controller; and then send the results from the Controller back to the Sender.

The flow would look something like this:

  1. Sender Application needs to communicate with devices.
  2. Sender Application transmits information using JSON.
  3. Proxy receives this JSON request.
  4. The Proxy then contacts the Device Controller over HTTP.
  5. The Device Controller only talks to the Proxy, and returns a result of 0 or 1 depending on the result from the physical device.
  6. The Proxy then needs to communicate this result to the Sender Application.

At first, you might think to develop your Proxy over HTTP (using the HTTP Connector). This connector creates a web service endpoint (a website, basically) that can listen and respond to requests.

  1. The Sender Application connect to this endpoint over HTTP and submits the JSON document containing the commands to be executed.

  2. Your proxy then immediately contact the Device Controller (again, over HTTP using the same connector).

  3. The device controller talks to the devices, and then returns the response to your Proxy (over HTTP).

  4. You take this response and then send it back as the response to the original HTTP request (from the Sender Application).

The problem here is if there is any delay between your connection and the Device Controller (or the Device Controller and the physical devices), the connection will remain blocked on both sides (since you need to send a response).

If there is a large delay the HTTP connection between your Proxy and Sender Application may terminate.

This is the same when some site is overloaded and doesn't respond - eventually the browser will timeout.

To avoid this scenario, split your integration into three separate flows.

  1. The first flow will create a normal HTTP connection to which the Sender Application will upload the JSON document. It will take the JSON document and convert each entry into a message using the batch module (note: this is only available in the Enterprise edition - for the CE version you'll have to code this logic yourself). Next, take this message and put them in a separate queue. Return the unique ID of this message as a JSON response back to the Sender Application.

  2. Your second flow is listening on this queue and whenever a message arrives, it connects to the Device Controller and gets the response. The response is then written to another queue.

  3. Your third and final flow listens on this results queue, takes each message on this queue and converts it to JSON/XML. It then has a HTTP connector where it can be queried for results for each command.

In the above setup, your Sender Application can drop a large JSON file of commands to be executed; for each command, a unique ID will be returned to the Sender Application.

It will then query the result endpoint (what your last flow exposes) and send it the message ID. The result endpoint will then check the status of this request and respond with the appropriate code.

Here is an example of how this would work (from the point of view of the Sender Application):

I is the input to your flow, O is the result sent.

Step 1 - send a request for commands to be executed:

I: Sender Application > http://localhost:8080/input-commands?device=1&command=Y
O: <command><req-status>OK</req-status><id>1234-123</id></command>

Step 2 - Query results:

I: Sender Application > http://localhost:8080/result?id=1234-123
O: <command><id>1234-123</id><result>0</result></command>

Upvotes: 1

Related Questions