<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>Hi Mike</div>
<div>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</div>
<div>Just a thought</div>
<div>Rgds</div>
<div>Jocelyn</div>
<div><br>
Sent from my iPad</div>
<div><br>
On 9 May 2015, at 6:49 am, Rick Bakker <<a href="mailto:rbakker@gmail.com">rbakker@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">Hi Mike,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>regards</div>
<div>Rick</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 8, 2015 at 10:20 AM, Mike Pokraka <span dir="ltr">
<<a href="mailto:wug@workflowconnections.com" target="_blank">wug@workflowconnections.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Florin,<br>
<br>
Nice idea, I like it. It's sortof between my option 1 and 2 but cleaner.<br>
<br>
Another approach I'm considering is a bit more radical. It's a hybrid BOR<br>
and OO workflow precisely because of a multitude of events from Status<br>
Management, which still doesn't do OO-WF. I kept BOR in the WF because I<br>
had it in my head that I could do dynamic waits for events straight from<br>
BSVW config.<br>
<br>
If the eventing in WF is too complex, I'm thinking an event forwarder into<br>
a pure OO workflow right from the beginning is probably better. With a bit<br>
of subclassing*, I can reduce it to 3 or 4 event waits and a little<br>
consolidation logic in the event forwarder code.<br>
<br>
Still pondering, will post back what I finally decide on. Still open to<br>
other suggestions.<br>
<br>
Thanks,<br>
Mike<br>
<br>
* - Dang, I forgot to add support for OO interfaces into the customer<br>
connection suggestions!<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On Fri, May 8, 2015 5:23 pm, Florin Wach (SI) wrote:<br>
> Hi Mike,<br>
><br>
> as I'm on the train, here's the short version after having thought about<br>
> some alternatives:<br>
><br>
> Instead of a Wait step, create a subflow with a single asynchronous<br>
> background step that executes a dummy method.<br>
><br>
> Within that step you create a container element that is bound to the name<br>
> of the dynamic event you're waiting for.<br>
><br>
> As terminating events of that task you define once all the possible<br>
> events.<br>
><br>
> A instance linkage check FM now compares the name of the event with the<br>
> value of that container element of the task.<br>
><br>
> Have a look at the instance binding of BUS2012.Released where the element<br>
> 'ReleaseCode' is compared.<br>
><br>
> The subflow has only the reason to avoid 20+ outcomes of the task . With<br>
> a subflow it looks more cleaner.<br>
><br>
><br>
> Mit freundlichen Gruessen / With kind regards<br>
> Florin Wach<br>
> Senior Workflow Engineer<br>
> Systems-Integration<br>
><br>
> --------------------------------------------------<br>
> <a href="http://www.systems-integration.net" target="_blank">http://www.systems-integration.net</a><br>
><br>
>> Am 08.05.2015 um 18:01 schrieb Mike Pokraka<br>
>> <<a href="mailto:wug@workflowconnections.com">wug@workflowconnections.com</a>>:<br>
>><br>
>> Hi all,<br>
>><br>
>> I bumped into a limitation in the wait step and was wondering if anyone<br>
>> had any more elegant workarounds than my klutzy attempts:<br>
>><br>
>> What I'd like to do is wait for a dynamic event. It would be easy with a<br>
>> container element for the event name, but unfortunately the Wait step<br>
>> complains that "Event &WAITFORTHIS& does not exist" when I try to insert<br>
>> a<br>
>> container element into the event field of a wait step.<br>
>><br>
>> Background:<br>
>> The WF can be started by a variety of events. Depending on triggering<br>
>> event, there will be a variety of different events to wait for.<br>
>><br>
>> Some approaches I've considered are:<br>
>> 1. A bunch of parallel wait branches and a series of switches to<br>
>> de/activate them, but that's nasty (20+ events).<br>
>> 2. The start event triggers a second workflow (one for each scenario),<br>
>> which only waits for the relevant reactors and then signals the main WF<br>
>> with a secondary event. Ugly.<br>
>> 3. Custom event receiver module in the event linkage table to manipulate<br>
>> the relevant workflow. Obscure.<br>
>><br>
>> I can't help thinking there must be a better way :-)<br>
>><br>
>> Any input appreciated,<br>
>> Mike<br>
>> (Cross-posted on WUG and SCN)<br>
>><br>
>> _______________________________________________<br>
>> SAP-WUG mailing list<br>
>> <a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
>> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
><br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> <a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
><br>
<br>
_______________________________________________<br>
SAP-WUG mailing list<br>
<a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" target="_blank">http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>SAP-WUG mailing list</span><br>
<span><a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a></span><br>
<span><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</a></span><br>
</div>
</blockquote>
</body>
</html>