jdafoe

Reset doesn't fully reset

Discussion created by jdafoe on Dec 4, 2012
Latest reply on Jan 8, 2013 by MaryGreening
Hello,

Just posting a problem that I encounter again and again. I have raised this issue with CA but they have responded that it is working as designed. I then proceeded to create an enhanacement request. Wanted to share this with everyone to hopefully hear your opinions on it and let CA know that a "fix" would really solve a lot of frustration...

The problem...
When operators are reset, they are NOT FULLY reset.

For example, when the assign user task operator is run, an operator dataset variable is created called TaskID, which is the ID of the task that is created. When you reset the assign user task operator (using reset operator or if the assign user task operator is in a loop), the taskID variable still exists and still contains the value from the first time it was run.

Why does this cause problems? Take the example process straight from CA's designer guide ( 4.0 SP1 Content Designer Reference on pg 380 ). This example process assigns a Form and simultaneously sends an email notification with a link to the IRF. Try putting that example in a loop and it will not work as designed. The reason is because the TaskID from the Assign User Task operator dataset retains it's first value the second time in the loop and consequently, the second email notification link is generated incorrectly (it sends out a link to the first IRF form which is now expired).

A bigger problem is when you design a process and test it to perfection and then take that process and use it as a subprocess in a larger process. You put the subprocess in a loop and, bang, your design doesn't work. That's because your logic didn't take the reset problem into account and therefore unexpected results occurred. You now have to go fix your original subprocess that you thought was tested to perfection and working as designed.

I have run into this problem again and again and it's really frustrating. I strongly believe this problem is the result of a a bad design. It forces users to have to constantly think hard about variables retaining old values and create workarounds for all of them. A task that is impossible to do flawlessly in all our processes. As a result, our processes don't function as designed

In other programming languages, they have the concept of scope and I compare this problem a lot to that, If you define a variable in a function, the next call to the function will not retain the old value. This scoping behavior is desired because it minimizes code bugs and flaws. If we want to retain the old value from a function variable, we consciously decide to define the variables outside the function as a global variable instead (or similar). Well the same idea should apply to PAM operators. That is, if we want to retain the values of operator dataset variables, then we would consciously copy them outside the operator and save them to another process variable. BUT the operator dataset variables SHOULD ALWAYS ALWAYS ALWAYS reset when we reset them or they are reset as a result of being in a loop. It should be as if the operator had never been called.

The only workaround I have found is to delete the undesired operator variables using deleteValueMapField() before the operator runs again. Not an ideal solution since I usually only discover the problem after the fact.

Does anyone else encouter this problem? And would you also like to see this fixed?

Thanks,

James

Outcomes