Showing results for 
Search instead for 
Did you mean: 

Singleton WF approach with bus1001006.viewcreated event(s)

Former Member
0 Kudos

This a question which came into my mind while reading the excellent blog post


Please feel free to comment and provide advice!

Following scenario:

When a material is created, a workflow driven review process should start.

The workflow starts on event bus1001006.viewcreated because it must also start when later on another view is added to an existing material.

This event gets fired for every material view created, so n (n = number of created views) workflows are started simultaneously.

The first thing to do for the flow is to persist the data passed by the event into a z-table.

The first of the concurrent flows to do this is designated the "leading flow". All other flows recognize themselves as "non leading flows" and terminate after persisting their event data into the z-table.

So far so good. My problem is how to catch when all other workflows have persisted their event data so that the leading flow can continue.

Until now I'm simply using a Dummy Step with "requested start" = WI creation + 1 minute to give the other flows "enough" time to persist their data (which the leading flow must work with afterwards) and terminate.

Nevertheless, I'm not very happy with this approach since it may fail if the tRfc queue is congested.

Using the above mentioned singleton pattern the "non leading" flows would have to fire an event telling the "leading" flow that they have terminated.

The problem here is for the "leading" flow to know for how many parallel flows to wait for their termination.

I would have to find out how many material views were created respectively how many viewcreated events were fired for that material instance at the same moment.

Table MSTA unfortunately only has creation date but no time field, so this wouldn't work.

Do you understand my problem and have any advice?

Best regards...

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hello Frank,

this is a very similar requirement to one that you could have with a Purchase Order release procedure, where for every open release code a separate Workflow instance is being started. Also here it can be useful to have only one main workflow that holds and processes all of the release codes.

I think it can be done an figured out with a complex check-Function module on the event BUS1001006.ViewCreated, and figure out the situation. There are basically two types:

  1. Material is new, and one ore more views were created
  2. Material was existing, and one or more views were added

In this particular case I'd suggest to simplify the Check-FM and choose a different event for the created-Situation.

ad 1) Use the .Created event

You can use "Event creation through change document" (transaction SWEC) or check if BUS1001006.CREATED is already fired. A change document for MATERIAL will be written already for the on-INSERT activity. I have checked that.

Within the event creation or at the workflow-Startup in a special preparation step, extract the VIEWS, which were created, create your multiline container element and transform it in a way until you can use the existing workflow(s).

ad 2) Combine the .ViewCreated into a single event, e.g. .ViewsCreated

You can use also here the SWEC and create your own .ViewsCreated event and use the exit-Function-Module on "Change event container". Within that user-exit you have full access to the change document and you will know then, how many - and which - views were created.  Add this information as an event parameter.

Because of that, you will now receive only one event at a time, regardless if there were one or several views created at the same time.

The existing workflow instance can now receive such events and incorporate them into the running instance.


So, this is the draft algorithm to bring multiple events into a single Main workflow instance. The more concrete solution description should be part of the project you're working with.

Maybe other Forum members have already done similar solutions for the Material master data Workflows and they may share them here.

Take care