Dynamic even in a wait step

[Mike Pokraka]

Hi Florin,

Nice idea, I like it. It's sortof between my option 1 and 2 but cleaner.

Another approach I'm considering is a bit more radical. It's a hybrid BOR
and OO workflow precisely because of a multitude of events from Status
Management, which still doesn't do OO-WF. I kept BOR in the WF because I
had it in my head that I could do dynamic waits for events straight from
BSVW config.

If the eventing in WF is too complex, I'm thinking an event forwarder into
a pure OO workflow right from the beginning is probably better. With a bit
of subclassing*, I can reduce it to 3 or 4 event waits and a little
consolidation logic in the event forwarder code.

Still pondering, will post back what I finally decide on. Still open to
other suggestions.

Thanks,
Mike

* - Dang, I forgot to add support for OO interfaces into the customer
connection suggestions!


On Fri, May 8, 2015 5:23 pm, Florin Wach (SI) wrote:
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>