Can a non-Ensemble web service PULLs messages from Ensemble?

Hi Basem,

Yes, you can do that, but you need to make sure that you do not change anything in original Message Header. You should only use message header to retrieve message body.

Status, sessions etc are stored in message header, with message body class name and message body ID.

So in Ensemble, you can create a Webservices which will accept request. And request may contain message body class name, source and Target. Now you will query in Ens.MessageHeader with this params and get message body IDs, and you already know class name. From message body IDs you can get all the messages and can construct a response for your Webservice.

Your Vendor can call this Webservice, whenever he wants to PULL all the details of queued up messages.

I understand, a bit of coding involved doing this, but this how I think you can achieve the requirements.

Please let me know if you find any better way doing so.

Regards,

Sourabh

Hi Basem,

I think that you need to make sure that the overall setup here is as robust as possible. To help with that, I think you probably need some application-level tracking that ensures you know when the web service client has successfully retrieved messages. I say this because if the caller makes an API call, but crashes before it finishes processing the response we send, we can think we've sent the response, but the caller may not have processed it correctly.

At a basic level, I think it would make sense to have your Business Operation write to a new persistent class that looks something like the following:

/// Class to expose internal information about messages to an external caller.
Class My.WebService.Tracker Extends %Library.Persistent
{

/// Reference to the original Ensemble Message Header that the caller should be told about.
/// Note that this could also be the actual message, depending on how you want to track which messages have been fetched.
Property MessageHeader As Ens.MessageHeader [ Required ];

}

For each message you want to "queue" up for the caller, you'd create a new instance of this class, reference your message, and then save the value.

You can then write a fairly straightforward web service class that accepts a "Last Processed ID" value that allows the caller to request only new entries in the Tracker table, or even to request old ones to reprocess them. Your logic could simply query My_WebService.Tracker WHERE ID > ? when a last processed ID is supplied. You probably want to specify a maximum number of messages per response, and have some flag in the response to indicate whether more messages exist

The question of working out which messages have been processed gets slightly more complicated. You can track the last returned ID in your web service, though that gets tricky if you have multiple systems fetching from this queue. If you do have multiple systems, you'd need some way of tracking the status of each system. The complexity here really stems from your reporting needs.

As a final question, how important is it that you know when messages are actually received by the other system? If it's really important to see that within Ensemble, you may want to use the "Deferred Sending" mechanism in Ensemble, which is generally described here and specifically described for your business service here. You could store the token for each message in the Tracker table. (Note that using this approach could be tricky for effectively tracking the state for multiple other systems.) Be careful - this means that the original callers will wait until the message has been retrieved by the calling system, which could take a long time. This can lead to complex resource usage patterns in your production, so it may not be a good idea.