nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Common Error Handling

JMcNeil

Hey guys, we're looking to do some common error handling in an upcoming project. Essentially our workflow will consist of a number of external tasks which will be calling CLTs such as checksums, virus scans, unpacking tools, etc. Should one of these commands fail, and return a non-zero return code we'd like to notify and admin, and have them press a 'Retry' button in a usertask when they feel the problem may have been fixed.

So what I'm thinking is of two ways to do this. One is to have a notify and usertask associated with each external task. This makes it simple from a flow perspective as it should be all simple transitions.

(Retry 1,2,3 transitino back to tool 1,2,3)

Tool1 ---Pass--> Tool2 --Pass--> Tool3 -->etc.
|.......................|......................|
Fail....................Fail...................Fail
|.......................|......................|
V......................V.....................V
Notify1->retry1....Notify2->retry2....Notify3->Retry3

The problem with this is that for each task we add, we need (at least) two helper tasks. Also if we want to change the error handling procedure, we'll need to change it in many places. (Not necessarily if we make a robust task, but if we would like to add more tasks to the common error handling flow)

The second way we're thinking is to have three common error tasks. When a tool fails, the external task will set a job variable with its job name. It will then transition to a Notify Task, which goes to a usertask and waits for an admin to press retry. Once the admin presses retry that usertask will transition to an external task, which will grab the job variable set earlier and transition back to the task of that value using the TeamSite::CGI_lite::iwcallback() function (which as I understand it will transition to a task based on its name/description).

So I guess I'm looking for input on which method is better, I'm also using the Modeller so a drawback to the second method is a spider web of links going everywhere, where I can group and minimize the tasks in the first method, which would keep the flow a little more viewable. Also how have others deon this in the past, I'm sure it's a fairly common thing.

Find more posts tagged with

Comments

Migrateduser

I tend to prefer the latter scenario -- common error tasks. It's much simpler and you can absolutely leverage job variables to have another helper task doing your routing for you. Besides, if you decide at a later time to add more logging information to your error task, you would need to change it in one place instead of many.

kaalraa

I also recommend the second option to be the better one as it has minimal number of tasks. One suggestion over there is to have your Admin Notify failure as Group task... so that it can be shared among a group. It should not be dependent upon a single user.

Migrateduser

One suggestion over there is to have your Admin Notify failure as Group task...

The "Notify" task, as I understand it, is an external task and just sends an email or whatnot. If that's the case, this can't be a group task -- nor should it be. Also, if the environment has only one admin then of course the subsequent usertask should remain a usertask.

Dave

JMcNeil

Thanks Dave and Kaalraa. For the notify task, we're probably going to just throw the error and some information in a database through an external task, and have our notification framework send out the actual email (TeamSite is only one part of our solution, and other servers will be sending notification as well).

The admin retry task could end up being a group task though, and that is actually a very good idea to make it so as it adds flexibility early on (if there's only one admin, thats ok, if more are added, still ok!)

kaalraa

The "Notify" task, as I understand it, is an external task and just sends an email or whatnot. If that's the case, this can't be a group task -- nor should it be. Also, if the environment has only one admin then of course the subsequent usertask should remain a usertask.

Dave

Thanks Dave for correcting my post as by the time i read it again, you have already qouted the wrong thing. I agree the notification is mostly used for mail and which is being done through external task.

Adam Stoller

As an addendum to what has already been posted - I suggest you ensure that the first transition for all those externaltasks (and/or cgitasks) - i.e. CallBack 0, be the transition to the error handler - it will make it easier to code the scripts to know that if they encounter an error that is the callback they should use - and it leaves you free to have as many "success" callbacks as you may need (e.g.: an externaltask script may perform multiple functions, any of which might lead to a decision to follow distinct paths of the process flow, and you can add additional paths as needed - without disrupting the error handling path)

You might also consider having a job variable for storing a detailed error message - so that when an error occurs, that job variable's information can be referenced (in email or just within the WF interface) to assist with debugging.

ISCBorisB

Once the admin presses retry that usertask will transition to an external task, which will grab the job variable set earlier and transition back to the task of that value using the TeamSite::CGI_lite::iwcallback() function (which as I understand it will transition to a task based on its name/description).

Yes, you can make that work. There are couple complications though.

You can not use CGI_lite::iwcallback method from external task (it uses a form normally posted to CGI Task, you won't have that in the External task).

So, you will have to use WFTask::CallBack method instead. Transition parameter is the ordinal number of your successor
in the successor set. What it means is that you will have to a)generate(or hardcode) all possible successors of the final
*error handling set* task and b) Determine proper transition number in the task itself using *callback variables* set by
previous tasks

JMcNeil

Thanks guys,

That really sucks about only being able to use the zero based index, I suppose I could increment a counter job variable for each successful task, so the transition task would be able to know which task had called it. What about the sub that returns all possible transitions, does it return which index you would transition to in order to get to that task?

And those are really good ideas Fish, thanks for the input on those!

Adam Stoller

Thanks guys,

That really sucks about only being able to use the zero based index, I suppose I could increment a counter job variable for each successful task, so the transition task would be able to know which task had called it. What about the sub that returns all possible transitions, does it return which index you would transition to in order to get to that task?

