Hello Florin,<br><br>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. <br>
<br>I also like your suggestion of ending without raising an exception. I'll give it a try.<br><br>Jocelyn, <br><br>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.<br>
<br>Your point below:<br><br>2) If the task is a background task, the application should return a<br>
code indicating that there is an error and any details of the error as<br>
exporting parameters - you can then design your workflow flowchart to<br>
send a message to the user if that error occurs. You should do this<br>
instead of raising an exception - as you actually don't want the<br>
workflow to stop in the event of error.<br><br>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.<br>
<br>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.<br>
<br>Thanks again for both of your quick advice and again happy new year.<br><br>Regards,<br><br>Alex C<br><br><div class="gmail_quote">On Tue, Dec 30, 2008 at 5:53 AM, <span dir="ltr"><<a href="mailto:sap-wug-request@mit.edu" target="_blank">sap-wug-request@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 29 Dec 2008 21:12:29 +0100<br>
From: "Florin Wach (gmx)" <<a href="mailto:florin.wach@gmx.net" target="_blank">florin.wach@gmx.net</a>><br>
Subject: Re: Worklow using OO: Container values not set when temporary<br>
exceptionraised<br>
To: "SAP Workflow Users' Group" <<a href="mailto:sap-wug@mit.edu" target="_blank">sap-wug@mit.edu</a>><br>
Message-ID: <8854F1934681499F8DE8EAE37EC43FCB@SI.local><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hello Alex,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best wishes, Happy New Year,<br>
Florin<br>
----- Original Message -----<br>
From: Alex Flow<br>
To: <a href="mailto:sap-wug@mit.edu" target="_blank">sap-wug@mit.edu</a><br>
Sent: Monday, December 29, 2008 4:54 PM<br>
Subject: Worklow using OO: Container values not set when temporary exceptionraised<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
A simplified version of the code is just:<br>
<br>
ex_bapiret = lx_bapiret. " both are type bapiret2_tab and lx_bapiret has a single line in it<br>
raise exception type cx_bo_temporary.<br>
<br>
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.<br>
<br>
Thanks and have a good new year,<br>
<br>
-Alex<br>
<br>
<br>
<br>
</blockquote></div><br>