Exception Classes which use T100 Message - IF_T100_MESSAGE

[Mike Pokraka]

Oh man, why T100 exception classes? They're an evil invention supposedly
for easier transition and mixology of old style T100 messages and class
exceptions, but really end up confusing matters and making errors more
difficult to trace. But that's just my opinion; I prefer to map T100
messages into class exceptions and keep separation clear.

Onto your problem: IF you still want to use those type of exception
classes, then you simply need to pass the message parameters properly. The
textid parameter for message-based exception classes contains a full
structure. You don't need to do any coding or add additional parameters in
the exception class. I whipped up, a quick test class/prog but no time to
test in a WF, but you should get the picture:

DATA: lo_oops TYPE REF TO ycx_t100exc,
      ls_t100 TYPE scx_t100key,
      lv_msg  TYPE string.
TRY.
    ls_t100-msgid = 'SWF_RUN'.
    ls_t100-msgno = '001'.
    ls_t100-attr1 = 'go home'.
    RAISE EXCEPTION TYPE ycx_t100exc
      EXPORTING
        textid = ls_t100.
  CATCH ycx_t100exc INTO lo_oops.
    lv_msg = lo_oops->get_text( ).
    WRITE: lv_msg.  "==> Action &go home& is unknown
ENDTRY.

Regards,
Mike


On Wed, February 15, 2012 5:37 am, Mark Pyc wrote:
> G'day Jocelyn,
>
> Yep, when I created the Sub-class I selected the 'with Message Class'
option which included the interface. I don't quite understand the use of
the Interface as I don't need to do anything with it. I haven't
> reimplemented the GET_TEXT method. Within normal ABAP if I raise and
catch
> an exception, the standard GET_TEXT will correctly resolve the message
variable into appropriate text.
>
> My harness is as follows:
>
> REPORT
>
> Z_PYC_EXCEPTION.
>
> data:
> lr_cx TYPE REF TO zcx_awi_wf_temp_trim,
> lv_msg type string.
>
> try.
> perform sub1.
> catch zcx_awi_wf_temp_trim INTO lr_cx.
> call method lr_cx->if_message~get_text
> receiving
> result = lv_msg.
> write:/ lv_msg.
> ENDTRY.
>
> form SUB1 RAISING zcx_awi_wf_temp_trim.
> data:
> lv_m1 type symsgv.
>
> lv_m1 = 'BUS2013'.
> RAISE EXCEPTION TYPE zcx_awi_wf_temp_trim
> EXPORTING
> textid = zcx_awi_wf_temp_trim=>invalid_business_object_type
> mv1 = lv_m1.
>
> endform. *" SUB1*
> **
>
> It gives:
> BUS2013 is an invalid Business Object Type
>
> When included into WF, the Step History shows:
> MV1 is an invalid Business Object Type
>
> I'm just not sure if WF is doing something other than calling GET_TEXT
and
> therefore missing the T100 logic. I know that the CX_BO_TEMPORARY
doesn't
> include the T100 interface and so the WF code won't be expecting to do
anything with it, but just having the interface linked is enough from
some
> snippets I've read. WF runtime should be able to call GET_TEXT without
needing to know about T100 explicitly....???
>
> Any advice appreciated.
>
> Have fun,
> Mark
>
>
> On 15 February 2012 15:41, Dart, Jocelyn <jocelyn.dart at sap.com> wrote:
>
>> Hi Mark, ****
>> I’ve not tried IF_T100_MESSAGE – are you able to add it to your exception
>> class and call a method  or function module to create the message text
from
>> the GET_TEXT method? ****
>> ** **
>> There are heaps of function modules that do it... I seem to recall I used
>> one of the BAL_LOG_ ones... ****
>> Regards,****
>> Jocelyn****
>> ** **
>> *From:* sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] *On
Behalf Of *Mark Pyc
>> *Sent:* Wednesday, 15 February 2012 12:53 PM
>> *To:* WUG
>> *Subject:* Exception Classes which use T100 Message -
>> IF_T100_MESSAGE****
>> ** **
>> G'day Wuggers,****
>>  ****
>> Is it possible to utilise T100 based exceptions within WF? ****
>>  ****
>> I've created an sub-class of CX_BO_TEMPORARY and included an Exception ID
>> which is based on a T100 message including variables. I've extended my
class to have additional attributes for passing in data (MV1, MV2, MV3,
MV4
>> all like SYMSGV) which are then referenced as appropriate in the pop-up
for
>> assigning a T100 message to the Exception ID. ****
>>  ****
>> When I raise the exception, I pass in the additional parameters.****
>>  ****
>> If I test this via a simple harness program, the text of the message is
resolved correctly.****
>>  ****
>> When I integrate into WF, the variable isn't resolved and remains as
MV1
>> in the text of the WF log. ****
>>  ****
>> I've seen some prior posts from Jocelyn that suggest adding a BAPIRET2
based table and redefining the GET_TEXT method to offer the ability of
passing multiple messages with a single exception. Is this necessary to
even handle a basic scenario?****
>>  ****
>> I've found OSS note 1671428 (yet to be translated) which looks
promising
>> but am waiting for it to be applied to the system. However in thinking it
>> through further I doubt it will change anything since CX_BO_TEMPORARY
doesn't implement IF_T100_MESSAGE.****
>>  ****
>> Can anyone confirm if the T100 based exceptions are possible in WF, or do
>> I need to go down the path of redefining GET_TEXT as suggested by Jocelyn?
>> ****
>>  ****
>> Many thanks,
>> Mark****
>> _______________________________________________
>> 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
>