And those are really good ideas Fish, thanks for the input on those!

You could use a cgitask if you wanted - and then you'd be able to use TeamSite::CGI_lite::iwcallback() and pass in the description of the successor - you'd just need to write the cgitask so that it either never initializes a window, or it initializes a very small window and then closes it.

If you're doing this after a grouptask - you can use an iwat trigger to set the owner of the cgitask to the user who takes ownership of the grouptask -- through I believe Nipper found a bug with respect to this when using TS 6.7.1...

ISCBorisB

If you're doing this after a grouptask - you can use an iwat trigger to set the owner of the cgitask to the user who takes ownership of the grouptask -- through I believe Nipper found a bug with respect to this when using TS 6.7.1...

Nipper had a special case in that project, he was running 6.7.x on VMWare. That is not supported, see for example [thread=20023]here[/thread]

There is no need IMO to feign CGI Task in this case. I did similar things before simply by passing job variable
with the successor number that indicated *return ordinal* for the particular task that have called Error Routine.

That creates somewhat brittle WF structure in a sense that if you add a new task you have to remember to add it to
Error processing successors and set *return ordinal* accordingly. Other than that, it's Ok.

Adam Stoller

Nipper had a special case in that project, he was running 6.7.x on VMWare. That is not supported, see for example [thread=20023]here[/thread]

There is no need IMO to feign CGI Task in this case. I did similar things before simply by passing job variable
with the successor number that indicated *return ordinal* for the particular task that have called Error Routine.

That creates somewhat brittle WF structure in a sense that if you add a new task you have to remember to add it to
Error processing successors and set *return ordinal* accordingly. Other than that, it's Ok.

I agree that it can be done with an externaltask - I was simply saying that it could be done with a cgitask too if one were so inclined.

ISCBorisB

I agree that it can be done with an externaltask - I was simply saying that it could be done with a cgitask too if one were so inclined.

Previous Fish-Avatar was sooo much more charming

nipper

Previous Fish-Avatar was sooo much more charming

I think it needs to be bigger. :-)

JMcNeil

Well I'm thinking that at the end of every external task that completes successfully, I increment a job variable which is just an int which counts successful external tasks. If I reference this variable in my transition gateway task, I'll know that say 6 tasks have passed, and I'm at the failure point, so I must want to transition to the 7th successor.

This SHOULD allow me to put tasks in anywhere I need, so the workflow should still be fairly flexible

nipper

Well I'm thinking that at the end of every external task that completes successfully, I increment a job variable which is just an int which counts successful external tasks. If I reference this variable in my transition gateway task, I'll know that say 6 tasks have passed, and I'm at the failure point, so I must want to transition to the 7th successor.

This SHOULD allow me to put tasks in anywhere I need, so the workflow should still be fairly flexible

Will that work in a loop or tasks ? i.e. review -> reject -> author edit -> review etc ?

JMcNeil

Probably not too happily, does anyone know what the results of WFTask::GetPossibleTransitions() look like? Are they sorted in the same zero based index order?

Adam Stoller

Probably not too happily, does anyone know what the results of WFTask::GetPossibleTransitions() look like? Are they sorted in the same zero based index order?

Is that new in 6.7? (I don't have access to a 6.7x server right now - it doesn't appear to be in 6.5)

Previous Fish-Avatar was sooo much more charming

Sorry - but the other one wasn't really "mine" - this one is.

I think it needs to be bigger. :-)

Hey - it fits doesn't it? -- and I had to send it the devnet team in order to get it there - since there's no way to upload it - but that's another thread ...

nipper

Probably not too happily, does anyone know what the results of WFTask::GetPossibleTransitions() look like? Are they sorted in the same zero based index order?

Perldoc does not say they are sorted, just that you get the descriptions (Labels) of the possible successors. However reading through the Perl, it iterates through the array, which certainly APPEARS like it would be in the same zero based index order.

Yes Fish, that is from 6.7.1, so I guess it is new.

JMcNeil

Just to add a little closure on this topic and for anyone out there looking to do the same kind of thing with 6.7.1 here are some of my observations after testing this a little bit.

The first link you create out of a task in the Modeler is the 0th transition, the next link you create becomes the 1th transition, and so on. So that might work out if you never change your workflow, but as soon as you delete a link, or add a new one, or somehow change that rather hidden order, the jobspec that gets output to power your job changes in the same respect. Not so hot!

So to take out the ambiguity of this (since you don't write the wft/jobspec, it's hard to ensure you'll always know the zero based index) you should name all your transitions according to what they're doing (the name of the link defines the successorset description in the final jobspec). Then in your external task which has multiple links coming from it, use the GetPossibleTransitions() method.

Using this method will return a list of the descriptions of the possible successorsets (name of the links in Modeler) in the zero-based index order (yay!!!). So you can take that list, build a hash if you like such as:


my @transitions = $task->GetPossibleTransitions();
my %transitionHash;
my $counter=0;
foreach my $tran (@transitions) {
     $transitionHash{$tran}=$counter;
     $counter++;
}
$task->Callback($transitionHash{'Desired Successor Description'}, "Some Comment");

I haven't actually tried running that code, I just thought it up for this post, but that should pretty allow you to transition to the task of your choice without having to know the final jobspec output.

I think Smiley Happy