Check if a variable which only exists at runtime but only in certain contexts exists

A Score Level 1

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

Parents
  • 0
    Certified Lead Developer

    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.

Reply
  • 0
    Certified Lead Developer

    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.

Children
No Data