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