Hi,

Can you post a screen shot of how you set up the rules?

Remember the indentation can be used to group conditions.

For this one it should look something like this:

Folioname = 'PWF'

AND

    STATE= 'CA'

      OR

         STATE='TX'

             AND

         CITY = 'Dallas'

If you did not use the indentation in the rules then the result would be wrong.

Please show us your rule setup if the above is confusing.

Hopefully if you configure the indentation correctly the rule should work as expected.

Regards,

JohanL

I had a ticket with support but this probably applies to you.

At the moment, the WorklistCrtieria does not support this type of logic, see below:

The OpenWorklist method first filters all normal process fields (in SQL first - because it is available as separate SQL columns: like folio, StartDate, FinishDate etc.) and returns a result set, which then filters all the data/xml fields that are specified to the process instance. It has been done this way, because the data and/ xml fields are stored in binary archiveX encrypted packets and SQL isn't really sure how to decrypt that. In this case, if we filter on ProcessFullName (first filter from the SQL side to get specific process instances) and ProcessData (from the K2Server Side), the method will do a call to SQL with only the ProcessFullName filter parts in it... SQL will then return the results and these are the results that will then get filtered for ProcessData and ProcessXML on K2 server(s).

A working example as follows:
a. If you use ProcessFolio (SQL side) AND ProcessDate (from the K2Server side), it should work because the ProcessFolio will bring back the process with the filtered Folios and then continue to filter out the datafields (this will worked correctly)
b. BUT, ProcessFolio OR ProcessData will not work as expected because it brings back the Filtered Folios, but then the OR is useless because it does not have the other Processes without the Folio to check the datafields

So if you only do the Data/XML field filtering in 1 WorklistCriteria Object - it should work, but if you mix DataXML with normal Process fields, the logic does not work. This is something that has been logged by the Labs Support Team.

Currently there is not a fix for this issue as there are some HUGE changes in our current logic and possibly even our architecture, in order to fix this. This is also something that I will log as a known issue in our documentation.

The proposed work-around, is if you need to filter on data or xml - those values should be externalized to SmartBox or other SmartObjects - not workflow fields. This is because there will be a huge performance impact otherwise, and this is something we obviously would like to avoid. Since these are stored in encrypted packets, reading everything in and decrypting EACH WorklistItem in order just to inspect the value, will take its toll on performance.

Hello JohanL

I didnot get the "set up" rules part ? how do I set them up?

can you please eloborate?

Thank you

Hrishi

Hi Hrishi,

I think I misunderstood the question.

I thought you wanted to set up this logic in your workflow as a condition.

However, from the other responses I think you want to get all the instances matching this criteria using the API.

It might be that the WorklistCriteria does not support this, but please let us know if you are trying to do this using the API and let us know what you have tried so that we can clarify.

Kind Regards,

JohanL