[LIKELY JUNK]Re: Worklow using OO: Container values not set when temporaryexceptionraised

[Dart, Jocelyn]

Hi Alex, 
It's possible to pass information into the exception class.  I have in
the past used this to put more details into the workflow log - you may
also be able to use this to write your own log, but I haven't explored
this myself.  
 
You need to create your own sub class of either CX_BO_TEMPORARY,
CX_BO_SYSTEM or CX_BO_APPLICATION depending on the type of error
response you want the workflow to take.  If you then create additional
attributes of your sub class, you will find the RAISE EXCEPTION
statement will automatically allow you to pass values to these
attributes (use the ABAP "pattern" feature as usual to help create the
raise exception statement). 
 
It is NOT however appropriate to use an exception to update the workflow
container - this would be contrary to good OO and workflow design and is
not permitted. 
 
If you need a message to be returned immediately to the user then you
have a number of strategies available:
1) If the task is a dialog task the application you are calling should
return a message to the user directly. You will need your task to be
either asynchronous or use a completion condition to check whether the
step has been completed correctly.
 
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. 
 
 
Hope that helps.
Regards,
Jocelyn 
 
 
 

________________________________

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Florin Wach (gmx)
Sent: Tuesday, 30 December 2008 7:12 AM
To: SAP Workflow Users' Group
Subject: [LIKELY JUNK]Re: Worklow using OO: Container values not set
when temporaryexceptionraised


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 <mailto:workflow at heidiandalex.com>  
	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/20090106/f98b8083/attachment.htm