Dynamic even in a wait step

[Florin Wach (SI)]

Hi Mike,

as I'm on the train, here's the short version after having thought about some alternatives:

Instead of a Wait step, create a subflow with a single asynchronous background step that executes a dummy method.

Within that step you create a container element that is bound to the name of the dynamic event you're waiting for.

As terminating events of that task you define once all the possible events.

A instance linkage check FM now compares the name of the event with the value of that container element of the task.

Have a look at the instance binding of BUS2012.Released where the element 'ReleaseCode' is compared.

The subflow has only the reason to avoid 20+ outcomes of the task .  With a subflow it looks more cleaner.


Mit freundlichen Gruessen / With kind regards 
   Florin Wach 
   Senior Workflow Engineer
   Systems-Integration 

--------------------------------------------------
http://www.systems-integration.net

> Am 08.05.2015 um 18:01 schrieb Mike Pokraka <wug at workflowconnections.com>:
> 
> 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 Wait step
> 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 WF can be started by a variety of events. Depending on triggering
> event, there will be a variety of different events to wait for.
> 
> Some approaches I've considered are:
> 1. A bunch of parallel wait branches and a series of switches to
> de/activate them, but that's nasty (20+ events).
> 2. The start event triggers a second workflow (one for each scenario),
> which only waits for the relevant reactors and then signals the main WF
> with a secondary event. Ugly.
> 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)
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug