Exception Classes which use T100 Message - IF_T100_MESSAGE

Thu Feb 16 06:21:37 EST 2012

Long time indeed, coming to ASUG?

Ah, I missed the bit about you declaring a new exception text. My example
was just using the exception class as is - just create it and pass in the
scx_t100key populated from within your code.

Have avoided them for so long that I can't remember all the evils, but
every time I mucked about with T100 classes I ran into a new annoyance. A
bugbear is that you can do a where-used on a T100 message, or on a class
exception, but not on a generic T100-class exception. So you need to make
your T100 messages explicit (e.g. by declaring specific exceptions for
each message), which ends up defeating one point of using T100's in first
place. Also, there were other restrictions that appeared - I think once
it's defined as a T100-style class, it and all it's subclasses can no
longer do 'normal' class exceptions. I think this may link to the issue
you're seeing.

Cheers,
Mike

On Wed, February 15, 2012 10:52 pm, Mark Pyc wrote:
> G'day Mike,
>
> Long time....
>
> Unfortunately it's not as simple as me not passing parameters properly. In
> the 7.02 version I'm on, when I declare the exception class to include
> messages it automatically gets the IF_T100_MESSAGE interface and when I
> declare an exception text, the auto-generated constant is a 'direct entry
> type' with code generated to populate the scx_t100key structured key based
> on the fields I maintain against the exception text.
>
> In my code when I have...
> RAISE EXCEPTION TYPE zcx_awi_wf_temp_trim
> EXPORTING
>        textid = zcx_awi_wf_temp_trim=>invalid_business_object_type
>        mv1    = lv_m1.
>
> ...I am passing a fully structured key. But I don't need to code it, it's
> stored against the class definition.
>
> I'm my case I guess I don't have a strong reason for wanting to use T100
> based exception texts, but I believe it 'should' work. You know how I get
> caught up on things that 'should' happen :-)
>
> I've seen similar comments from you in numerous posts to WUG but to be
> honest I'm stuggling to see your point about why such T100 messages are
> anything other than another option. One where for an existing message with
> detailed long text it's probably the most convenient option. Can you
> detail
> what is so evil about them??
>
> Having issues with OSS connection at site, so still waiting to apply note.
> Will let you all know if it makes any difference.
>
> Thanks!
> Mark
>
> On 16 February 2012 01:47, Mike Pokraka <wug at workflowconnections.com>
> wrote:
>
>> 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
>> >
>>
>>
>>
>>
>> _______________________________________________
>> 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
>