Worklow using OO: Container values not set when temporary exception raised

[Alex C]

Hello Florin,

Thanks for the tip regarding the header for the retry count.  It seems it is
also in the work item instance (RetryCounterForWisWithError) so I can bind
it directly from the task to the method without having to first read it from
the SWWWIHEAD table or pass in the work item id.

I also like your suggestion of ending without raising an exception. I'll
give it a try.

Jocelyn,

Thank you as well for your advice here, especially the pattern regarding the
exception, for some reason I never thought to use that for raising
exceptions and that will be helpful.

Your point below:

2) If the task is a background task, the application should return a
code indicating that there is an error and any details of the error as
exporting parameters - you can then design your workflow flowchart to
send a message to the user if that error occurs.  You should do this
instead of raising an exception - as you actually don't want the
workflow to stop in the event of error.

is also very good.   I was trying to re-use the functionality from RSWWERE
to retry in the event of temporary errors.  The temporary errors work well
to cover things such as locked materials and then after retrying multiple
times raising a real error with the message to the user in the task.  I
would like to model a different outcome but with a temporary error I will
need to not raise an exception on the last try.

I will probably end up creating the exception that inherits from
CX_BO_TEMPORARY and add on a bit of information for the workflow log.  Since
it is not proper to send information directly via the exception I may try to
either write out the error message externally, or change the background task
to allow it to just return the error message without the exception.

Thanks again for both of your quick advice and again happy new year.

Regards,

Alex C

On Tue, Dec 30, 2008 at 5:53 AM, <sap-wug-request at mit.edu> wrote:

>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 29 Dec 2008 21:12:29 +0100
> From: "Florin Wach (gmx)" <florin.wach at gmx.net>
> Subject: Re: Worklow using OO: Container values not set when temporary
>        exceptionraised
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Message-ID: <8854F1934681499F8DE8EAE37EC43FCB at SI.local>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello Alex,
>
> it's a normal behaviour to have no dataflow on an exception, so it'll be
> rather difficult to pass any information with that exception. You may think
> of subtyping the exception class to fill your own exception-message (using
> msgv1, v2...) -- yes this will work. No, I don't know how to read this
> information from a completed work item, though you had to know the
> precessor.
>
> However I would recommend to continue using the RAISE EXCEPTION TYPE
> CX_BO_TEMPORARY and that you have your own exception handling with an
> exporting parameter ERROR_RESULT and the internal table of BAPIRET giving
> more detailed information. Before you raise the exception, you'll read your
> /own/ retry count of this work item (it's stored in the SWWWIHEAD table) and
> that you omit the RAISE statement and set the error flag instead, returning
> immediatly.
>
> Best wishes, Happy New Year,
>   Florin
>  ----- Original Message -----
>  From: Alex Flow
>  To: sap-wug at mit.edu
>  Sent: Monday, December 29, 2008 4:54 PM
>  Subject: Worklow using OO: Container values not set when temporary
> exceptionraised
>
>
>  I have a task that is supposed to return the error messages in the event
> of a failure.  I'm using temporary errors so that it will retry a couple of
> times before giving up.
>
>  When it fails I would like to know what that error message was and then
> send a mail to the user with details of the error.  The error step is
> modeled and I'm using a bapiret message to pass around the information.  The
> strange thing is that the return messages are never filled after the
> temporary exception is raised.
>
>  The problem is that it seems that after RAISE EXCEPTION TYPE
> cx_bo_temporary the return values aren't moved back to the container.  I
> know the container bindings are all ok because if I remove the raise
> exception everything proceeds as expected and the bapiret is filled.
>
>  I've tried checking through various oss notes and the sap help but no
> luck.  The background step is synchronous so I would expect that on
> completion OR temporary error the container is updated.
>
>  My question is: is this normal behaviour for no return parameters to be
> filled if there is a temporary exception?  i.e. is this a bug or a feature?
>  I don't remember if this is the same if done with the older business
> objects when an exception is raised.
>
>  A simplified version of the code is just:
>
>  ex_bapiret = lx_bapiret. " both are type bapiret2_tab and lx_bapiret has a
> single line in it
>  raise exception type cx_bo_temporary.
>
>  Otherwise does anyone know a good method to create a custom temporary
> message and use it to pass data to the next task?  I couldn't see a simple
> way to bind the results of a temporary error to the container values.
>
>  Thanks and have a good new year,
>
>  -Alex
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20090106/f487158c/attachment.htm