How do you check if a variable which only exists at runtime but only in certain contexts (i.e. if called from a record view it'll not be there but from a task it will) exists?
What I'm trying to do is find out where an expression rule is being used at runtime and logging that information for us to help diagnose a performance issue. These expression rules are used in hundreds of places across the application so it's not feasible to try and diagnose that way. We want to be able to see where the rule was called from, i.e. process node, interface, record list, record view, task... We've settled on checking the existence of pp!id / tp!id / rf!id to get information about where it came from and then query the analytics with that to identify the chain all the way back up to identify how it was executed. However, if you query these variables in the wrong context (e.g. pp!id when the rule is used in a record view), it errors out as the variable doesn't exist at runtime.
Any ideas?
Thanks in advance,
Caz
Discussion posts and replies are publicly visible
As far as I know, checking a variable's existence at runtime is not possible in Appian. This would require try/catch type functionality which is currently not available. There is an undocumented try() function but it is not recommended to use (could be removed at any time) and will not work for this scenario anyway - returns the same error if a variable is not available.
Note the Admin Console Rule Performance area may assist with narrowing down time frames of longer executions to map to other process/task reports, and/or verifying there is not a surrounding issue. Other than what you are doing already, I would suggest applying many different rule test cases.
Can you elaborate a little bit on what the connection is between the expression rule and the performance issue?
This seems to work:
try( eval("pp!id"), null )
neither try() nor eval() are officially supported and could be withdrawn at any point in time.
Hello,
It sounds like you have an issue with an expression and you are trying to narrow down the locations it is called to find the bug. You talk about using the information of process Id, Task Id, or Record Id to determine the location of the bugged instance.
In my head this would only work if you had already created a parameter and in all locations passed in the value to the expression. But I doubt you did because you mention that the expression is used in hundreds of places.
There exists a couple of different ways to go about finding the bug.
If the bug caused an error on the interface (pink screen) I would head over to the design log.
If the bug is erroring out in a process model look in monitoring for the models that have alerts.
Like others have said you could use undocumented functions of try catch, but I would highly discourage that.
You say that the issue is a performance issue. Can we know a little bit more of what it is doing. Is it a Query, Formatter, is it doing some kind of math?
One little trick I have picked up is that you can use the API object to point back to your own enviroment and kick off process models whenever expressions are called. This little trick could open up the chance for you to kick off a process model that write to the DB any time the expression is called. With that you may be able to send into the model things like the logged in user, a date time, and any other information about the expression to help you diagnose.
Just be careful because if you have a performance issue this is only going to make it worse while your diagnosing.
To my mind the try() and eval() functions should be avoided at all costs IN PRODUCTION. There's nothing, I would think, to keep you from using them while they are available to diagnose an issue, to use exclusively for debug purposes. You may want to consider leaving your debug code out of production builds, because again those rules could change or be removed at any time, but if it doesn't effect outward user-facing functionality, then it won't break your application when those rules DO change or go bye-bye.
One has to wonder why these undocumented functions exist and continue to exist if not to be used at least in some capacity. Creating a rule that you intend to mothball when you're done using it sounds like a perfect use case.
Do you need to see if the var exists or if the data is set? If its just to see if data exists, then you can do an isnull or if you have access to the Appian PS toolkit, rule!APN_isEmpty() or rule!APN_isBlank().
Is there a better alternative available?