Exception Classes which use T100 Message - IF_T100_MESSAGE

[Mark Pyc]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20120216/9e9ffa2c/attachment.htm