Exception Classes which use T100 Message - IF_T100_MESSAGE
Florin Wach
florin.wach at gmx.net
Thu Feb 16 09:25:50 EST 2012
Hi Mike, Hi Mark,
that instantiation is really annoying, but the exception class only allows to store persistently the message-ID with it's parameters.
I have found a workaround to display individual text w/o T100:
I have subtyped the exception class and created a new class-method "get_instance", that creates an exception class instance using the currently present sy-msgno, sy-msgid, ... etc. or - alternatively - uses the import element iv_message_text TYPE STRING and assignes this to a member-attribute of the just create class for later pickup.
To present the text other than "Temporary exception was triggered in ...", I did also override the method "IF_MESSAGE~Get_text" to simply display the short text of the message, if present, otherwise T100 is used per default.
The text that is displayed in the workflow protocol and the item is fixed, once the workitem processing ends, i.e., the get_text method is directly called by the workflow runtime after catching the temporary exception and that copy is stored here. So overriding get_text( ) does most of the work.
But that way, you need two additional coding lines to get your exception thrown:
DATA: lo_cx_my_temp_exception TYPE REF TO ZCX_SPECIAL_TEMP.
lo_cx_my_temp_exceptoin = ZCX_SPECIAL_TEMP=>get_instance( 'Hello, World' ).
RAISE EXCEPTION lo_cx_my_temp_exception.
"The workitem's message and protocol will now show "Hello, World".
I don't know, if that is too much of a coding, which could have been achived easier (Any hints?)
So maybe that's some ease to that nasty T100-stuff.
With the very best wishes,
Florin
....
So here's some coding excerpt:
GET_INSTANCE: returning ro_instance TYPE REF TO ZCX_TEMPORARY
importing iv_message_text TYPE STRING OPTIONAL.
method GET_INSTANCE.
IF iv_message_text IS INITIAL.
DATA: ls_textid TYPE SCX_T100KEY.
ls_textid-msgno = sy-msgno.
ls_textid-msgid = sy-msgid.
ls_textid-attr1 = sy-msgv1.
ls_textid-attr2 = sy-msgv2.
ls_textid-attr3 = sy-msgv3.
ls_textid-attr4 = sy-msgv4.
sy-msgty = 'E'.
CREATE OBJECT ro_instance EXPORTING textid = ls_textid.
ELSE.
CREATE OBJECT ro_instance.
ro_instance->mv_message_text = iv_message_text.
ENDIF.
endmethod.
method IF_MESSAGE~GET_TEXT. (redefinition)
IF NOT mv_message_text IS INITIAL.
result = mv_message_text.
ELSE.
result = super->IF_MESSAGE~GET_TEXT( ).
ENDIF.
endmethod.
ADD member attribute mv_message_text TYPE STRING instance private.
-------- Original-Nachricht --------
> Datum: Thu, 16 Feb 2012 11:21:37 -0000 (GMT)
> Von: "Mike Pokraka" <wug at workflowconnections.com>
> An: "SAP Workflow Users\' Group" <sap-wug at mit.edu>
> Betreff: Re: Exception Classes which use T100 Message - IF_T100_MESSAGE
> 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
> >
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list