on 07-30-2013 5:43 PM
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...
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:
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
Florin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.