cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Dynamic event in a wait step

pokrakam
Active Contributor
0 Kudos
339

Hi all,

I bumped into a limitation in the wait step and was wondering if anyone had any more elegant workarounds than my klutzy attempts:

What I'd like to do is wait for a dynamic event. It would be easy with a container element for the event name, but unfortunately the WF builder complains that "Event &WAITFORTHIS& does not exist" when I try to insert a container element into the event field of a wait step.

Background:

The Workflow can be started by a variety of events. Depending on triggering event, there will be a variety of different events to wait for.

What I've tried:

Some approaches I've considered are:

  1. A bunch of parallel wait branches and switches to activate them, but that's ugly (20+ events).
  2. The start event triggers a second workflow (one for each scenario), which only waits for the relevant events and then signals the main WF with a secondary event. Nasty, but keeps the main WF neat and manageable.
  3. Custom event receiver module in the event linkage table to manipulate the relevant workflow. Obscure.

I can't help thinking there must be a better way ๐Ÿ™‚

Any input appreciated,

Mike

(Cross-posted on WUG and SCN)

Accepted Solutions (1)

Accepted Solutions (1)

former_member186746
Active Contributor
0 Kudos

Hi Mike,

What is the business requirement?

Suppose a wait for dynamic event is possible then you will have problems with the bindings from event container to workflow container.

What I would do (depending on the requirement) is create a custom event where the workflow waits for maybe use workitem id or guid as key along with a check table to store the various dependancies.

And then for all of the 20+ events which might be the original sender of the event add an entry in SWEINST for a check or receiver function module. In that module you find out what the key should be of the custom event and then trigger that one.

Kind regards, Rob Dielemans

Answers (2)

Answers (2)

pokrakam
Active Contributor
0 Kudos

Hi Rob,

The business requirement is to wait for different events in different scenarios, depending on trigger and status.

e.g. If WF starts with event A then it should respond to events B and C. When X then I'm interested in events Y and Z. (An added curve ball is that it can be different object types too, but I've polymorphed my way around that).

Event containers are not an issue, these are status management events with just an object key.

My current thinking is to ditch the whole design. Status management can only do BOR events, so I'm using BOR objects in my WF to keep it clear and simple, based on my incorrect assumption that I could do dynamic eventing.

The added complexity due to hardcoding events outweighs the simplicity I gain by keeping BOR. So now I'm leaning back towards an 'event mapping' module outside of WF and go pure OO. Which is nice ๐Ÿ™‚

Still open to other ideas though...

Thanks & regards,

Mike

ronen_weisz
Active Contributor
0 Kudos

I agree that with complex mapping, an event mapping module will probably be more useful and readable then the condition editor. but maybe this could be done by using the same event for all statuses and reading the status as an attribute and placing a condition on that in the 'wait for event step'? there is the 'interface' option on the BOR if needed for more then one object.

pokrakam
Active Contributor
0 Kudos

Hello Ronen,

"...reading the status as an attribute" was exactly the sort of thing I had in mind - only I wanted to use events as calculated attributes and wait for &MYOBJECT.MYNEXTEVENT&

BSVW is limiting me from defining the same events for similar steps (different object key fields). Unless I manually create the entries in the tables... hmmmm.... This builds up on prior developments that defined separate events for each status so in many cases we will have multiple events for the same thing. Still, might be worthwhile.

Conditions is another interesting twist I hadn't considered. Wasn't aware they could be applied to wait steps. I may play around with this idea a little more.

Thanks, you have given me something to think about.

Regards,

Mike

former_member186746
Active Contributor
0 Kudos

Hi Mike,

From the workflow log point of view, option 2 is not that bad. It's also the least amount of work.

It's what you do in SRM workflow or MM-PUR scenarios, the process starts in a 1:2 fork. In one branch the whole process and in the other a subflow with lots of wait for event steps (deleted, significantly changed, released, others).

Disregards my previous post, my suggestion is to go this route.

Kind regards, Rob Dielemans