<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Mike P,<BR>
<BR>
Don't you find it strange though that the new OO Workflow stuff never went as far as creating proper OO Exception instances to work with? I do...<BR>
<BR>
To my mind Workflow lacks something here that SOA has been forced to tackle, namely the OO encapsulation of an exception as a runtime instance. <BR>
<BR>
For our PI stuff that means working with Sub-Types of SAP Standard Class CX_ROOT.<BR>
<BR>
I know that's moving a little off-topic here on this particular thread and doesn't solve Robert's original question (sorry Robert!) but it does strike me as odd that Workflow has dodged dealing with Exceptions in a proper 'OO way'<BR>
<BR>
Regards,<BR>
<BR>
Mike GT<BR>
<BR>> Date: Thu, 20 May 2010 14:17:31 +0100<BR>> Subject: Re: exception in class and passing of parameters<BR>> From: wug@workflowconnections.com<BR>> To: sap-wug@mit.edu<BR>> <BR>> Hi,<BR>> <BR>> Mike's suspicions are entirely correct: The WF engine picks up that an<BR>> exception has occurred and doen't bother binding anything back.<BR>> <BR>> My take on SAP's design is that an exception is an error condition, which <BR>> invalidates return values. A 'business exception' should thus be modeled<BR>> with a return value that gets checked later.<BR>> <BR>> Regarding return parameters in BOR, I've never liked them and almost<BR>> always gotten by without them in the BOR world. In some cases it's a minor<BR>> inconvenience compared to BOR of having to check a parameter in a separate<BR>> condition; but in other cases (if the step is simple and doesn't modify<BR>> any data) it actually simplifies things because you can even skip the step<BR>> completely and plug a functional method straight into a condition.<BR>> <BR>> Cheers,<BR>> Mike<BR>> <BR>> On Thu, May 20, 2010 10:32 am, Robert van den Berg wrote:<BR>> ><BR>> > Hi all,<BR>> > <BR>> > I discovered where the evil is. In the old situation with BOR objects,<BR>> > the method has a return parameter (setting on the method). So the<BR>> > 'exceptions' are not exceptions but return values.<BR>> > <BR>> > Is there a possibility to use this with a Class method?<BR>> > <BR>> > Best regards,<BR>> > Robert<BR>> > On May 20, 2010 10:58 "Robert van den Berg" <wug@bergtop-ict.nl>wrote:<BR>> >> Mike,<BR>> >> <BR>> >> it does not realy need a statement to pass the value, does it?<BR>> >> <BR>> >> The export parameter is set by the normal ABAP statement:<BR>> >> APPEND ls_amr TO amr_reject.<BR>> >> AMR_REJECT is set as exporting parameter.<BR>> >> <BR>> >> Regards,<BR>> >> Robert<BR>> >> On May 20, 2010 10:48 "Mike Gambier" <madgambler@hotmail.com>wrote:<BR>> >> > Jocelyn,<BR>> >> > <BR>> >> > I'm not sure that's entirely accurate anymore. ABAP was adjusted<BR>> >> > some time ago to return EXPORTING, TABLES and CHANGING parameters in<BR>> >> > FMs or ABAP Class Methods even if you raise an exception.<BR>> >> > <BR>> >> > We have several examples of where an Exception is thrown and we can<BR>> >> > still trust the value of an Exporting 'Error' flag or Application<BR>> >> > Log instance as well.<BR>> >> > <BR>> >> > The flaw highlighted by Robert I think is buried in the way the<BR>> >> > value being received is being bound (or not) into the Method<BR>> >> > container.<BR>> >> > <BR>> >> > Mike GT<BR>> >> > <BR>> >> > From: jocelyn.dart@sap.com<BR>> >> > To: sap-wug@mit.edu<BR>> >> > Date: Thu, 20 May 2010 10:30:07 +0200<BR>> >> > Subject: RE: exception in class and passing of parameters<BR>> >> > Hi Robert,<BR>> >> > <BR>> >> > If you raise an exception, the exporting parameters are NOT returned<BR>> >> > to the calling application (not just workflow – all calling<BR>> >> > applications) – exact same behaviour as function modules. The<BR>> >> test<BR>> >> > tool “cheats” a little. <BR>> >> > <BR>> >> > So for a synchronous task either use an additional exporting<BR>> >> > parameter to indicate success/failure or use an exception class to<BR>> >> > update the workflow log with your returned value.<BR>> >> > Or raise an event (with or without parameters) – and make your task<BR>> >> > asynchronous.<BR>> >> > <BR>> >> > Regards,<BR>> >> > Jocelyn<BR>> >> > <BR>> >> > From:sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On<BR>> >> > Behalf OfRobert van den Berg<BR>> >> > Sent: Thursday, 20 May 2010 6:17 PM<BR>> >> > To: SAP Workflow Users' Group<BR>> >> > Subject: exception in class and passing of parameters<BR>> >> > <BR>> >> > Hi Group,<BR>> >> > <BR>> >> > I have a task which uses a method of a class. This method has export<BR>> >> > parameters and exceptions.<BR>> >> > Before the exception is raised, the export parameter is set.<BR>> >> > <BR>> >> > The problem is that, when the exception is raised, the export<BR>> >> > parameter is empty. When I test the method from the class builder,<BR>> >> > the export parameter contains a value but when I test the workflow,<BR>> >> > the workflow container is empty.<BR>> >> > <BR>> >> > Does anyone have an idea?<BR>> >> > <BR>> >> > Regards,<BR>> >> > Robert<BR>> >> > <BR>> >> > Get a free e-mail account with Hotmail. Sign-up now. <about:blank><BR>> > _______________________________________________<BR>> > SAP-WUG mailing list<BR>> > SAP-WUG@mit.edu<BR>> > http://mailman.mit.edu/mailman/listinfo/sap-wug<BR>> ><BR>> <BR>> <BR>> _______________________________________________<BR>> SAP-WUG mailing list<BR>> SAP-WUG@mit.edu<BR>> http://mailman.mit.edu/mailman/listinfo/sap-wug<BR> <br /><hr />Get a free e-mail account with Hotmail. Sign-up now. <a href='' target='_new'></a></body>
</html>