Temporary Exception Message Not Showing Up in Workflow Log

Wed Dec 11 17:39:18 EST 2013

G'day Loren,

GET_ELEMENT is really just a READ TABLE statement. So 8 means the entry
wasn't found in the table (the container is really just an internal table).
You are correct. If you haven't bound it, at run time it won't be in the
container. Inbound containers only have entries that are bound to them, and
not an entry for every element specified at design time. And yes, the test
tools will load all elements with an initial value if nothing else
specified.

Agree that the set of 'USEEXCEPTIONS' on the basis of NoCommit not being
passed looks like a bug, but since in the PO WF I always want exceptions
and explicitly bind an 'X' I've never noticed.

Have fun,
Mark

On 12 December 2013 09:13, Bratzler, Loren <loren.bratzler at nscorp.com>wrote:

> Mark,
>
>
>
> Thank you for pointing this out.  I changed my message number to 001 and I
> am now getting my warning messages!
>
>
>
>
>
> And to Rick’s point about debugging the method:  I did that and I noticed
> some odd behavior in our Purchase Order workflow (BUS2012).  The BAPI that
> is used to release the PO has a parameter that basically tells the BAPI if
> any exceptions are going to be raised:
>
>
>
> CALL FUNCTION 'BAPI_PO_RELEASE'
>   EXPORTING
>     use_exceptions         = useexceptions
>     po_rel_code            = relcode
>     no_commit              = nocommit
>     purchaseorder          = object-key-purchaseorder
>   IMPORTING...
>
>
>
> If this parameter is not populated with an “X”, the BAPI will not raise
> any exceptions at all.
>
>
>
> I then saw this code at the beginning of the PO Release method:
>
>
>
> swc_get_element container 'RelCode' relcode.
> swc_get_element container 'UseExceptions' useexceptions.
> swc_get_element container 'NoCommit' nocommit.
> IF sy-subrc <> 0.
>   MOVE 'X' TO useexceptions.
> ENDIF.
>
>
>
> During debugging, I noticed that the first GET_ELEMENT command got a
> return-code of zero.  But the next two both got return-codes of 0008.
> Looking at the bindings, I could see that we were passing the workflow
> container elements to the task container, but the workflow container
> elements were never populated anywhere in the workflow.  *What is the
> criteria for when a GET_ELEMENT command will return a SY-SUBRC of 0008?*  What
> I found interesting was that if I tested the BOR method stand-alone through
> SWO1, these GET_ELEMENT commands always got return codes of zero, even
> though I did not key anything into the importing fields on the test
> screen.  They only got return-codes of 0008 when running in the workflow
> itself.  So is it possible that the SWO1 test screen was populating these
> fields with spaces which was accepted?  And then when running in the
> workflow they were INITIAL which caused the return-code 0008?
>
>
>
> The other thing I notice here is that the check of SY-SUBRC is after the
> GET of the NoCommit parameter but it is populating the UseExceptions
> parameter if sy-subr is not zero.  That looks to me like an error in the
> code and this code came from the standard RELEASE method of BUS2012.  I
> think the only reason we have been getting any exceptions at all from this
> process is because we just happened to not populate the NoCommit parameter
> which caused SY-SUBRC to be 0008 which then caused us to move the “X” to
> the UseExceptions variable.
>
>
>
> Loren
>
>
>
>
>
> *From:* sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] *On
> Behalf Of *Mark Pyc
> *Sent:* Tuesday, December 10, 2013 5:38 PM
>
> *To:* SAP Workflow Users' Group
> *Subject:* Re: Temporary Exception Message Not Showing Up in Workflow Log
>
>
>
> G'day Loren,
>
>
>
> An oldie, but a goldie!!
>
>
>
> SAP has some wonderful code that says if the message number is initial,
> don't include it in the log. Oh but wait, message 000 is a valid message
> number.... Too bad. Pick a different number.
>
>
>
> If you change to message ZWF_MSG 001 it'll work a treat.
>
>
>
> Have fun,
>
> Mark
>
>
>
>
>
> On 11 December 2013 05:41, Bratzler, Loren <loren.bratzler at nscorp.com>
> wrote:
>
> I feel like I’m asking an awful lot of questions here lately!  But here is
> another issue I am facing.  I spoke with Sue about this at TechEd and I
> have scoured SCN and the internet trying to find an answer but no luck so
> far.
>
>
>
> I have added a temporary exception to a BOR method when a user has the
> object locked.  On other workflows where we have a temporary exception, the
> workflow log shows a yellow warning indicator on the execution of the step
> that you can click on and get the temporary exception message:
>
>
>
>
>
>
>
> If you click on the warning, you get a pop-up window that displays the
> message:
>
>
>
>
>
>
>
> However, on the workflow where I just added the temporary exception, I do
> not get the warning message.  You can see in this example below, that the
> background task was executed twice by the retry program (RSWWERRE) before
> it finally completed but I did not get the warning messages:
>
>
>
>
>
>
>
> I have compared the two BOR methods (the one that works and the one that
> doesn’t work) and I believe I am doing everything correct.  They both have
> the exception defined as temporary:
>
>
>
>
>
>
>
> And the logic in the method is doing an EXIT_RETURN raising the temporary
> exception number:
>
>
>
> * If there is only one error message and it is a user lock
> * error (CJ-806), raise temporary exception 9001.
>       IF lv_lines = 1.
>         READ TABLE lt_result INDEX 1
>               INTO ls_result.
>         IF ls_result-message_id     = 'CJ' AND
>            ls_result-message_number = '806'.
>           lv_msg1 = ls_result-message_text.
>           exit_return 9001 lv_msg1 space space space.
>         ENDIF.
>       ENDIF.
>
>
>
>
>
> Even though these changes were made strictly to the BOR Object, I also
> generated a new version of the workflow to see if that would make the
> messages start appearing in the log, but that did not work either.
>
>
>
> Anyone have any ideas on what I might be missing here?
>
>
>
> Loren Bratzler
>
> Norfolk Southern Corporation
>
> 110 Franklin Road SE
>
> Roanoke, VA  24042-0060
>
>
>
> Phone: 540-524-3072
>
> Email: loren.bratzler at nscorp.com
>
>
>
>
> _______________________________________________
> 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/20131212/20df0436/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 14002 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20131212/20df0436/attachment-0005.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6141 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20131212/20df0436/attachment-0006.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15260 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20131212/20df0436/attachment-0007.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 17911 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20131212/20df0436/attachment-0008.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 31926 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20131212/20df0436/attachment-0009.png