Executing a destination more than once

[JonEBee]

MIrth 3.8.1, Linux (not sure about the version)

I have a destination set up as an HTTP Sender or Web Service Sender (the situation is the same for both) that calls an API and receives data back. In the response data is a signal that more data is available, which means that the API needs to be called again.

Is it possible to repeat a destination until the signal indicates that no more data is available? I assume that DestinationSet will play a part in the solution, but nothing is obvious to me at this point.

The only other option I can see is creating a Java version of the sender in a JS Writer.

Thanks.

[odoodo]

Does the target maybe provide parameters for paging? In this case, setting the page size high enough would allow you to read all data w/ 1 call.

Up to my knowledge there is no way of creating "Destination loops" w/ mirth. So your second thought is the way I also would go to accomplish this task - if really needed.

[tonygermano]

Does the data from each call get combined into a single response?

A JS Writer is probably the way to go, but you can route requests to a second mirth channel in a loop if you still want to use the HTTP Sender or Web Service Sender to make the actual API calls.

[JonEBee]

Yes, the data from each call is combined into a single response. The called API returns a finite number of results, with a signal to indicate if more results are available. The API being called is built in another channel, but I considered building a direct connection through Java code.

I did figure out that routeMessage() will also deliver a string value to the called channel and I know that the Channel Writer will also receive a response from the called channel, so how do I check for a response from within a JS Writer? That is the last question that I need to get answered.

Thanks in advance for your thoughts.

[pacmano1]

It would be interesting to just route back to yourself (the same channel).

So the source tab would just return some blob that you know was the "start" if it is a poll.
In your source transfomer you parse that or the JSON that came from the router.route back to your self.

I assume you collect whatever you need in the destination transformer of the http call of course.

[JonEBee]

That will require a $g variable as a temporary storage space for the incomplete data returned from the previous API call and the return connection information to the calling consumer (headers (?), remotePort, ssProtocol, remoteAddress), because a channel routing to itself creates new consumer identity information.

Should I include anything else from the Source map variables or anywhere else? This is a REST API.

@narupley, any insight into configuring a channel to call itself one or more times that would help? Thanks.

[pacmano1]

No, not really. It depends on a number factors. For example you can build the fields you need to persist in the response transformer of your destination and route back to yourself - your source needs to understand when it is polling or when it is accepting a message from itself. Also your token can be out of band - meaning stored in $g by some other channel that renews it before its expiration as per the vendor spec.

[tom08zehn]

Had a similar challenge. What I did:

• My channel processes "MASTER" and "SLAVE" messages
• The "MASTER" message is the inbound message from an external system and usually causes destinationSet.removeAll() in my source transformer code
• The "MASTER" message creates 1-n "SLAVE" messages that are sent to the same channel via router.routeMessageByChannelId(channelId, theMessage)
• "SLAVE" messages are then passed to the destination

In your case it could be even easier:

• initial inbound message ("MASTER") goes to destination
• destination response transformer checks the HTTP response
• if HTTP response contains the "signal" to call API again, then a "SLAVE" message is sent to the channel itself
• the "SLAVE" message can have the same design as the "MASTER" message, the only difference is the "thing" that tells the destination what to query from the API - or: you simply could store this "thing" in $gc (globalChannelMap = available to all messages in the channel) and keep the slave message clean and simple...

So the response transformer would create a loop as long as the HTTP response no more contains the "signal" to query again.