Re: OSWorkflow - initial action for steps?

Not really sure at all, it was just a thought I had. I emailed Bob and he
wrote back to me, and then I haven't had a chance to write back to him again
yet. I think for now we should operate under the assumption that no
collaboration will exist until one is actually confirmed. In the meantime, a
rule engine could be a very powerful addition to a workflow engine, so it's
somethig we should look at regardless.

-Pat

----- Original Message -----
From: "James Higginbotham" <[email protected]>
To: "Pat Lightbody" <[email protected]>; "Hani Suleiman"
<[email protected]>; <[email protected]>
Sent: Thursday, May 08, 2003 7:23 PM
Subject: RE: [Opensymphony-developers] OSWorkflow - initial action for
steps?


> Pat,
>
> So, as a lurker here for a few months to get to know the OS libraries, I
wonder how OSWorkflow would differ from Werkflow then after this
collaboration? Would you replace the core OSWorkflow with Werkflow or ...?
Just trying to understand what your thoughts are - I'm interested in this
thread and would benefit from this new feature, however it is implemented.
>
> Regards,
> James
>
> > -----Original Message-----
> > From: Pat Lightbody [mailto:[email protected]]
> > Sent: Thursday, May 08, 2003 8:28 PM
> > To: Hani Suleiman; [email protected]
> > Subject: Re: [Opensymphony-developers] OSWorkflow - initial
> > action for steps?
> >
> >
> > Yeah, it sounds like a complex problem. I think for version
> > 3.0 we should look in to making the engine a true
> > petrinet-based engine (it's pseudo-petrinet atm) and make
> > complete support for human and machine actions (possibly via
> > a rule engine). Werkflow is supposed to work this way and
> > I've spoken with Bob (I still need to email him back) about
> > possibly collaborating.
> >
> > -Pat
> >
> > ----- Original Message -----
> > From: "Hani Suleiman" <[email protected]>
> > To: <[email protected]>
> > Sent: Thursday, May 08, 2003 12:03 PM
> > Subject: Re: [Opensymphony-developers] OSWorkflow - initial
> > action for steps?
> >
> >
> > > One thing to keep in mind though is that actions that are
> > > autoperformed would have to have an unconditional result,
> > there will
> > > probably be validation performed to ensure that a descriptor which
> > > does not have an unambigious action result and has that
> > action set to
> > > autoexecute is reported as an error.
> > >
> > > On Thursday, May 8, 2003, at 10:15 AM, Hubert Felber wrote:
> > >
> > > >
> > > >> Any downside to having it in?
> > > >
> > > > If there was a "step initial function" in the form of a
> > > > pre-function, would it be executed every time you make a
> > transition
> > > > to the same step from within an action? If yes, this
> > could be what
> > > > you wanted, or not. The same is true for "step post functions".
> > > >
> > > > I vote for the proposal that Alex made. It would be great to have
> > > > all actions with attribute "auto=yes" performed automatically.
> > > >
> > > > Hubert
> > > >
> > > >>>> Axel Müller <[email protected]> 05/08/03 08:57am >>>
> > > > This sound really good and is what I would like to see soon :-)
> > > > However it is limited to a single "autoaction" per step which
> > > > sometimes
> > > >
> > > > is not enough.
> > > > Why not have an "auto" attribute for each action? When a step
> > > > becomes current step all actions with "auto=yes" will be
> > performed
> > > > automatically with regards to the normal condition/restriction
> > > > behaviour.
> > > >
> > > > Axel
> > > >
> > > >
> > > > [email protected] wrote:
> > > >
> > > >> Yup. You understand what I mean.
> > > >>
> > > >> Pre-functions for steps would work great and would be
> > the cleanest
> > > > implementation.
> > > >>
> > > >> As simple change you could just add an optional attribute in the
> > > > "step" element
> > > >> that specifies an action to take automatically when the step is
> > > > transitioned to..
> > > >> like:
> > > >>
> > > >> <step id="3" name="xxx" autoaction="101">
> > > >> <actions>
> > > >> <action id="101" name="Starting action...">
> > > >> ..
> > > >>
> > > >> As I said earlier, something like this would help the tool be
> > > >> useful
> > > > as a process-
> > > >> modelling engine for processes that have no humans..
> > > >>
> > > >> -Greg
> > > >>
> > > >>
> > > >>
> > > >> ---- Original Message ----
> > > >> From: Hani Suleiman
> > > >> Date: Wed 5/7/03 15:35
> > > >> To: [email protected]
> > > >> Subject: Re: [Opensymphony-developers] OSWorkflow - initial
> > > > action for steps?
> > > >>
> > > >> Hmm, yeah. can't think of a way to do it currently without
> > > >> specifying
> > > > a
> > > >> pre/post function in every caller. It sounds like you need the
> > > >> option
> > > >
> > > >> of specifying pre/post functions to steps, not just to
> > actions. Am
> > > >> I right? Does anyone else find this useful? Any
> > objections to it?
> > > >> Any downside to having it in?
> > > >>
> > > >> Hani
> > > >>
> > > >> On Wednesday, May 7, 2003, at 03:59 PM, [email protected]
> > > >> wrote:
> > > >>
> > > >>
> > > >>
> > > >>> I'm trying to model some workflows that use asynchronous
> > > >>> processing (by sending JMS messages to some other system) in
> > > >>> OSWorkflow and I'm finding it difficult. I can
> > > >>> create steps than have actions (called manually ala the
> > example) that
> > > >
> > > >>> send JMS
> > > >>> messages, and I've created a JMS listener that waits
> > for the reply
> > > > and
> > > >>> invokes the
> > > >>> proper action to "complete" the step and let it
> > transition to the
> > > > next
> > > >>> step, no
> > > >>> problem..
> > > >>>
> > > >>> But once I transition to the next step, say "Step B",
> > there is no
> > > >>> way
> > > >
> > > >>> to
> > > >>> automatically perform an action when the workflow
> > transitions to
> > > >>> that
> > > >
> > > >>> "step" from
> > > >>> somewhere else (maybe from a join, or from some other step's
> > > >>> result).
> > > >
> > > >>> I cant have
> > > >>> every place that could possibly transition to Step B
> > perform the
> > > >>> JMS
> > > >
> > > >>> action.. the
> > > >>> same workflow XML would get propagated all over the
> > place.. I want
> > > >>> Step B to perform the JMS action automatically whenever
> > a workflow
> > > >>> transitions
> > > >
> > > >>> to it.
> > > >>>
> > > >>> Seems like what I need is the <initial-actions> stanza within a
> > > > <step>
> > > >>> definition..
> > > >>> That would allow the specified actions to occur whenever a
> > > >>> transition
> > > >
> > > >>> is performed
> > > >>> to that step.
> > > >>>
> > > >>> What do you think? How hard woud that be?
> > > >>>
> > > >>> Can you think or any workarounds given the current model? There
> > > >>> doesn't seem to be any hook in the <step> definition that would
> > > >>> allow me to perform an action.. Makes
> > > >>> it very difficult to use the product for workflows that are
> > > >>> "automatic" sorts of
> > > >>> background flows, as opposed to users performing
> > actions directly.
> > > >>>
> > > >>> -Greg
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> -------------------------------------------------------
> > > >>> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> > > > Clara
> > > >>> The only event dedicated to issues related to Linux enterprise
> > > >>> solutions www.enterpriselinuxforum.com
> > > >>>
> > > >>> _____________________________________________
> > > > __
> > > >>> Opensymphony-developers mailing list
> > > >>> [email protected]
> > > >>>
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-develope
> > > >>> rs
> > > >
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> -------------------------------------------------------
> > > >> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> > > >> Clara The only event dedicated to issues related to Linux
> > > >> enterprise
> > > > solutions
> > > >> www.enterpriselinuxforum.com
> > > >>
> > > >> _______________________________________________
> > > >> Opensymphony-developers mailing list
> > > >> [email protected]
> > > >>
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-developer
> > > >> s
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> -------------------------------------------------------
> > > >> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> > > >> Clara The only event dedicated to issues related to Linux
> > > >> enterprise
> > > > solutions
> > > >> www.enterpriselinuxforum.com
> > > >>
> > > >> _______________________________________________
> > > >> Opensymphony-developers mailing list
> > > >> [email protected]
> > > >>
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-developer
> > > >> s
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> > > > Clara The only event dedicated to issues related to Linux
> > enterprise
> > > > solutions www.enterpriselinuxforum.com
> > > >
> > > > _______________________________________________
> > > > Opensymphony-developers mailing list
> > > > [email protected]
> > > >
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-deve
> lopers
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
> > > Clara The only event dedicated to issues related to Linux enterprise
> > > solutions www.enterpriselinuxforum.com
> > >
> > > _______________________________________________
> > > Opensymphony-developers mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
> > >
> >
> >
> >
> > -------------------------------------------------------
> > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> > The only event dedicated to issues related to Linux enterprise
> > solutions www.enterpriselinuxforum.com
> >
> > _______________________________________________
> > Opensymphony-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The
only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
>
> _______________________________________________
> Opensymphony-developers mailing list
[email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com