exception in class and passing of parameters

[Mike Pokraka]

Hi Mike,

Yes and no. I far prefer the exception class concept over BOR. In some
ways I suspect it's deliberate design not to be able to pass error objects
back into WF (if I understand you correctly). i.e. handling exceptions
should be done in a BAPI-fashion. I agree that it's a bit limiting that it
doesn't work out the box to be able to see more info about the exception
object in the WF log, but a little once-off effort can solve that.

If you're talking about OO capability as being able to build a hierarchy
of exception classes with different functionality then we have some good
OO capability that I like to make full use of.

I suppose a workaround for handling exception objects later in the flow (I
am not sure off the top of my head what problems this would solve or what
benefit this would bring) would be to use a carrier pigeon object which
can take an exception as a parameter (coded inside the task method of
course) and be bound back into WF. I've never tried it but could be
feasible.

Cheers,
Mike


On Thu, May 20, 2010 2:53 pm, Mike Gambier wrote:
>
> Mike P,
>
>
>
> 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...
>
>
>
> 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.
>
>
>
> For our PI stuff that means working with Sub-Types of SAP Standard Class
> CX_ROOT.
>
>
>
> 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'
>
>
>
> Regards,
>
>
>
> Mike GT
>
>
>> Date: Thu, 20 May 2010 14:17:31 +0100
>> Subject: Re: exception in class and passing of parameters
>> From: wug at workflowconnections.com
>> To: sap-wug at mit.edu
>>
>> Hi,
>>
>> Mike's suspicions are entirely correct: The WF engine picks up that an
>> exception has occurred and doen't bother binding anything back.
>>
>> My take on SAP's design is that an exception is an error condition,
>> which
>> invalidates return values. A 'business exception' should thus be modeled
>> with a return value that gets checked later.
>>
>> Regarding return parameters in BOR, I've never liked them and almost
>> always gotten by without them in the BOR world. In some cases it's a
>> minor
>> inconvenience compared to BOR of having to check a parameter in a
>> separate
>> condition; but in other cases (if the step is simple and doesn't modify
>> any data) it actually simplifies things because you can even skip the
>> step
>> completely and plug a functional method straight into a condition.
>>
>> Cheers,
>> Mike
>>
>> On Thu, May 20, 2010 10:32 am, Robert van den Berg wrote:
>> >
>> > Hi all,
>> > Â
>> > I discovered where the evil is. In the old situation with BOR objects,
>> > the method has a return parameter (setting on the method). So the
>> > 'exceptions' are not exceptions but return values.
>> > Â
>> > Is there a possibility to use this with a Class method?
>> > Â
>> > Best regards,
>> > Robert
>> > On May 20, 2010 10:58 "Robert van den Berg" <wug at bergtop-ict.nl>wrote:
>> >> 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 OfRobert 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. <about:blank>
>> > _______________________________________________
>> > SAP-WUG mailing list
>> > SAP-WUG at mit.edu
>> > http://mailman.mit.edu/mailman/listinfo/sap-wug
>> >
>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _________________________________________________________________
> http://clk.atdmt.com/UKM/go/195013117/direct/01/
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>