All,
For anyone who is using the Task Flow engine in Change Management in more
than a trivial way, you may have encountered bugs that prevent a built flow
from behaving as expected.  We did.  After several unhelpful and
time-wasting discussions with BMC support, we tracked-down and fixed a
handful of bugs in the Task Flow engine.

Context: ITSM 7.0.03, patch 008.

Hoping this may be useful to others, here are the corrections that we made
and why.

1.  Filter "TMS:TAS:Bypassed_MarkFlowTo_NotFollowed"
The If Action - Push Fields was setting the Flow Status to "Flow Followed"
rather than "Flow Not Followed" as its name says.  This was causing a flow
that should be bypassed appear as if it was still active.  The correction
was to modify the Push Fields to set Status = “Flow Not Followed”
==> This was the principle bug we found.  Fixing this caused the bypass of
Task Groups to function properly.

2.  Filter "TMS:FLW:Bypassed_TaskEvaluate`!"
The Run If qualification was looking for Status = "Flow Followed" to check
for bypassed rather than "Flow Not Followed".  No doubt this bug was hidden
because of the first one above (or created because the first one could not
be found.)  The correction was to change the Run If condition to check for
Status = "Flow Not Followed".

3.  Filter "TMS:TGR:Bypassed`!"
This filter was not properly setting the DO variable "zTmpInternal" when a
Task Group within another Task Group was being bypassed.  When this happened
the change of Status to "Bypassed" was being interpreted as a user input
change which caused the filter "TMS:SHR:Inactive_StatusLock" to generate an
error.  This caused all pending flow updates to roll back leaving the flow
unusable.  The correction was to add  zTmpInternal = "Yes" to the third Push
Fields If Action.

4.  Filter "TMS:FLW:CheckForOtherFailedFlows"
I consider this a defect.  In a merged flow (i.e., a Task with multiple
input flows) if ANY input flow was bypassed, this filter caused the task and
all downstream flows to also be bypassed.  This is not the behavior I
expect.  When I have Flow To Successor when = "All Complete" (in the flow
definition) I consider a bypassed input flow to be a completed flow.
Therefore if any input is closed normally, then the multiple-input task
should be activated normally.  The multiple-input task should only be
bypassed if ALL inputs are bypassed.  This is important because using "Any
Complete" in the flow is not an adequate solution.  I want the multi-input
task to activate only when all inputs are completed or bypassed.  Setting
the flow to "Any Complete" would allow the task to fire prematurely.  The
correction was to DISABLE the filter.

5.  Filter "TMS:SHR:varSetNameAsSourceForLabel".  Despite what its help text
says, this was only setting the source field for a data label if the data
variable was an OUTPUT.  We need the labels to be set when they are INPUT as
well.  My correction was to copy the filter and add the opposite condition,
in this case ('zTmpVariableID' != $NULL)

I hope this saves someone some time and pain.

Regards,
Chuck Baldi

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Reply via email to