Dynamic even in a wait step

[Mike Pokraka]

Hi Jocelyn & James,

That's precisely what I meant by 'event forwarder', and looks like I will
be going this route.

The idea of dynamic events tipped the balance towards BOR initially as it
made things more consistent and transparent, because the BOR events are
pre-existing and already used in other WFs.

Currently designing a table-driven generic event forwarder. A minor irk is
the multiple RFC calls - one for method execution and another for the
second event. But it's not too high volume.

Thanks & regards,
Mike

On Sat, May 9, 2015 1:21 pm, Dart, Jocelyn wrote:
> Hi Mike
> Many moons ago we wrote an event receiver function module that converted a
> BOR event into a OO event which saves creating event only workflows
> Just a thought
> Rgds
> Jocelyn
>
> Sent from my iPad
>
> On 9 May 2015, at 6:49 am, Rick Bakker
> <rbakker at gmail.com<mailto:rbakker at gmail.com>> wrote:
>
> Hi Mike,
>
> How about have each of the wait events listed as a start event of a
> workflow whose only step is to create a generic event to be picked up by
> your main workflow?
>
> regards
> Rick
>
> On Fri, May 8, 2015 at 10:20 AM, Mike Pokraka
> <wug at workflowconnections.com<mailto:wug at workflowconnections.com>> wrote:
> 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<mailto: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<mailto:SAP-WUG at mit.edu>
>>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu<mailto:SAP-WUG at mit.edu>
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu<mailto: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
>