No condition matches in trigger

, ,
1

I am receiving the following error in the serverlog.

[ISS.0098.0061D] No condition matches in trigger package1.triggers:trigger1 for document
aa.bb:cc_Pub with activation wm123…

We have two Is in cluster with same packages and triggers deployed in both of them. Can you please let me know what the reason could be?

2

It looks like your publisable document dont have any subscription by any trigger??

  1. open your publishable document type and check the properties,
    what is the broker is document type name… Is that correct what you are subscribing… or broker document having any _1 or _2 like that???
3

I didn’t get the answer.

I checked the trigger condition. I don’t find anything wrong.

Will this be happening because there is something wrong with the publishable document or wrong with the trigger?

Can you be more specific of where to search and what to search?

4

Do you have any filter criteria on the trigger? Can you post the details of your trigger?

5

Trigger condition was having
%doc/Header/field%=“aa”.
If I convert this to lexical condition, may be this warning will go away.

Can you please confirm.

6

Having a condition will indeed cause the warning message you first reported. It’s saying “I received a subscribed event, but it doesn’t match any of your conditions.”

You can either convert to the lexical form (usually a good idea since the Broker will then do the filtering instead of IS) or just ignore the warning.

7

Hi Reamon,

In the document it has said both Broker and IS evaluate the document against the Subscription filter upon receiving the document.

or

only Broker evaluates the document and then places the dcoument in the subscribers client Queue if it matches the filter?

Is there will be any differences in evaluating the document when we use
Standard Relational Operators
or
Lexical Relational Operators.
as you said the Broker will do the filtering Instead of IS.

Thanks in Advance
Gouse.

8

The Broker and IS support different, but overlapping, filter syntax.

"Filters can be saved with the subscription on the Broker and with the trigger on the Integration Server. The location of the filter depends on the filter’s syntax, which is evaluated at design time.

…

If the Broker determines that the syntax is valid for the Broker, it saves the filter with the subscription. If…the sytax is not valid on the Broker…saved only on the Integration Server."

If the Broker can save and apply the filter, it will do so. In this case, IS will again filter the document, to invoke the right trigger service.

If the Broker cannot save the filter, IS will do all the filtering.

9

so it is good to use Lexical Operators were the Broker validates the documents there itself?

10

It depends. Generally speaking, filtering on the Broker is preferred since it reduces network traffic and hand-shaking between the Broker and clients. On the other hand, traffic volume and relative load on Broker vs. IS may point one to do filtering on IS.

If you have one Broker and one IS and traffic is relatively light to moderate, it likely doesn’t matter where the filtering is done.

11

Thanks Rob…