Pete Wirfs

V9 management of runtime variables

Discussion created by Pete Wirfs on Sep 19, 2013
Latest reply on Sep 20, 2013 by Pete Wirfs
We are in the middle of migrating from V6 to V9. V10 was released after we started.  Within V9 we are still trying to figure out what are the best practices for managing variable input data.  We decided we prefer to utilize Promptsets which is going well.  However we have had cases where we receive a request to alter a parameter or variable value, we alter the value in the workflow or the job that uses that value, and the next time it executes it runs with the old value instead of the new value (not good!)   This experience led me to discover that sometimes the parent object will override the values even though we didn't ask it to do so, and this causes us to have to also change the values in the parent. In our most recent experience with this problem we were asked to change a filename in an RA FTP object that transfers data to a bank; our operations staff changed the filename within the FTP object, but the workflow overrode the value and caused us to transfer the stale filename, and resulted in our submission of duplicate transactions. So what are the best practices here?  Should we always be maintaining all of our variable input data and parameters at the parent level?   If the answer is YES, wouldn't this suggest the need for constant dual maintenance if you don't want to leave inaccurate values in the child objects? What I WISH would happen, is that UC4 would be smart enough to detect when a variable data override matches the value that it is overriding, and when they match, do not store it as an override.  When they match, a visual inspection will not tell you if it is stored as an override or not.  I've been running custom SQLI statements to determine whether or not an override is stored against an object. Pete