Join condition in Trigger

, , ,
1

Hi,
Two publishable documents are calling the same service. Then during subscription of this which doucment referece I have to use?.

Thanks in advance
Hari

2

If a Flow or java service is referenced in multiple triggers, you should specify both publishable document types as inputs. Only one of the document types will contain data.

I’d suggest starting your Flow with a branch statement that tests whether the first document is null and if so maps the second document to a new “internal” document that references the same document type structure. If the first document is not null ($default case) then map the first document type to an internal document.

Your Flow can then proceed using the internal document type. Renaming the publishable document type to an internal document type allows the major portion of your Flow service to reference a much shorter name. If both input documents share the same structure, then renaming also allows you to avoid having to duplicate code.

HTH,

Mark

3

Mark,

On the other hand how do I create a service to accept 2 documents as inputs and trigger the service only when 2 documents are received by the join manager. So far I can get this scenario working by doing the following steps

Subscribe side

  1. Create 2 documents docA, docB
  2. Create a service to process (ServiceX)
  3. Create a Trigger with docA and docB as input documents with join condition set to All(AND) and assign ServiceX as processing service.

Publishing side

  1. Generate a UNIQUIE ID (id1)for corelation
  2. Create a docA instance and assign the id1 to _env.activation
  3. publish docA
  4. Create docB instance and assign the id1 to _env.activation
  5. publish docB

But my question is can I get through this by not touching the _env document. Which means can I assign a custom filed for corelation. More over I remember there are some changes to the way broker works in the new realease with regards to activationID. Can some one explain what those changes are please.

Cheers,
Ram Challuri

4

I don’t think so!!

5

If both documents are published within the same top-level service, then you do not need to manually assign an activiation ID. IS automatically assigns the same activation ID to all docs published within a single top-level service.

May I ask the rationale for publishing two different docs and then processing them together on the subscribe side? Would one doc type be sufficient?

6

Hi,

pryWM - can you explain why you don’t think so.

Reamon - I agree with you that if we use the same toplevel service to publish 2 documents then IS is going to assign the same activationid. But what happens if the TOP level service is different. Now the answer to your next question is the same. What happens if I am expecting input from 2 departments for me to proceed with my service.

e.g. - in our environments we have morethen 25 production integration servers and every. We have atleast one for every department and all of them connected through wm brokers and gateways and teritories. It is very common for us to expect input from 2 different departments to perform a task.

Ram Challuri

7

For two published docs to meet the join criteria of a trigger, they must have the same activationId. If they do not, they will never be joined.

If you don’t publish the two documents within the same top level service, then you must set the activationId manually, and it must be the same in both published docs. This is described in the pub/sub guide. It still applies to IS 6.5.

So, if you’re using two different top level services to publish two documents, you must somehow set the activationId to be the same in both published documents. The best bet is to use something from the document data that is unique.

8

sorry for leaving a short and incomplete message in my last post.

I would go with the things explained by raemon.

9

Thanks for the clarification.

The other part of the question was, Can I use any part of the document as the activation id or I should only use the _env.activationID.

10

You can place any value you like into _env.activationID but whatever value you use, it must be placed into that field. Let me know if I misunderstood your question.

11

Reamon,
Thanks for your response.

I have been placing document specific ID’s {e.g. po#, invoice# etc} into _env.activationID. But my question was instead of using the activationID from _env, can I use any other variable from the document itself.

Cheers,
Ram Challuri

12

No. According to the documentation (you have read it, no?), only the _env.activationID is used to determine whether or not to join documents.

13

Hi Guys,

In this scenario i have a question too…according to the documentation, to enable the trigger check for duplicates the docuemnts should have the same uuid. I have tried setting up the same uuid’s and also setting up the trigger settings for duplicate verification. But webM internally assigns a uuid to the document published and hence am not able to chk for duplicates at the trigger level. Is there anything i am missing out here?

Rgds,
Pradeep

14

What IS considers a duplicate and what your process considers a duplicate is likely two different things. The UUID is used and tracked to prevent processing the exact same message more than once (to overcome network failures, etc.). If you’re trying to prevent processing the same invoice, or PO, or other document more than once, you’ll need to use some other mechanism to detect duplicates at this level.

15

Thanks Reamon.

16

Reamon,

Is there any way in which the dupliactes (in our sense like dupliate PO/SO) can be controlled at trigger level. The document resolver service can be used for the same purpose, but i was trying in a different way.
Instead of doing a pub.pub:publish i was trying to create a broker client using the broker API and set the UUID in it from the data and publish the event to broker. But i messed it up :slight_smile: at the end and i gave up that idea

Rgds,
Pradeep

17

The document resolver service would be a good way to go. You’ll need to have that service store and/or look-up an identifier (PO#, etc) to determine if it has a dupe.