exception in class and passing of parameters

[Ramki Maley]

While on the topic...

Is it possible to get the exception message text into the very generic 
"Workflow nnnnnn set to status ERROR" message that gets sent out?
Has anyone tried customizing this message?

Regards,
Ramki.





On 5/20/10 7:17 PM, Dart, Jocelyn wrote:
> Folks,
> The ABAP OO for Workflow concept **** DOES **** include exception classes.
>
> There are a bunch of classes such as CX_BO_TEMPORARY, CX_BO_SYSTEM, CX_BO_APPLICATION, CX_BO_INSTANCE_NOT_FOUND, etc...
>
> You can add your own exception classes by creating subclasses of the first 3 (that determines workflow's default response if the exception is NOT explicitly modelled in your workflow flowchart).
> You can pass messages from the method that discovers the problem to the exception class,  and dynamically adjust the exception class text so that it appears in the workflow log.
> You can respond to a ABAP method's exceptions in workflow in the same way we did for BOR - i.e. activate the exception in the Outcome tab and add your alternate processing in the path.
>
>
> It's all in the SAP Library help.
> Regards,
> Jocelyn
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Pokraka
> Sent: Friday, 21 May 2010 2:55 AM
> To: SAP Workflow Users' Group
> Subject: RE: exception in class and passing of parameters
>
> Ah, now I see exacly what you're after!
>
> Interesting concept, although I am not too sure that level of
> functionality exists within standard exception classes outside of WF.
>
> I think the concept is certainly achievable in WF. There is a certain
> amount of trickery that can be done with error classes in WF, failing that
> something along the lines of the carrier pigeon idea should work.
>
> Cheers,
> Mike
>
>
> On Thu, May 20, 2010 4:58 pm, Mike Gambier wrote:
>>
>> Mike P,
>>
>>
>> Imagine this extremely theoretical scenario if you will:
>>
>>
>>
>>
>> An Error Instance is returned as a persistent object to the Workflow (that
>> had invoked the Method that errored) and this instance knows it is of type
>> 'Temporary Exception' because the Method tried to lock something and
>> couldn't, e.g. Foreign Lock. The Error Instance could even remember what
>> Object was supposed to be locked and also recall why the enqueue attempt
>> failed and could even be a specialised Class that's dedicated to this
>> particular type of Lock attempt.
>>
>>
>>
>> The Workflow could then routinely ask the Error Instance what it thinks
>> the problem is and what to do about it. In turn, the Error Instance could
>> reply to the Workflow that maybe it would be a good idea to wait for a bit
>> and try again later. Or, it could reply that because it knows that if an
>> enqueue fails on this type of Object then something is really wrong and
>> the Workflow should actually ask an Agent to investigate.
>>
>>
>>
>> In other words, couldn't a proper Error Instance in this way become an
>> integrated part of the Business Process and help add value to the
>> decision-making power of the WF definition in that it could provide
>> solutions to itself?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Mike GT
>>
>>
>>> Date: Thu, 20 May 2010 15:52:12 +0100
>>> Subject: RE: exception in class and passing of parameters
>>> From: wug at workflowconnections.com
>>> To: sap-wug at mit.edu
>>>
>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> SAP-WUG mailing list
>>> SAP-WUG at mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>> _________________________________________________________________
>> http://clk.atdmt.com/UKM/go/197222280/direct/01/
>> We want to hear all your funny, exciting and crazy Hotmail stories. Tell
>> us now_______________________________________________
>> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug