We are on IS 9.5 and i am trying to implement Exactly Once Processing. In publishable document, i am setting trackId as a combination of order # and order type which is unique expecting that IS will use it as UUID. But when i see messages in q, i see all messages have different UUID even though i am submiting the same document twice.
On trigger side, Detect duplicates=True, Use History=True, History time to live= 2 hrs & Document resolver service=.
Since UUID is different for all document, trigger is not able to detect duplicates. Am i doing anything wrong here?
Hi AP,
In order to catch duplicates, we can enable ‘Exactly once processing’. Once you enable this exactly once processing, there are two ways to verify duplicates
Using document history - this comes out of the box, wherein the uuid of messages will be verified if they were processed before or not… these are technical duplicates… functional duplicates cannot be caught using this approach 2. Using document resolver service - you need to write some logic inside this service to identify whether the message was processed before or new message (by checking your backend system or cache or something)… using this you can avoid functional duplicates…
You can use both the options together as well, wherein the first technical duplicates will be detected by Document history table, and then followed by functional duplicates that will be detected by Document Resolver service… Both can be used together or individually.
In Publish-Subscribe Developer’s Guide 9.5 Page number 75 mentioned that
Integration Server automatically assigns a UUID to all the documents that it publishes.
I want clarify you why your method of UUID=trackID is not working .This method is only for 6.0.1
the 6.0.1 version of Integration Server does not assign a UUID when publishing a document
Integration Server requires the UUID to create and find entries in the document history database. Therefore, if the server receives a document that does not have a UUID, it creates a UUID using one of the following values from the document envelope:
1.If the trackID field contains a value, the server uses the trackID value as the UUID.
2.If the trackID field is empty, the server uses the eventID as the UUID.
The maximum length of the UUID field is 96 characters. If the trackID (or eventID) is greater than 96 characters, the server does not assign a UUID and cannot conclusively determine the document’s status. If specified, integration Server executes the document resolver service to determine the document’s status. Otherwise, Integration Server logs the document as In Doubt.
It seems your implementation is not correct. Maintain proper UUID and document resolver service which checks coming document UUID not exist in DB before processing it. Kindly share your code to correct or comment.