ARS: Intermediate: Writing Better Workflow Qualificaitons

Having an eye on query performance right from the first days of your programming is better. Practice good habits from day one! Thus, later you may not have to pay attention to assure that your code is not the reason for slow performance! I have seen fresh AR System developers writing Workflow without any Run If at all. I have seen them choosing more than necessary Execute On conditions to make sure that the Active Link or Filter will execute in all possible scenarios when they are not sure which conditions shall meet their purpose.

After visiting the production floor of one of the BPO customers in India back in 2007, I felt the 'crime' that a developer does while compromising on application performance is more humanitarian than technical. We spoke to the end users while my team was working on the performance tuning of the application. Most of the BPO agents were complaining that their Performance Appraisals are affected by application slowness. Another group complained that they are not meeting the criteria for performance incentives because the application eats their time. Another group said they started hating their job because their productive hours were spent waiting for the application to respond after every click. They all said one common concern, the application made all of them get lesser incentives, that is application eats all their money and job satisfaction.

Even experienced guys often forget to think about avoiding table scan while writing qualifications.

Some of those to avoid are…

The != Operator

Searches using the != operator check every record to see if the value is NOT contained. Indexes on a field are not used in this case. Searching by what you are looking for gives better performance that what you are not looking for.

Quoting the example given in BMCs documentation: you can rewrite the search qualification ’Status’ != "Closed" to 'Status' < "Closed" to improve the use of an index.

The != operator does not match entries in which the value for the field is NULL. You must explicitly include a test for NULL to find NULL values.

Wildcards in front of search terms

Searches that begin with a leading wildcard (for example, 'Submitter' LIKE

"%John%") does not use the index but scans the database for every record containing the word John. But the search searches with trailing wildcards are valid and use indexes. for example 'Submitter' LIKE “John%" utilizes the indexing.

Poorly written arithmetic operations

Try to use the indexed field on the left side of the equation,

as in the following qualification: 'Create Date' < $TIMESTAMP$ -60*60*24.

Avoid unqualified Run If statements for escalations.

An unqualified Run If statement for an escalation performs an unqualified query to the database table and execute the If actions for every request found in the form. Server performance is especially degraded for unqualified Run If statements in escalations that are set to run at frequent intervals, because the server must search the database every time the escalation is run.

Some of the other query optimization techniques are…

1) Creating effective indices

Index frequently searched(either workflow or by user) fields.

Tip: Too many indices may cause adverse effect hence do indexing with caution.

2) Setting QBE Match to equal or leading

Note: This is done from field properties, ‘QBE Match’ Drop Down

3) Optimizing Menus

Select Refresh ‘On Open’ only when absolutely necessary. Unless you anticipate the data to change so frequently, choose Refresh ‘On Connect’ (this option refreshes menu entries when the form is opened)

For more information, download the ‘Optimizing and Troubleshooting Guide’ from BMC.

I would still say, knowing the performance tuning tips are not compulsory for anyone to do coding in BMC Remedy AR System. But it is vital to be effective in their profession.

Be responsible, do it right!