Using WM v6.0.1, does anyone know how to create an IS trigger with a condition, so that the condition is evaluated at the broker rather than at the IS – so broker does not send a document to a subscribing IS unless it meets the criteria defined in the trigger condition.
webMethods is currently saying that IS subscriptions with conditions can only be evaluated at the IS. That contradicts their own documentation (Building Integration Solutions Using Publication, pages 119-120).
Has anyone done this successfully?
We had the same issue. First thing is to be sure there are no errors validating the trigger ON THE BROKER. The Broker is apparently a bit more strict about certain conditional syntax than IS, so a condition may work on IS but not on the Broker. One of the more … subtle things we found in this category was that conditions on the Broker have to use lexical operators (EQUALS, LESS THAN, etc.), as opposed to symbols (=, <, etc.). HTH.
Can anyone give more details on this please? How is the passage from a IS to Broker filter controlled? Is this automatic?
I’m no pub/sub expert, so it’s probably best to consult the document Dave Matlock referenced above. However, I can tell you that when you create a trigger to subscribe to a document you have the option of specifying a filtering condition. This condition can specify any criteria you require to discern whether your subscribing service should process the document.
When a document is published by (one of your publishing services on) an IS, the Broker evaluates the triggers for that doctype to determine the list of subscribers for the document. The document is then placed in each subscriber’s (IS’s) queue. When the subscribing IS receives the document it also evaluates the triggers for the document to determine which service it should invoke.
If the trigger (optionally containing a filtering condition) is saved properly on the Broker, the document will only be placed in the appropriate IS’s queue(s). If the trigger doesn’t completely parse on the Broker, it may be saved without the filtering condition. In this case, the document will be placed on every IS’s queue and the condition will be evaluated by each IS. HTH.
Do you know how to verify if the filter is “properly saved on the broker”? My IS triggers with conditions saved with no error or warning. The criteria is very simple and matches the syntax we used in ES 5.0.1. However, I still get a bunch of “[ISS.0098.0061D] No condition matches in trigger …” messages in the IS server log. To me this means IS is doing the evaluation role…
What do you think?
I asked a colleague who’s done this before, and she says:
In the Broker Administrator, select your Broker Server and then Brokers->Clients (you should see a list of Triggers). Select the Trigger with the condition in it and then select Subscription. If the filter is being evaluated at the Broker it will be listed in the Filter column. HTH.
Thanks again Michael,
I found the column you mentioned. Unfortunately, after closely reading the pub/sub docs (again) I can’t seem to have that field populated for any of my triggers. Would you be able to get an example of syntax that works?
Sure, here’s one that works for us:
%Type% L_EQUALS “<some>”
This appears in the Filter of a Condition in one of our Triggers. The %Type% references a field in our Publishable Doctype, and of course I’ve left out the actual value to protect the innocent :-). Note that the lexical operator (L_EQUALS) is used here in order to ensure the filter is evaluated at the Broker. However, in the Broker Administrator this Filter shows up with a symbolic operator (==). There are of course, lexical equivalents for other symbolic operators as well. I believe they’re listed in an Appendix somewhere, but I could dig it up if you need it.
The lexical operators did the trick! They seem to be the only way to pass the filter to the broker from IS which is a little strange…
Thanks for all your help!
It starts to make SOME sense. To compare string types (which are the IS default) we must use the lexical operators (IS Developer Guide Appendix D) and for any strong typed values (int, bool, etc) we can then use regular operators.
Also, it does not seem that, and I think documentations mentions it, that the broker will not be able to evaluate array filters such as struct.value.
CAN ANYBODY TELL ME HOW THE DOCUMENT IS TRANSFERRED TO THE SUBSCRIBER(TRIGGER).i MEAN IF THE PUBLISH SERVICE SENDSA DOC TO BROKER THEN HOW THE SUBSCRIBER WORK ON THE DOCUMENT,HOW CAN HE REFER THE DOCUMENT OR THE SUBSCRIBER(TRIGGER SERVICE) HAS TO GET THE DOC AGAIN
Ashok subscriber works as listener for particular document type. If you use IS Doc triggers they use poling mechanizm that checks broker periodically if there are any documents to get. The interval can be set in Developer on trigger itself. If you use Broker API directly then its a callback set for Broker Event.
Hope this helps.
Does anyone know how to build a filter string that checks a field for a null value on the broker? “%field% = $null” and "!%field% are not allowed on the broker.
If you want to know more on the supported constructs of the filters in the broker, please look at Appendix D. of the ISDevelopers Guide (especially the last part)
i got the Publishable document and i need to specify the Filter condition , it the valied Filter condition
but its not working for me.I am checking particular field
(DetailTableName to be “PoInvoice” )
what is the right way ?
CAN ANYBODY TELL ME HOW THE DOCUMENT IS TRANSFERRED INTO THE DATABASE
BY USING TRIGGER IF WE ARE HAVING TWO DATABASES INSIDE
“HOW THE DOCUMENT IS TRANSFERRED INTO THE DATABASE”
Please elaborate more on the query what you are trying to do.
Anyways do you want to insert the document/data into DB?If so you need to use WmJDBCAdapter configure a JDBC Connection to DB and finally build a AdapterService using InsertSQL template and this will insert the data.
You can also acheive the same using WmDB (configure db alias)and using execSQL or insert service insert the document/data/fields to DB.