I have a simple test scenario I do not understand. I have a single publishable document defined in Integration Server where messaging is configured to use UM. I have defined a trigger using a “Provider Filter” (no client side filter).

1. If I publish a document satisfying the “Provider Filter”, the trigger service is executed as expected.
2. If I then publish a document that does not satisfy the “Provider Filter”, the trigger service is not executed as one would expect.
3. If at some point later I remove the “Provider Filter” from the trigger, the trigger service is executed receiving the document published in step 2 above.

For step 2 above - when the document was published and there were not any “interested” subscribers, I expected that the document would be “acknowledged” and no subsequent processing would be performed on the document. What am I not understanding?

Since there is no filter condition and if the trigger is registered with the publishable document which you are publishing it will invoke the service registered with trigger.

For your case, you can disable the trigger from the properties panel or from IS and you can see the trigger service will not be invoked and processed.

Thanks for the reply. Sorry, I still do not quite understand.

It appears to be the case that if the filter criteria is changed for a trigger, documents that were published prior to the filter criteria change that did not satisfy the criteria but now do satisfy the criteria will be processed by the trigger. It is a different behavior than what would be experienced using the Broker. To me it is analogous to initiating a magazine subscription and subsequently receiving “back” issues.

Hello,

The best way to change any trigger property would be to disable the trigger first( when you enable the trigger later, its regenerated with new attributes which you have set). The only constraint in doing so is the unprocessed messages are lost from the destination.

Regards
Sasa

Thanks for the suggestion.

I disabled the trigger. I then removed the Provider Filter and saved the trigger. I then enabled the trigger. The document published previously that did not satisfy the previous Provider Filter criteria was processed by the trigger (not a new document, a document that was published previously). Is this the expected behavior?

We’re running 9.7 IS and UM if that is a consideration…

I don’t think. If the published doc doesn’t satisfy the provider filter criteria how it gets processed by the trigger ?

Can you re-try again. Please share your IS & UM fix levels. If required we can report this to SAG.

Thanks,

The scenario is as follows (have re-tried multiple times with same result):

1. A trigger has been defined with a “Provider Filter” criteria specified.
2. Publish a document that does not satisfy the “Provider Filter” criteria. The associated trigger service is not executed.
3. Disable the trigger (e.g. set “Enabled” to “False”) and “save”.
4. Remove the “Provider Filter” criteria and “save”.
5. Enable the trigger (e.g. set “Enabled” to “True”) and “save”.
6. The document published in step 2 above is now processed by the service associated with the trigger.

IS: Version 9.7.0.0; Updates: IS_9.7_SPM_Fix1, IS_9.7_Core_Fix4, TNS_9.7_Fix2; Build Number 361

UM: Realm Server version = $Name: nirvana_9_7 $ - $Revision: 1.141 $
Build Number = Build 12911
Build Date = August 14 2014

Thanks for the assistance!

What is the “processing” property of the trigger set to? Is it “serial”? Then the behaviour might be as designed (but still very counter intuitive). If a document is published which no subsriber is interested in, the document is still held in the “document queue” in UM. And is only discarded after a (another) document is published which has an interested subscriber.

Try to change the setting to “concurrent” and report back your experience.

Thanks for the information regarding the “serial” setting.

The “Processing mode” is “concurrent” with “Max execution threads” of “1”. It has always been defined with these settings.