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.

@daniel-sanches-0, could you please include the complete XML output that you are seeing? (You may be able to exclude large, irrelevant portions of the content), but there may be relevant xmlns attributes higher up in the XML tree.

Also, how are you adding the signature to your XML and getting your XML content back out from the objects?