Query Rules vs a!queryEntity

RE: Query Rules vs a!queryEntity

judym598 — Fri, 24 Jul 2020 15:25:00 GMT

Got it now - that makes sense as far as the new Expression Rule wrapper. As to the data falloff - I've done that with some of our view definitions, but will definitely take another look. Thanks so much for your help!

RE: Query Rules vs a!queryEntity

Mike Schmitt — Fri, 24 Jul 2020 15:14:21 GMT

The reasoning behind expression rule wrappers around all legacy query rules is, basically, you could reduce your dependence on the legacy objects to nothing other than the expression rules calling them (instead of hardcoded into process models / process instances / forms / etc), in a manner that would basically allow you to quickly do 1:1 replacements of the QR call with its new Expression Rule wrapper, save and deploy. Then when you're ready to replace a particular QR or set of related QRs, you don't need to hunt down all old places that used it, or worry (as much) about whether you'll be breaking a running process instance.

For the "data falloff" I mentioned - if you have a view that scales up in size with the growth of production data, filtering (regardless of which query you use) won't help; even pulling back a single row directly from the database can grow super slow when a view is allowed to grow unbounded. The only thing that noticeably helps with this (in my experience, and as an admitted SQL novice) is filtering within the definition of the view itself - i.e. filtering out all deactivated entries, entries older than X rolling date, etc. This can make the difference between a view that's pulling back a million entries, versus a view that's pulling back 10,000 *relevant* entries.

RE: Query Rules vs a!queryEntity

judym598 — Fri, 24 Jul 2020 14:50:26 GMT

Thanks for your informative response! I only checked a couple instances and some are querying views and others, tables. Some tables contain a LOT of data - 2 million rows, in some cases, so changing those query rules should definitely make a difference. I'm not sure how to address ' whether a data fallout can be added' as you mentioned above. I thought we had that covered with the filters, but evidently with the old query rules - that won't help. Not sure how creating expression rule wrappers around the old QRs would help unless your thought here is to make those expression rules stand out as ones that need to be updated.

RE: Query Rules vs a!queryEntity

Mike Schmitt — Fri, 24 Jul 2020 14:35:25 GMT

In my old longtime project, we began implementaton after Temo was mainstream (thank goodness) but before either SAIL or queryEntity were commonly used (or even present). To wit, we ended up with over 500 legacy query rules in the system. Particularly difficult was that since query rules are not at all flexible, we ended up with dozens upon dozens of nearly identical query rules that differed just by one parameter or something else.

For yours that are timing out routinely - are they querying from views? The only time I've seen consistent in-process query timeout issues was queries which are pulling data back from complex views which look at ever-growing data. The solution to this is multi-pronged, including reassessing the view and its efficiency (and addressing whether a data falloff can be added, i.e. principal items in the view older than X years are no longer included, etc). Additionally, it could help to cherrypick which Query Rules you convert to Query Entities, and finetune those to query efficiently when possible (pulling back only selected columns, a constrained page size, etc).

A suggestion for your current approach: the transition from Query Rules to queryEntities can be eased by having the QRs abstracted behind an expression rule (where the expression rule has the same inputs as the QR, calls it, and returns the same output). The thinking here is, one of the issues we had on that project was legacy long-life process instances wherein certain breaking query rules were 'hardcoded' essentially. In a few places the original rules were wrapped in an expression rule anyway, and in those cases the internal logic of the expression rule could simply be swapped out with the new QE rule call. For other places, we had to phase out the QR calls while making sure to leave the legacy rules sitting around until legacy instances could complete.

So my current suggestion (if you feel it's needed) might be: for QRs where you don't yet have time to develop and test equivalent QE rules, create expression rule wrappers and use those to replace the QRs in all other locations of your processes/forms/etc. With this you could potentially reduce (or eliminate) the legacy instances relying directly on the legacy rules, and then you can take your time with replacing the internal logic of these with new QE logic.