Dynamic even in a wait step

Mon May 11 14:07:31 EDT 2015

Agreed with Jocelyn, I've successfully implemented such an approach for an 
ISU workflow on my client project, and it works very well.  In my case, 
the SAP standard ISU events I was interested in were BOR-based (I think 
they all are in ISU) , so I opted to create a custom receiver to generate 
an equivalent OO event.

Best Regards,
James Johnson

E-mail:JJohnson at uk.ibm.com
Mobile: 07908715224

From:   "Dart, Jocelyn" <jocelyn.dart at sap.com>
To:     "SAP Workflow Users' Group" <sap-wug at mit.edu>
Date:   09/05/2015 13:32
Subject:        Re: Dynamic even in a wait step
Sent by:        sap-wug-bounces at mit.edu

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> 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
> 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

_______________________________________________
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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20150511/a586d58f/attachment.htm