Worklow using OO: Container values not set when temporary exceptionraised

[Florin Wach (gmx)]

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



------------------------------------------------------------------------------


  _______________________________________________
  SAP-WUG mailing list
  SAP-WUG at mit.edu
  http://mailman.mit.edu/mailman/listinfo/sap-wug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081229/0b0a0480/attachment.htm