Hi,

We are currently trying to implement a mechanism in which we would like to use a trigger with join condition as a queueing mechanism. We plan to publish on the broker several documents of the same type, with the same ActivationID, and “consume” them one by one by publishing their matching documents.

Example:
We publish on the broker documentA with ActivationID=1, then publish another documentA with the same ActivationID. Afterwards we publish a documentB with ActivationID=1, which fires our trigger. We are expecting to be able to fire the second time our trigger by publishing another documentB with the same ActivationID, but this is not happening. It seems that the broker (Join Manager) does not store the second documentA.

Did we miss any configuration or this is a webMethods/Broker limitation?

Thank you and best regards,
Nimenand23

Hi,

which wM Version are you using?
which Broker version are you using?
Or will it be Universal Messaging?

Is there anything in the server log or error log of IntegrationServer related to this?
Most likely you are hitting some sort of “unique key violation” from the ISInternal database as the Join Manager stores its information there.

I think that the problem is that both documentA have the same activationId.
When the activationId differs this should be working.

Please have a look at the Publish_Subscribe_Developers Guide.
It might contain helpful information.

Regards,
Holger

Hi Holger,

We are using webMethods 8.2 with Broker. We are currently trying this approach with the same ActivationID because we would like to use it as customer identification ID in our flow.

We read the chapter from the Publish_Subscribe_Developers guide dedicated to the Join Triggers but we did not find any limitation regarding using the same ActivationID. So our guess was that we can publish multiple docs with the same ActivationID and consume them one by one by publishing their matching document.

Anyhow it seems that there is a restriction in place. We got this error in the server log:
Received Duplicate Document of type:MTanase.Test.dublePublish:doc1 for activation key: MTanase.Test.dublePublish:myTrigger:wm68

is there a way to bypass the duplicate check?

I dont think so.

As the combination of DocTypeName and activation id will be used as the unique identifier for the IS_TRIGGER_DOC table.

So when might be a possibility to bypass the duplicate check in the API you will hit the “Primary Key Violation” in the database.
JoinManger uses this information to identify the document and wont be able to do so when there will be a possibility for duplicates.

Can you try to find another value for the activationId?

As soon as the first documentA(activation1) has been resolved with a corresponding documentB it is possible to publish a second documentA(activation1) for the next round.

Regards,
HoLger

Hi Holger,

Let’s say we have two systems: A and B
B publishes more documents on the broker which have as identifier a customer ID. It could be possible that one or more documents from the broker queue are relevant for the same customer depending on their type.
A calls a webService and publishes another document type on the broker which has as identifier the customerID and expects to retrieve a document relevant to him (it does not matter what type it is it just has to have the same customer ID identifier). When a match is found based on the customer ID the trigger service is fired which sends back a relevant document to A. If A calls the webService again and there is another document available for him on the broker then it does the same thing.
We are trying to avoid to use 3rdParty systems in this implementation.
Is it possible to join two documents based on another custom condition beside activationID?

Hi,

can you try to use subscription filters with one field from the payload instead of the envelope?

When using processes you can have the first document start the process waiting for the second one.
The second documetn will then join the waiting process by using a correlation.

See Process Development Help for details about this.

Regards,
Holger