Caution: in SRM 5.0 - using SWE_EVENT_MAIL

Susan R. Keohan keohan at ll.mit.edu
Tue Feb 14 08:10:20 EST 2006


Hi Jocelyn,

Yes, SRM is indeed special.  The SWE_EVENT_MAIL was working if I triggered the event via SWUE, but 
it was also preventing any Purchase Orders from being saved because of the 'ambiguous workflow' 
condition.

I just wanted to share that info so that nobody else has to feel my pain.

Thanks for the pointer about BBP_PDH_WFL_DB_UPDATE!
Cheers,
Sue

Dart, Jocelyn wrote:

> Yep Sue - that's right.  SRM is *special* that way. 
> 
> In any case, SWE_EVENT_MAIL probably won't work because SRM doesn't
> generally raise the event - it simulates the whole event manager process
> and then uses the result of the simulation to start the workflow
> directly. 
> 
> So I'm afraid SWE_EVENT_MAIL won't be of much use to you anyway. 
> 
> You are better off to put a break-point in fm BBP_PDH_WFL_DB_UPDATE, and
> in debug change the flag to run the workflow checking/creation
> synchronously.  
> 
> 
> Regards,
> Jocelyn Dart
> Senior Consultant
> SAP Australia Pty Ltd.
> Level 1/168 Walker St.
> North Sydney 
> NSW, 2060
> Australia
> T   +61 412 390 267
> M   + 61 412 390 267
> E   jocelyn.dart at sap.com
> http://www.sap.com
> 
> The information contained in or attached to this electronic transmission
> is confidential and may be legally privileged. It is intended only for
> the person or entity to which it is addressed. If you are not the
> intended recipient, you are hereby notified that any distribution,
> copying, review, retransmission, dissemination or other use of this
> electronic transmission or the information contained in it is strictly
> prohibited. If you have received this electronic transmission in error,
> please immediately contact the sender to arrange for the return of the
> original documents. 
> Electronic transmission cannot be guaranteed to be secure and
> accordingly, the sender does not accept liability for any such data
> corruption, interception, unauthorized amendment, viruses, delays or the
> consequences thereof.
> Any views expressed in this electronic transmission are those of the
> individual sender, except where the message states otherwise and the
> sender is authorized to state them to be the views of SAP AG or any of
> its subsidiaries. SAP AG, its subsidiaries, and their directors,
> officers and employees make no representation nor accept any liability
> for the accuracy or completeness of the views or information contained
> herein. Please be aware that the furnishing of any pricing information/
> business proposal herein is indicative only, is subject to change and
> shall not be construed as an offer or as constituting a binding
> agreement on the part of SAP AG or any of its subsidiaries to enter into
> any relationship, unless otherwise expressly stated. 
> 
> 
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of Susan R. Keohan
> Sent: Tuesday, 14 February 2006 1:43 AM
> To: SAP Workflow Users' Group
> Subject: Caution: in SRM 5.0 - using SWE_EVENT_MAIL
> 
> Hello WF-ers,
> 
> While debugging in SRM 5.0, WAS 700, to determine if an event is
> raised...
> 
> If you use standard functionality to send an SAPOffice message to your
> userid when an event is 
> created (see attachment), unless your username begins with a letter
> greater than W (for 'WS'), your 
> username will be returned as the first row in table lt_start_receivers
> after the following calls...
> 
> BBP_PDH_WFL_CHECK_BEFORE_START
> SWE_BBP_EVENT_SIMULATE
> 
> SWB_2_CHECK_FB_START_COND_EVAL
> SWB_COND_EVAL
> 
> Back in BBP_PDH_WFL_CHECK_BEFORE_START...
>    IF sy-subrc <> 0.
> * Kein Genehmigung-Workflow gefunden; Systemverwaltung informieren
>      MESSAGE s012(bbp_wfl) RAISING no_workflow_found.
> *    RETURN.
>    ENDIF.
> 
>    READ TABLE lt_start_receivers WITH KEY wf_task = 'X'.
>    IF sy-subrc <> 0.
> * Kein Genehmigung-Workflow gefunden; Systemverwaltung informieren
>      MESSAGE s012(bbp_wfl) RAISING no_workflow_found.
> *    RETURN.
>    ELSE.
>      IF sy-tfill > 1.
> * Genehmigung-Workflow ist nicht eindeutig; Systemverwaltung informieren
>        MESSAGE s013(bbp_wfl) RAISING workflow_not_unique.
> *      RETURN.
>      ENDIF.
>    ENDIF.
> 
>    ev_cond_task = lt_start_receivers-rectype.
>    gv_wf_start_cond_task = lt_start_receivers-rectype.
> 
> At the point where the read table lt_start_receivers is executed, the
> row with the workflow template 
> which should be started is, in my case, the second row.  Therefore, when
> sy-tfill is evaluated, it 
> is equal to 2, which causes the 'workflow_not_unique' to be raised.
> 
> A Customer Message has been raised, but I wanted to help any of you
> prevent needless heartache.
> Regards,
> Sue

-- 
Susan R. Keohan
SAP Workflow Developer
MIT Lincoln Laboratory
244 Wood Street
LI-200
Lexington, MA. 02420
781-981-3561
keohan at ll.mit.edu



More information about the SAP-WUG mailing list