cancel
Showing results for 
Search instead for 
Did you mean: 

Standard Error Processing within Workflow

Former Member
0 Kudos

I am working on my first custom workflow so I am reletively inexperienced. Within one of the steps in my workflow, a method is called which executes the transaction FB02 to change vendor info. I would like to do some type of error processing logic in case it returns from the transaction with an error. (The actual transaction screen processing is hidden to the user.)

What is the standard for error processing within a workflow method? I was thinking about changing the status of the workflow to Error using SWW_WI_STATUS_CHANGE_NEW and then possibly creating an attachment describing the error. Suggestions for a better method?

If this is the best method, can someone give me directions on using SWW_WI_STATUS_CHANGE_NEW? There is no documentation for it in English. Is the id passed the workflow header id or the task id?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Mike,

Thanks for the help. This was huge! Neither the SAP workflow class nor the book I am referencing spend much time discussing exceptions. I have a couple more questions.

I created an exception (temporary error) for the docuement being locked by another user and added the appropriate EXIT_RETURN logic in the method. I noticed that when the exception occurs, the workitem status remains "in process". The book says that the number of retries and interval between retries is configurable. Where would I go to change that configuration?

Thanks again for the help.

Joanne Johnson

pokrakam
Active Contributor
0 Kudos

Hi Joanne,

Temporary errors are typically used for things such as a document that is currently locked by somebody else. the number of retries can be configured as part of the error monitoring job configuration - I don't have a system in front of me right now, but it is In the workflow menu under administration.

I don't usually have outcomes for temporary errors because I do not expect them to fail. The default of three times at twenty minute intervals is pretty reasonable , and I have very rarely had occasion to change it. On the very odd occasion where somebody does lock the document for over an hour, it is usually a simple matter for a workflow admin to just restart the workflow.

Most other types of errors should be set up as application errors, this will 'fail' straight away, giving you the opportunity to proceed down different branches of the workflow based on various conditions you can set in your code.

Hope that helps,

Mike

Former Member
0 Kudos

Hi Joanne/Mike

I am trying to use the EXIT_RETURN logic to re-run a background task if it fails but am having trouble getting the work item to reprocess, the workflow doesn't stop at all.

As far as I am aware by using the EXIT_RETURN function the workflow should go into a status of 'in process' and should wait at that failed step until the background job SWWERRE runs for the number of re-tries, if it has still failed after the total no of re-tries, then the work item will go down the exception branch.

My problem is that the work item is going down the exception branch immediately.

Firstly is my description above sound correct, and secondly do you have any example code.

Many thanks for your time.

Daniel

Answers (2)

Answers (2)

Former Member
0 Kudos

Mike,

What happens when a temporary error occurs and is re-tried? Does the method that the exception is tied to get re-executed from the top?

Thanks for your speedy responce. You've been a big help. The transaction for changing the config is SWEQADM_1.

Joanne

pokrakam
Active Contributor
0 Kudos

Hi Joanne,

Please always mention version - particularly with WF things have changed quite a bit over the versions.

I assume that by 'processing is hidden' you mean a BDC. This is also something which is slowly going the way of the dodo, for most things there are BAPIs or similar function modules - though I think vendors may still be lacking there.

Onto your real question: you should define one or more exceptions for your method - just use the exceptions button in the builder. In your code, use:

EXIT_RETURN <exception number> <param. 1> <p2> <p3> <p4>.

to raise an exception.

Each exception becomes an outcome in the WF builder. You can then activate the outcome and add further processing to go down that branch. If you leave the outcome inactive, the WF will go into error. This is generally a bad idea, the WF should handle most exceptions - this is what WF is all about: having different branches/processes depending on the result of a step.

Typically, if something fails you would e.g. send an online FB02-type task to a user for manual processing. Workflows in error should really only be for something unexpected or rare as a WF admin has to deal with those. They are not the right people to be dealing with problems relating to a vendor update.

Have fun with workflow.

Cheers,

Mike