Dynamic even in a wait step

[Rick Bakker]

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>
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>:
> >>
> >> 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
> >
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20150508/7455af4a/attachment.htm