<div>G'day Mike,</div><div> </div><div>Long time....</div><div> </div><div>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. </div>
<div> </div><div>In my code when I have...</div><div>RAISE EXCEPTION TYPE zcx_awi_wf_temp_trim<br>EXPORTING<br> textid = zcx_awi_wf_temp_trim=>invalid_business_object_type<br> mv1 = lv_m1.</div><div> </div>
<div>...I am passing a fully structured key. But I don't need to code it, it's stored against the class definition.</div><div> </div><div>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 :-)</div>
<div> </div><div>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??</div>
<div> </div><div>Having issues with OSS connection at site, so still waiting to apply note. Will let you all know if it makes any difference.</div><div> </div><div>Thanks!</div><div>Mark<br><br></div><div class="gmail_quote">
On 16 February 2012 01:47, Mike Pokraka <span dir="ltr"><<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
Oh man, why T100 exception classes? They're an evil invention supposedly<br>
for easier transition and mixology of old style T100 messages and class<br>
exceptions, but really end up confusing matters and making errors more<br>
difficult to trace. But that's just my opinion; I prefer to map T100<br>
messages into class exceptions and keep separation clear.<br>
<br>
Onto your problem: IF you still want to use those type of exception<br>
classes, then you simply need to pass the message parameters properly. The<br>
textid parameter for message-based exception classes contains a full<br>
structure. You don't need to do any coding or add additional parameters in<br>
the exception class. I whipped up, a quick test class/prog but no time to<br>
test in a WF, but you should get the picture:<br>
<br>
DATA: lo_oops TYPE REF TO ycx_t100exc,<br>
ls_t100 TYPE scx_t100key,<br>
lv_msg TYPE string.<br>
TRY.<br>
ls_t100-msgid = 'SWF_RUN'.<br>
ls_t100-msgno = '001'.<br>
ls_t100-attr1 = 'go home'.<br>
RAISE EXCEPTION TYPE ycx_t100exc<br>
EXPORTING<br>
textid = ls_t100.<br>
CATCH ycx_t100exc INTO lo_oops.<br>
lv_msg = lo_oops->get_text( ).<br>
WRITE: lv_msg. "==> Action &go home& is unknown<br>
ENDTRY.<br>
<br>
Regards,<br>
Mike<br>
<div><div class="h5"><br>
<br>
On Wed, February 15, 2012 5:37 am, Mark Pyc wrote:<br>
> G'day Jocelyn,<br>
><br>
> Yep, when I created the Sub-class I selected the 'with Message Class'<br>
option which included the interface. I don't quite understand the use of<br>
the Interface as I don't need to do anything with it. I haven't<br>
> reimplemented the GET_TEXT method. Within normal ABAP if I raise and<br>
catch<br>
> an exception, the standard GET_TEXT will correctly resolve the message<br>
variable into appropriate text.<br>
><br>
> My harness is as follows:<br>
><br>
> REPORT<br>
><br>
> Z_PYC_EXCEPTION.<br>
><br>
> data:<br>
> lr_cx TYPE REF TO zcx_awi_wf_temp_trim,<br>
> lv_msg type string.<br>
><br>
> try.<br>
> perform sub1.<br>
> catch zcx_awi_wf_temp_trim INTO lr_cx.<br>
> call method lr_cx->if_message~get_text<br>
> receiving<br>
> result = lv_msg.<br>
> write:/ lv_msg.<br>
> ENDTRY.<br>
><br>
> form SUB1 RAISING zcx_awi_wf_temp_trim.<br>
> data:<br>
> lv_m1 type symsgv.<br>
><br>
> lv_m1 = 'BUS2013'.<br>
> RAISE EXCEPTION TYPE zcx_awi_wf_temp_trim<br>
> EXPORTING<br>
> textid = zcx_awi_wf_temp_trim=>invalid_business_object_type<br>
> mv1 = lv_m1.<br>
><br>
</div></div>> endform. *" SUB1*<br>
> **<br>
<div class="im">><br>
> It gives:<br>
> BUS2013 is an invalid Business Object Type<br>
><br>
> When included into WF, the Step History shows:<br>
> MV1 is an invalid Business Object Type<br>
><br>
> I'm just not sure if WF is doing something other than calling GET_TEXT<br>
and<br>
> therefore missing the T100 logic. I know that the CX_BO_TEMPORARY<br>
doesn't<br>
> include the T100 interface and so the WF code won't be expecting to do<br>
anything with it, but just having the interface linked is enough from<br>
some<br>
> snippets I've read. WF runtime should be able to call GET_TEXT without<br>
needing to know about T100 explicitly....???<br>
><br>
> Any advice appreciated.<br>
><br>
> Have fun,<br>
> Mark<br>
><br>
><br>
> On 15 February 2012 15:41, Dart, Jocelyn <<a href="mailto:jocelyn.dart@sap.com">jocelyn.dart@sap.com</a>> wrote:<br>
><br>
</div>>> Hi Mark, ****<br>
<div class="im">>> I’ve not tried IF_T100_MESSAGE – are you able to add it to your exception<br>
>> class and call a method or function module to create the message text<br>
from<br>
</div>>> the GET_TEXT method? ****<br>
>> ** **<br>
<div class="im">>> There are heaps of function modules that do it... I seem to recall I used<br>
</div>>> one of the BAL_LOG_ ones... ****<br>
>> Regards,****<br>
>> Jocelyn****<br>
>> ** **<br>
>> *From:* <a href="mailto:sap-wug-bounces@mit.edu">sap-wug-bounces@mit.edu</a> [mailto:<a href="mailto:sap-wug-bounces@mit.edu">sap-wug-bounces@mit.edu</a>] *On<br>
Behalf Of *Mark Pyc<br>
>> *Sent:* Wednesday, 15 February 2012 12:53 PM<br>
>> *To:* WUG<br>
>> *Subject:* Exception Classes which use T100 Message -<br>
>> IF_T100_MESSAGE****<br>
>> ** **<br>
>> G'day Wuggers,****<br>
>> ****<br>
>> Is it possible to utilise T100 based exceptions within WF? ****<br>
>> ****<br>
<div class="im">>> I've created an sub-class of CX_BO_TEMPORARY and included an Exception ID<br>
>> which is based on a T100 message including variables. I've extended my<br>
class to have additional attributes for passing in data (MV1, MV2, MV3,<br>
MV4<br>
>> all like SYMSGV) which are then referenced as appropriate in the pop-up<br>
for<br>
</div>>> assigning a T100 message to the Exception ID. ****<br>
>> ****<br>
>> When I raise the exception, I pass in the additional parameters.****<br>
>> ****<br>
<div class="im">>> If I test this via a simple harness program, the text of the message is<br>
</div>resolved correctly.****<br>
>> ****<br>
<div class="im">>> When I integrate into WF, the variable isn't resolved and remains as<br>
MV1<br>
</div>>> in the text of the WF log. ****<br>
>> ****<br>
<div class="im">>> I've seen some prior posts from Jocelyn that suggest adding a BAPIRET2<br>
based table and redefining the GET_TEXT method to offer the ability of<br>
passing multiple messages with a single exception. Is this necessary to<br>
</div>even handle a basic scenario?****<br>
>> ****<br>
<div class="im">>> I've found OSS note 1671428 (yet to be translated) which looks<br>
promising<br>
>> but am waiting for it to be applied to the system. However in thinking it<br>
>> through further I doubt it will change anything since CX_BO_TEMPORARY<br>
</div>doesn't implement IF_T100_MESSAGE.****<br>
>> ****<br>
<div class="im">>> Can anyone confirm if the T100 based exceptions are possible in WF, or do<br>
>> I need to go down the path of redefining GET_TEXT as suggested by Jocelyn?<br>
</div>>> ****<br>
>> ****<br>
>> Many thanks,<br>
>> Mark****<br>
<div class="HOEnZb"><div class="h5">>> _______________________________________________<br>
>> SAP-WUG mailing list<br>
>> <a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
>> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> <a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
SAP-WUG mailing list<br>
<a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
</div></div></blockquote></div><br>