Re: 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-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
> >
> > _______________________________________________
> > 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