Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Change documents + Workflow, avoiding recurrence

0 Likes
1,523

Hi there,

Scenario.

1. User creates customer.

2. Based on change documents, event CREATED is raised (SWE2 - configured custom Z* module checking some conditions and raising the event).

3. Workflow starts, goes through all company codes and synchronously calls XD01 via BDC to create customers in remaining company codes.

Problem.

Every time XD01 is called from workflow, event CREATED is raised as well, thus workflow is called recursively.

I am not able to distinguish whether event is raised by a user or workflow.

So far I just check (Z* FM, before raising CREATED event) if there's only 1 entry in KNB1, only then the event is raised.

I'm looking for a clever way to solve the issue, be it temporarily suppressing event generation within workflow session, passing some extra event parameters, or something else.

Thanks.

1 ACCEPTED SOLUTION
Read only

josef_graf
Explorer
0 Likes
1,396

Hey,

if the creation of the additional CC views happens in a batch workitem, then the user, who executes these steps and fires the (unwanted) events, should be the WF Batch User (WF-BATCH in standard customizing.

So you could try to define a starting condition for the Workflow like

&_EVT_CREATOR& <> 'WF-BATCH'

Best regards

Joe

5 REPLIES 5
Read only

ruben_rollano
Participant
0 Likes
1,396

Hello Bartosz,

My suggestion is to extend the estandard BUS with your own object, create you ZCREATED event and work with this one.

Best regards.

Read only

rameez_khan
Active Participant
0 Likes
1,396

Hello Bartosz,

Just to understand better, when you say based on change documents
Do you mean IDOC -> change pointers ? or the Z* FM/Module is called in any exit of XD01 where it raises event ?

Thanks
Rameez Khan

Read only

0 Likes
1,396

@Rameez Khan, Ruben Rollano Carcajona

No IDOCs involved.

I have created custom BOR object ZZ_KNA1 (as a subtype of KNA1). Standard KNA1 object does not have any events, thus I've added them (events ZZ_KNA1.created/ZZ_KNA1.changed) and tied them to change document (DEBI - customer) - tcode SWEC.

Then in tcode SWE2 I've tied event ZZ_KNA1.created to my workflow and configured custom Z* function module as the "Receiver function module".

By adding receiver FM, before ZZ_KNA1.created event is raised, Z* FM is called automatically by system (no custom coding here, system just calls this FM whenever customer is created). In this FM I check some conditions (customer group KNA1-KTOKD) before raising the actual event and then raising the event by calling SWW_WI_CREATE_VIA_EVENT_IBF.

The above works, workflow is started after customer is created.

The problem is the workflow itself also creates customers (extends them to other company codes) but that fires ZZ_KNA1.created events as well, which in turn start workflows.

As an example.

Let's say, there are 3 company codes 1000, 1001, 1002.

1. User creates customer in CC 1000.

2. Z* FM is called, ZZ_KNA1.created event is raised, workflow is called.

3. Workflow starts copying customer to CC 1001, 1002.

4. Z* FM is called, ZZ_KNA1.created event is raised for CC 1001 - the same workflow is called again.

5. Z* FM is called, ZZ_KNA1.created event is raised for CC 1002 - the same workflow is called again.

I do not want steps 4 and 5 to happen or at least find a condition that would allow me to filter the events (inside Z* FM) and react only to those generated by users and not the workflow itself.

Read only

josef_graf
Explorer
0 Likes
1,397

Hey,

if the creation of the additional CC views happens in a batch workitem, then the user, who executes these steps and fires the (unwanted) events, should be the WF Batch User (WF-BATCH in standard customizing.

So you could try to define a starting condition for the Workflow like

&_EVT_CREATOR& <> 'WF-BATCH'

Best regards

Joe

Read only

0 Likes
1,396

Argh, I've checked it before and I missed it (!)

You're right, subsequent events have USWF-BATCH as the creator.

Case solved.

I'll do the check in Z* FM, no need to start workflow just to do nothing in there.