| Author |
Message
|
| anuppc |
 Posted: Wed Oct 05, 2005 3:00 am Post subject: Error handling in synch UPES call |
 |
|
Voyager
Joined: 22 Oct 2002
Posts: 93
Location: Montreal
|
Hi,
Can you point me to reference material or tell me how we can pass Activity Impl errors to MQWF?
What is best practices to handle errors?
If i send the reply message with _RC as 1 then the synchronous UPES activity would go to error state.
How does administrators handle such issues? Log files or error queues?
Is there a possibility pass the application level error either into a log or queue? If so how?
Can the error message contain Process ID so that Admin can correlate with the "In Error" process.
Regards
Anup
_________________
BlowFish |
|
| Back to top |
|
 |
| fidelio |
| Posted: Wed Oct 05, 2005 7:52 am Post subject: |
|
|
Apprentice
Joined: 14 Sep 2005
Posts: 45
Location: AttainBPM
|
What are you trying to accomplish? The ActivityImplInvokeError reply message should only be used for catastrophic failures within your UPES implementation. If you want to handle an anticipated error situation in your UPES implementation you should use the ActivityImplInvokeResponse message with error codes in the output data and use an exit condition or transition conditions in modeling to handle the error.
The only reason an activity should get set to InError state is if there is an MQ definition or service failure or like failure within your code. |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Oct 05, 2005 8:27 am Post subject: Re: Error handling in synch UPES call |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| anuppc wrote: |
Can you point me to reference material or tell me how we can pass Activity Impl errors to MQWF?
What is best practices to handle errors? |
You should definitely have a look at Chapter 34 in the V3.6 Programming Guide entitiled "Error Handling" if you are looking for doc on dealing with errors in UPES activities.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| anuppc |
| Posted: Wed Oct 05, 2005 8:38 am Post subject: |
|
|
Voyager
Joined: 22 Oct 2002
Posts: 93
Location: Montreal
|
Thanks Fidelio and JMac,
So if i use the "ActivityImplInvokeResponse" with _RC as 1 the activity would go into error state right?
and if i specify an reply2Q in the response message then MQWF will put the general error message into the reply2Q.
(I see this in the "ErrorHandling" chapter)
My question is i want to set in the ActivityImplInvokeResponse _RC=1 and also some error string saying the impl failed due to some condition (this is not part of fmcmretc.h - standard error messages but application level message)
For example.... the impl might have failed due to inadequate input data....
How do i set these application specific messages in the response and then allow mqwf to dump it in the reply2Q.
Regards
Anup
_________________
BlowFish |
|
| Back to top |
|
|
| fidelio |
| Posted: Wed Oct 05, 2005 3:56 pm Post subject: |
|
|
Apprentice
Joined: 14 Sep 2005
Posts: 45
Location: AttainBPM
|
The method I usually use with a UPES where I expect data errors is create a block with an exit condition. The block contains two steps, the UPES activity and a manual activity. I connect the two with a control connector with the transition condition _RC<>0. I make sure the the UPES activity output container has an area for a message as well. The manual task I assign to the user that is responsible for the process. If a data error occurs in the UPES implementation, I complete the activity successfully but with a non-zero return code. The manual step tells the user the error condition, and provides the user the opportunity to correct the data error. The user then can finish the task such that the block exit condition fails, so that the UPES is run with the modified data.
I find this manages data errors better because it allows the UPES step to run again with proper data. It is harder to re-run a step if it is in the InError state. |
|
| Back to top |
|
|
| hos |
| Posted: Wed Oct 05, 2005 11:53 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Hi,
you can use any valid MQWF return code values in your exception object (see chapter 33 in the Programming Guide).
The errorReason().messageText() method uses the MQWF message catalog to create the error message.
You can pick any suitable message that takes one or more parameters and provide the parameter values via the
<Parameter> tag (see e.g. chapter 34 The General Error Message). In
general you can use RC=1113 for UPES exception messages.
For instance your error message could look like this:
<ActImplCorrelID>RUEAAAABALQABwAAAAAAAAAAAAAAAgAAAAEAs0ABAAAAAAAAAAAAAAACQQA
AAAEAtAALAAAAAAAAAABF</ActImplCorrelID>
<Exception>
<Rc>1113</Rc>
<Parameters>
<Parameter>63399;F;BDW;Error Text;Error Detail</Parameter>
<Parameter> <null/> </Parameter>
</Parameters>
<MessageText></MessageText>
<Origin>F4W Upes Framework</Origin>
</Exception>
</ActivityImplInvokeResponse>
</WfMessage> |
|
| Back to top |
|
|
| anuppc |
| Posted: Tue Oct 11, 2005 6:50 am Post subject: |
|
|
Voyager
Joined: 22 Oct 2002
Posts: 93
Location: Montreal
|
fidelio and hos thanks for your inputs...
The response from fidelio made me think of corrective actions rather than a block.....
can't we re-issue a restart command on the activity that has gone to "in Error" state?
Where else would we use a restart (repair) command?
what are the general rules for restart of an activity?
would it send a new message for the upes activity?
Anup
_________________
BlowFish |
|
| Back to top |
|
|
| hos |
| Posted: Tue Oct 11, 2005 11:16 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Hi,
you certainly can restart an activity that is inError via the Resart() / ForceRestart() API. In addition you can provide a new input container and yes, the UPES message is sent again. Note that an automatic activity gets a workitem created once it has been in state inError.
The difference of having the activity in state inError vs. having a block exit condition that deals with the error is a question of your business logic. If you EXPECT certain errors in your bussiness flow you should model the error handling and also automatic recovery - if possible. However there is always the possibility of unexpected errors (queue manager down, queue full, etc.). These errors need to be 'repaired' before your process instance can continue its flow. This kind of errors should be handled manually by the Restart() 'repair' APIs. Note that you need administration rights to call the repair APIs. |
|
| Back to top |
|
|
| fidelio |
| Posted: Wed Oct 12, 2005 6:13 am Post subject: |
|
|
Apprentice
Joined: 14 Sep 2005
Posts: 45
Location: AttainBPM
|
| anuppc wrote: |
fidelio and hos thanks for your inputs...
The response from fidelio made me think of corrective actions rather than a block..... |
Exactly...
| Quote: |
| can't we re-issue a restart command on the activity that has gone to "in Error" state? |
Yes, but the automatic activity becomes manual. In addition, you have to issue the re start API call via a program or via the webclient - the webclient force restart uses the default jsp to display activity information.
| Quote: |
| Where else would we use a restart (repair) command? |
The restart command is also useful for "hung" activities - where a UPES implementation has in some way crashed without responding to workflow and the ActivityInvoke message is lost.
In general, I find it best to reserve "InError" messages for system failures, and use process modeling to cover data or application errors. A UPES activity paired with a manual "exception" step allows you to have a user other than a workflow administrator manage the error. The work item can be transferred to another user if neccessary to solve the problem. If you are using the audit trail, then all of the activity will be recorded. |
|
| Back to top |
|
|
| anuppc |
| Posted: Sun Oct 16, 2005 5:46 am Post subject: |
|
|
Voyager
Joined: 22 Oct 2002
Posts: 93
Location: Montreal
|
Hi,
Thanks again for the clarifications...
How do i set the owner of the repair workitem? Can i do that in buildtime? or does it go to the process admin by default?
i know that we can set the staff defn for the upes activity, so the notion here is that we want to start the automatic activity on behalf of this staff. Does the error workitem come to the staff defined for the UPES?
Dont have mqwf installed box with me... so the question otherwise i could have tried this out.
_________________
BlowFish |
|
| Back to top |
|
|
| jmac |
| Posted: Sun Oct 16, 2005 6:01 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| anuppc wrote: |
How do i set the owner of the repair workitem? Can i do that in buildtime? or does it go to the process admin by default?
i know that we can set the staff defn for the upes activity, so the notion here is that we want to start the automatic activity on behalf of this staff.
Does the error workitem come to the staff defined for the UPES? |
You have answered your own question  . When the work item is created at the time the Upes activity goes "InError" MQWF will use the staff member that you assigned to run the UPES and will create the workitem for that user. I assume that since you are a good MQWF citizen, you have that workitem assigned to a single user maybe the Process Administrator or maybe a "UPES_RUNNER".
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
|
|
