Re: OSWorkflow - initial actionforsteps?

I'll try to find some time this weekend to implement autoactions, no 
promises, but based on the discussions on here, I don't anticipate that 
it'd be too hard or take too long.

Is there anything else that people desperately need to be in the 2.5 
release?

On Friday, May 9, 2003, at 12:30 PM, Axel Müller wrote:

> Greg,
>
> Thanks a lot for your offer. Since I need a solution soon (within 5-7 
> days) I may go your way.
> Right now I'm  still hoping we can get the auto-action feature into 
> OSWF.
>
> Axel
>
>
> Greg Nyberg wrote:
>
>> I needed the auto-action feature immediately, also, so I created a 
>> utility
>> class called "DoAction" that I put in the post-functions block of 
>> whichever
>> action moves to the next step. The DoAction function is passed the 
>> action ID
>> to invoke, and it simply calls doAction with that ID on the workflow..
>>
>>        <action id="202" name="Complete Step 2">
>>          <restrict-to>
>>            <conditions type="AND">
>>              <condition type="class">
>>                <arg
>> name="class.name">com.opensymphony.workflow.util.StatusCondition</arg>
>>                <arg name="status">JMSWait</arg>
>> 		    <arg name="stepId">2</arg>
>>              </condition>
>>            </conditions>
>>          </restrict-to>
>>          <results>
>>            <unconditional-result old-status="Finished" 
>> status="Underway"
>> step="3">
>> 		  <post-functions>
>> 		    <function type="class">
>> 		      <arg 
>> name="class.name">com.opensymphony.workflow.util.DoAction</arg>
>> 		      <arg name="action">301</arg> <!-- action I want to auto 
>> invoke -->
>> 		    </function>
>> 		  </post-functions>
>> 		</unconditional-result>
>>          </results>
>>        </action>
>>
>> Essentially the same as auto-action for action 301 in step 3 except I 
>> have
>> to put these DoAction functions all over on the source side of the 
>> state
>> transition.. works but not as clean as having 301 know it should be
>> automatically performed.
>>
>> This technique also doesn't work in joins in the CVS HEAD (until my 
>> patch
>> gets put in) and doesn't work in initial actions for the workflow 
>> because of
>> an entry-id race condition (cant process the first real step action 
>> before
>> workflow is saved, chicken and egg problem).
>>
>> Let me know if you want my DoAction class.
>>
>> -Greg
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]]On Behalf 
>> Of
>> Axel Muller
>> Sent: Friday, May 09, 2003 9:42 AM
>> To: Hani Suleiman
>> Cc: [email protected]
>> Subject: Re: [Opensymphony-developers] OSWorkflow - initial
>> actionforsteps?
>>
>>
>> You are right about the risk of additional complexity. However, 
>> adding a
>> rule engine on top of OSWF (as sugested by Pat) adds a lot more 
>> complexity.
>> I see the "auto"-action feature as improvement toward rule engine, 
>> which
>> might be added later. So, yes - you have to know what you do if you 
>> set
>> "auto=yes" for actions, but you don't have to study the rule engine
>> features just to get actions performed automatically.
>>
>> Right now actions have to have unique ids - a rule which has to be
>> respected by the person implementing the workflow definition. The
>> auto-action feature adds just one more rule: If there is more than one
>> valid action with"auto=yes", then the one with the lowest action id 
>> gets
>> executed. If would say that the power this feature adds to OSWF far
>> outweights the risk of using the attribute in a wrong context.
>>
>> Following the mailing list for 7 months and playing with the example I
>> was not even aware that there are only manual actions.
>> Whenever you have an environment with mixed computer-human-processing
>> you need kind of a auto-action feature. For the project I'm involved
>> with we need it even within days ... . Whatever comes out of this
>> discussion will help to find a solution, which fits into the current
>> OSWF but makes it more powerful. This is not theory - it's what's 
>> needed
>> in real-life.
>>
>> Axel
>>
>>
>> Hani Suleiman wrote:
>>
>>
>>> I don't agree with this, making it so that the first match is what's
>>> done seems an arbitrary solution, and is bound to confuse a lot of
>>> people....'I set my action to auto and I'm sure its condition passes,
>>> but it doesn't get called..help!'
>>>
>>> On Friday, May 9, 2003, at 03:44 AM, Hubert Felber wrote:
>>>
>>>
>>>> <I don't understand how "auto=yes" would cause actions to be 
>>>> invoked?
>>>> Would
>>>> <they just happen once the step that has that action is entered in 
>>>> the
>>>> <workflow? What if there are two actions with auto=yes?
>>>>
>>>> Just some thoughts:
>>>>
>>>> Actions with "auto=yes" are are called every time a transition to 
>>>> that
>>>> step is made. It's the programmers responsability to use 
>>>> restrictions
>>>> that control execution of "auto" actions.
>>>>
>>>> <What happens if two conditions evaluate to true? Do you have a 
>>>> split?
>>>>
>>>> Same as for conditional-results, only the first "auto" action with
>>>> restrictions that are fullfilled, is executed. Splits always must be
>>>> defined in results.
>>>>
>>>> Does that make sense?
>>>>
>>>> Hubert
>>>>
>>>>
>>>>
>>>>
>>>>>>> "Pat Lightbody" <[email protected]> 05/09/03 03:24am >>>
>>>>>>>
>>>>> <but does it make sense to "auto"-call more than one action?
>>>>>
>>>>> You could have auto actions with different conditions.
>>>>>
>>>>> Hubert
>>>>>
>>>> What happens if two conditions evaluate to true? Do you have a 
>>>> split?
>>>>
>>>> -Pat
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> 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