exception in class and passing of parameters

[Mike Gambier]

Robert,

 

This may well be a buggy bit of Workflow OO binding from ABAP Class Method to Workflow Container and not actually to do with the 'old' habit that ABAP used to have of blatting parameters when an Exception was thrown, which is what I think Jocelyn is alluding to. (Correct me if I'm wrong Jocelyn)

 

A quick way to test would be to write yourself a noddy SE38 Program to invoke the same Method that the Task is invoking and debug it, or failing that test the Task directly for example in SWDD with a break-point in and see for yourself. You'll probably have to turn on system debugging to dip into the kernel though so it might be a bit of a mission :(

 

This may also depend on which flavour of the Workflow container you're using too. We've had mixed results when using the 'old' Persistence approach as opposed to the new XML one by the way and by mixed I mean inconclusive which has been a bit frustrating.

 

My suspicion is that the ABAP Class Method is returning the value but then subsequently the Workflow Engine could be ignoring the value and not bothering to bind it back to the Workflow Container, choosing to focus instead on the exception.

 

Mike GT
 


From: wug at bergtop-ict.nl
To: sap-wug at mit.edu; sap-wug at mit.edu
Subject: Re: RE: exception in class and passing of parameters
Date: Thu, 20 May 2010 10:58:14 +0200




Mike,

 

it does not realy need a statement to pass the value, does it?

 

The export parameter is set by the normal ABAP statement:

APPEND ls_amr TO amr_reject.

AMR_REJECT is set as exporting parameter.

 

Regards,

Robert



On May 20, 2010 10:48 "Mike Gambier" <madgambler at hotmail.com> wrote:

Jocelyn,
 
I'm not sure that's entirely accurate anymore. ABAP was adjusted some time ago to return EXPORTING, TABLES and CHANGING parameters in FMs or ABAP Class Methods even if you raise an exception.
 
We have several examples of where an Exception is thrown and we can still trust the value of an Exporting 'Error' flag or Application Log instance as well.
 
The flaw highlighted by Robert I think is buried in the way the value being received is being bound (or not) into the Method container.
 
Mike GT
 


From: jocelyn.dart at sap.com
To: sap-wug at mit.edu
Date: Thu, 20 May 2010 10:30:07 +0200
Subject: RE: exception in class and passing of parameters





Hi Robert, 
 
If you raise an exception, the exporting parameters are NOT returned to the calling application (not just workflow – all calling applications)  – exact same behaviour as function modules.  The test tool “cheats” a little.  
 
So for a synchronous task either use an additional exporting parameter to indicate success/failure or use an exception class to update the workflow log with your returned value.
Or raise an event (with or without parameters) – and make your task asynchronous. 
 
Regards,
Jocelyn 
 


From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Robert van den Berg 
Sent: Thursday, 20 May 2010 6:17 PM
To: SAP Workflow Users' Group
Subject: exception in class and passing of parameters
 Hi Group,
 
I have a task which uses a method of a class. This method has export parameters and exceptions.
Before the exception is raised, the export parameter is set.
 
The problem is that, when the exception is raised, the export parameter is empty. When I test the method from the class builder, the export parameter contains a value but when I test the workflow, the workflow container is empty.
 
Does anyone have an idea?
 
Regards,
Robert
 



Get a free e-mail account with Hotmail. Sign-up now.  		 	   		  
_________________________________________________________________
http://clk.atdmt.com/UKM/go/195013117/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20100520/93d4b401/attachment.htm