You are viewing a plain text version of this content. The canonical link for it is here.
Posted to agila-dev@incubator.apache.org by Ramil Jason Yao <ry...@exist.com> on 2005/01/20 05:35:49 UTC
Subprocess Support
Just joined the mailing list :)
I'm currently working on the subprocess support for Agila,
any ideas on how to approach this?
Ramil
Re: Subprocess Support
Posted by Glenn J Gonzales <gg...@exist.com>.
>>
>
> There's a couple of things I'd like to see :
>
> 1) Simplicity
> 2) We need to add a 'parentID' field for instances, so we can find
> who's responsible for starting things, and also allow parent processes
> to do things like wait for completion of children/subprocesses
This is a good idea :)
> 3) Security - we need to be able to ensure that starting a subprocess
> is a controlled thing, so that a process needs the permissions to do
> this. The default could be "ok" with an option to turn off, but this
> ensures that processes can't make a mess.
>
I'm not sure what you mean by a process having permissions -- how do you
check for it/grant it? Or is it a global setting that the engine will
check, and if it's on, will allow processes to spawn child processes?
> The problem is fairly straightforward - just be able to call the
> ususal API to start a process w/ a map of input data.
>
> geir
>
>
>
>> Ramil
>
Re: Subprocess Support
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jan 20, 2005, at 12:35 AM, Ramil Jason Yao wrote:
>
> Just joined the mailing list :)
>
> I'm currently working on the subprocess support for Agila,
> any ideas on how to approach this?
>
There's a couple of things I'd like to see :
1) Simplicity
2) We need to add a 'parentID' field for instances, so we can find
who's responsible for starting things, and also allow parent processes
to do things like wait for completion of children/subprocesses
3) Security - we need to be able to ensure that starting a subprocess
is a controlled thing, so that a process needs the permissions to do
this. The default could be "ok" with an option to turn off, but this
ensures that processes can't make a mess.
The problem is fairly straightforward - just be able to call the ususal
API to start a process w/ a map of input data.
geir
> Ramil
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Subprocess Support
Posted by Glenn J Gonzales <gg...@exist.com>.
Could you also show WorkflowService? Was that also a patch that you
submitted?
jastrachan@mac.com wrote:
> Its pretty trivial really...
>
> import org.apache.agila.model.Connection;
> import org.apache.agila.model.NodeContext;
> import org.apache.agila.model.node.BaseNodeImpl;
>
> import java.util.Map;
>
> /**
> * Starts a new workflow instance of the given name with the same
> instance data as this workflow by default
> *
> * @version $Revision: 1.1 $
> */
> public class StartWorkflowTask extends BaseNodeImpl {
> private String workflowName;
>
> public String getWorkflowName() {
> return workflowName;
> }
>
> public void setWorkflowName(String workflowName) {
> this.workflowName = workflowName;
> }
>
> public boolean doStart(NodeContext context) {
> WorkflowService.getInstance().startWorkflow(getWorkflowName(),
> getNewWorkflowInstanceData(context));
> return true;
> }
>
> public Connection[] doEnd(NodeContext ctx) {
> return getOutboundConnections();
> }
>
> protected Map getNewWorkflowInstanceData(NodeContext context) {
> return context.getInstanceData();
> }
> }
>
>
> Then to use it in the XML...
>
> <node id="4" type="activity" class="StartWorkflowTask"
> display_name="Start the Foo workflow">
> <property name="workflowName" value="Foo"/>
>
> <actors>
> <actor name="Self"/>
> </actors>
> </node>
>
> though the above is dependent on my previous patch to allow property
> setting on tasks, so that you can set the workflow name you want to
> start easily from inside the XML
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: Subprocess Support
Posted by Ramil Jason Yao <ry...@exist.com>.
This is great, hope we can get the patches ready so we can play with it..
As you can see, Glenn's pretty excited :)
Ramil
----- Original Message -----
From: <ja...@mac.com>
To: <ag...@incubator.apache.org>
Sent: Thursday, January 20, 2005 4:26 PM
Subject: Re: Subprocess Support
>
> On 20 Jan 2005, at 08:11, Glenn J Gonzales wrote:
>> jastrachan@mac.com wrote:
>>
>>>
>>> What do you mean by sub-process? Starting a child workflow process?
>>>
>>> FWIW I"ve a StartWorkflowTask which I could submit (as well as a
>>> boolean decision node), once my previous patch is applied :)
>>>
>>> James
>>> -------
>>> http://radio.weblogs.com/0112098/
>>>
>> Interesting, how does the StartWorkflowTask work?
>
> Its pretty trivial really...
>
> import org.apache.agila.model.Connection;
> import org.apache.agila.model.NodeContext;
> import org.apache.agila.model.node.BaseNodeImpl;
>
> import java.util.Map;
>
> /**
> * Starts a new workflow instance of the given name with the same
> instance data as this workflow by default
> *
> * @version $Revision: 1.1 $
> */
> public class StartWorkflowTask extends BaseNodeImpl {
> private String workflowName;
>
> public String getWorkflowName() {
> return workflowName;
> }
>
> public void setWorkflowName(String workflowName) {
> this.workflowName = workflowName;
> }
>
> public boolean doStart(NodeContext context) {
> WorkflowService.getInstance().startWorkflow(getWorkflowName(),
> getNewWorkflowInstanceData(context));
> return true;
> }
>
> public Connection[] doEnd(NodeContext ctx) {
> return getOutboundConnections();
> }
>
> protected Map getNewWorkflowInstanceData(NodeContext context) {
> return context.getInstanceData();
> }
> }
>
>
> Then to use it in the XML...
>
> <node id="4" type="activity" class="StartWorkflowTask"
> display_name="Start the Foo workflow">
> <property name="workflowName" value="Foo"/>
>
> <actors>
> <actor name="Self"/>
> </actors>
> </node>
>
> though the above is dependent on my previous patch to allow property
> setting on tasks, so that you can set the workflow name you want to
> start easily from inside the XML
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: Question re: Task constants
Posted by Glenn J Gonzales <gg...@exist.com>.
Here's a fix, which follows the conditional in getTasksForInstance(). It
also removes the redundant status methods in TaskImpl.
Cheers,
Glenn
Geir Magnusson Jr wrote:
>
> On Mar 9, 2005, at 5:19 AM, Glenn J Gonzales wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>>
>>> On Mar 7, 2005, at 4:16 AM, Glenn J Gonzales wrote:
>>>
>>>> In org.apache.agila.services.task.Task:
>>>>
>>>> public final static int TASK_CANCELLED = 0x03;
>>>>
>>>> shouldn't this be public final static int TASK_CANCELLED = 0x04; ?
>>>
>>>
>>>
>>> Why? it's not a bitmap. They are exclusive values.... Am I
>>> missing something?
>>>
>> Sorry, was unable to include my reason for asking in my previous
>> post, must have been dazed or hurrying home :) Anyway, I was just
>> asking because in the memory implementation of the task service, the
>> code uses bit-AND to know which task to add:
>>
>> if ( (ti.getStatus() & type) > 0)
>>
>> which would include a cancelled task regardless of the value of type
>> (assuming it was one of the constants in the Task interface).
>
>
> Ah, yes. We definitely have to fix this.
>
>>
>>
Re: Question re: Task constants
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 9, 2005, at 5:19 AM, Glenn J Gonzales wrote:
> Geir Magnusson Jr wrote:
>
>>
>> On Mar 7, 2005, at 4:16 AM, Glenn J Gonzales wrote:
>>
>>> In org.apache.agila.services.task.Task:
>>>
>>> public final static int TASK_CANCELLED = 0x03;
>>>
>>> shouldn't this be public final static int TASK_CANCELLED = 0x04;
>>> ?
>>
>>
>> Why? it's not a bitmap. They are exclusive values.... Am I missing
>> something?
>>
> Sorry, was unable to include my reason for asking in my previous post,
> must have been dazed or hurrying home :) Anyway, I was just asking
> because in the memory implementation of the task service, the code
> uses bit-AND to know which task to add:
>
> if ( (ti.getStatus() & type) > 0)
>
> which would include a cancelled task regardless of the value of type
> (assuming it was one of the constants in the Task interface).
Ah, yes. We definitely have to fix this.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
[PATCH] DAO and Memory Implementation of subprocess-related methods
Posted by Ramil Jason Yao <ry...@exist.com>.
Hi,
I'm submitting a patch related to how the subprocess execution works. The
parent instance's token is saved using the child instance's id so that it
can be later retrieved and resume its execution upon completion of the child
instance. Before, I used to store the parent's token only in memory, or in a
map, and realized that it needed to be implemented to work both in memory
and in the DB, just like the other methods (internalCreate,
internalSave...). The patches I attached include both memory and dao
implementations.
Ramil
Re: Question re: Task constants
Posted by Glenn J Gonzales <gg...@exist.com>.
Geir Magnusson Jr wrote:
>
> On Mar 7, 2005, at 4:16 AM, Glenn J Gonzales wrote:
>
>> In org.apache.agila.services.task.Task:
>>
>> public final static int TASK_CANCELLED = 0x03;
>>
>> shouldn't this be public final static int TASK_CANCELLED = 0x04; ?
>
>
> Why? it's not a bitmap. They are exclusive values.... Am I missing
> something?
>
Sorry, was unable to include my reason for asking in my previous post,
must have been dazed or hurrying home :) Anyway, I was just asking
because in the memory implementation of the task service, the code uses
bit-AND to know which task to add:
if ( (ti.getStatus() & type) > 0)
which would include a cancelled task regardless of the value of type
(assuming it was one of the constants in the Task interface).
Re: Question re: Task constants
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 7, 2005, at 4:16 AM, Glenn J Gonzales wrote:
> In org.apache.agila.services.task.Task:
>
> public final static int TASK_CANCELLED = 0x03;
>
> shouldn't this be public final static int TASK_CANCELLED = 0x04; ?
Why? it's not a bitmap. They are exclusive values.... Am I missing
something?
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@gluecode.com
Question re: Task constants
Posted by Glenn J Gonzales <gg...@exist.com>.
In org.apache.agila.services.task.Task:
public final static int TASK_CANCELLED = 0x03;
shouldn't this be public final static int TASK_CANCELLED = 0x04; ?
[PATCH] user service
Posted by Glenn J Gonzales <gg...@exist.com>.
Here's a patch for the UserService, along with a file properties
implementation. Also included is a file properties implementation of the
ActorResolver patch I submitted earlier. These are sample
implementations to show the intent of the changes. I can submit the
memory and dao implementations if necessary.
What's changed is that the user service methods are now only getXXX
methods, because (as Geir mentioned before), the service is only
involved with providing user info to the bpm system and not in managing
it, although an implementation could decide to do that also. Not all of
the methods are necessary (as for example, if you have a system that has
only users and no grouping, or vice versa), but are provided for
flexibility. I also added the GroupInfo class, extended from Info, to
provide the group data. The UserInfo was also changed to extend Info.
in UserService.java:
/**
* Get the group info given a group principal name.
*
* @param principalName
* @return the GroupInfo of the group associated with
<code>principalName</code>
*/
public GroupInfo getGroupFromPrincipal(String principalName);
/**
* Get all group infos from this service.
*
* @return a list of GroupInfo of all groups in this service.
*/
public List listAllGroupInfo();
/**
* Get the users that belong to a given group.
*
* @param groupId
* @return array of UserInfo of users belonging to group with id
<code>groupId</code>.
*/
public UserInfo[] getUsers(GroupID groupId);
/**
* Get the groups that this user belongs to.
*
* @param userId
* @return array of GroupInfo of groups that have the user with id
<code>userId</code> as a member.
*/
public GroupInfo[] getGroups(UserID userId);
/**
* Get the user info given the username.
*
* @param userName
* @return UserInfo of the user with name <code>userName</code>
*/
public UserInfo getUserInfo(String userName);
/**
* Get the group info given the group id.
*
* @param groupId
* @return GroupInfo of group with id <code>groupId</code>
*/
public GroupInfo getGroupInfo(GroupID groupId);
/**
* Get the group info given a group name.
*
* @param groupName
* @return GroupInfo of group with name <code>groupName</code>.
*/
public GroupInfo getGroupInfo(String groupName);
Re: [PATCH] privatedata support
Posted by ja...@mac.com.
Note that if my previous patch is applied, it allows any (primitive
type) based property to be set on any type of Node, so rather than
having a ConfigurableNode with a generic private data parameter, you'd
be able set explicitly typed properties on the Node. (i.e. dependency
injection, rather than the node having to pull stuff from a list of
Elements).
<node class="Foo">
<property name="name" value="James"/>
...
The other extension to this is to provide a neat integration into
containers like Spring, HIveMind, Pico using a named reference
<!-- look up the customer DataSource in Spring -->
<property name="dataSource" ref="customerDB"/>
On 21 Jan 2005, at 10:14, Glenn J Gonzales wrote:
> Attached is a patch from Ramil (ryao@exist.com) for privatedata
> support.
> Index: org/apache/agila/model/node/ConfigurableNode.java
> ===================================================================
> --- org/apache/agila/model/node/ConfigurableNode.java (revision 0)
> +++ org/apache/agila/model/node/ConfigurableNode.java (revision 0)
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright 2004 The Apache Software Foundation.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License")
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +package org.apache.agila.model.node;
> +
> +import java.util.List;
> +
> +/**
> + * Abstract class for a node that can load a custom configuration.
> + *
> + * @author <a href="mailto:ryao@exist.com>Ramil Jason Yao</a>
> + */
> +public abstract class ConfigurableNode extends BaseNodeImpl {
> +
> + private Object privatedata;
> +
> + /**
> + * Load the configuration contained in the list parameter into
> this node.
> + *
> + * @param list
> + * @return
> + */
> + public abstract Object loadPrivateData(List list);
> +
> + /**
> + * Sets this node's configuration data to the privatedata
> parameter.
> + *
> + * @param privatedata
> + */
> + public void setPrivateData(Object privatedata) {
> + this.privatedata = privatedata;
> + }
> +
> + /**
> + * @return this node's configuration data
> + */
> + public Object getPrivateData() {
> + return privatedata;
> + }
> +}
> Index: org/apache/agila/util/XMLUtil.java
> ===================================================================
> --- org/apache/agila/util/XMLUtil.java (revision 125910)
> +++ org/apache/agila/util/XMLUtil.java (working copy)
> @@ -24,6 +24,7 @@
>
> import org.apache.agila.model.Variable;
> import org.apache.agila.model.NodeID;
> +import org.apache.agila.model.node.ConfigurableNode;
>
> import org.apache.agila.impl.BusinessProcessImpl;
> import org.dom4j.io.SAXReader;
> @@ -217,6 +218,17 @@
>
> n.addBinding(binding);
> }
> +
> + // If node has private data, load it and then set it
> + if (n instanceof ConfigurableNode){
> +
> + List privateDataList = node.selectNodes("privatedata/*");
> +
> + if(privateDataList != null) {
> +
> ((ConfigurableNode)n).setPrivateData(((ConfigurableNode)n).loadPrivateD
> ata(privateDataList));
> + }
> + }
> +
> graph.addNode(n);
>
> }
James
-------
http://radio.weblogs.com/0112098/
[PATCH] privatedata support
Posted by Glenn J Gonzales <gg...@exist.com>.
Attached is a patch from Ramil (ryao@exist.com) for privatedata support.
Re: Subprocess Support
Posted by ja...@mac.com.
On 21 Jan 2005, at 09:16, Glenn J Gonzales wrote:
> jastrachan@mac.com wrote:
>
>> As it happens in this particular case, it was just a simple helper
>> method we could include directly in the context, Engine or node
>>
>> BusinessProcessID businessProcessID =
>> context.getBusinessProcessService().getGraphIDByName(name);
>> context.getEngine().startNewInstance(businessProcessID.getID(),
>> requiredVariables);
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
> I was thinking more along the lines of:
> NodeContext.startChildInstance( ... ), where NodeContext uses the
> engine to start the instance, and then uses the instance service so it
> (the instance service) could track the newly created process as a
> child of the originating instance. This way we don't have to expose
> the engine to the nodes.
Sounds good with me - it'd also mean that the parent/child relationship
could be auto-maintained
James
-------
http://radio.weblogs.com/0112098/
Re: Subprocess Support
Posted by Glenn J Gonzales <gg...@exist.com>.
jastrachan@mac.com wrote:
> As it happens in this particular case, it was just a simple helper
> method we could include directly in the context, Engine or node
>
> BusinessProcessID businessProcessID =
> context.getBusinessProcessService().getGraphIDByName(name);
> context.getEngine().startNewInstance(businessProcessID.getID(),
> requiredVariables);
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
I was thinking more along the lines of: NodeContext.startChildInstance(
... ), where NodeContext uses the engine to start the instance, and then
uses the instance service so it (the instance service) could track the
newly created process as a child of the originating instance. This way
we don't have to expose the engine to the nodes.
Re: Subprocess Support
Posted by ja...@mac.com.
On 20 Jan 2005, at 11:52, Geir Magnusson Jr. wrote:
> On Jan 20, 2005, at 3:26 AM, jastrachan@mac.com wrote:
>
>>
>> public boolean doStart(NodeContext context) {
>>
>> WorkflowService.getInstance().startWorkflow(getWorkflowName(),
>> getNewWorkflowInstanceData(context));
>> return true;
>> }
>
> Full disclosure - I hate the singleton anti-pattern :)
Me too - the only reason the singleton was there was Agila is the only
place in our app where we can't use dependency injection (we use spring
to do all dependency injection to avoid needing to use statics), so we
had to hack a few singletons in there, just for the Agila nodes!
I'm still waiting for the <property> patch from November to be applied,
so I didn't wanna overload the list with yet more patches, but another
patch coming along soon is to be able to use dependency injection in
the configuration of Nodes, to be able to inject things like database
connections & other services. e.g.
<node ...>
<property name="dataSource" ref="customerDB"/>
which would use a pluggable InjectorService to resolve dependencies;
such as a Spring version, a HiveMind version, Pico, JNDI etc.
As it happens in this particular case, it was just a simple helper
method we could include directly in the context, Engine or node
BusinessProcessID businessProcessID =
context.getBusinessProcessService().getGraphIDByName(name);
context.getEngine().startNewInstance(businessProcessID.getID(),
requiredVariables);
James
-------
http://radio.weblogs.com/0112098/
Re: Subprocess Support
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jan 20, 2005, at 3:26 AM, jastrachan@mac.com wrote:
>
> public boolean doStart(NodeContext context) {
> WorkflowService.getInstance().startWorkflow(getWorkflowName(),
> getNewWorkflowInstanceData(context));
> return true;
> }
Full disclosure - I hate the singleton anti-pattern :)
I'd like to see this go through the context, rather than pull an
instance out of thin air, as this will lead to problems (I think) w/
containment, meaning we have to be careful about classloader stuff.
so something like right from the Engine.java class :
public InstanceID startNewInstance(int processID, Map params);
and add an optional by-name overload as well.
This way, the engine can veto if the caller doesn't have permission...
Second, we need a general mechanism for "end of execution" events. In
engines I've done in the past, I always put in a system where the
creator could specify how they wanted to be notified that the work was
complete.
Typically, this is an external creator - i.e. triggered from outside -
rather than internal, and the usual mechanism was a lifecycle event API
that given a URL, posted a predefined XML message to the URL given.
The contents were dependent upon what happened - failure of processing
(some sort of abnormal termination) or completion (returning a
workflow-defined result code).
In this case, we'd extend it and instead of a URL, we'd indicate that
it's a "PARENT WAIT" or something, and the engine would post a message
for that instance into the message queue, which would continue via
doEnd()
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Subprocess Support
Posted by ja...@mac.com.
On 20 Jan 2005, at 08:32, Christopher Lim wrote:
>> Then to use it in the XML...
>>
>> <node id="4" type="activity" class="StartWorkflowTask"
>> display_name="Start the Foo workflow">
>> <property name="workflowName" value="Foo"/>
>>
>> <actors>
>> <actor name="Self"/>
>> </actors>
>> </node>
>>
>
> I guess the <property> tag needs to be enhanced to be able to pass
> variables into the sub process.
Currently the task just passes in the current instance data; so you
could add new <binding> tags inside this node, to create new instance
variables, which would then be passed into the child workflow. So it
might just work already - though I've not tested this :)
James
-------
http://radio.weblogs.com/0112098/
Re: Subprocess Support
Posted by Christopher Lim <ch...@gmail.com>.
> Then to use it in the XML...
>
> <node id="4" type="activity" class="StartWorkflowTask"
> display_name="Start the Foo workflow">
> <property name="workflowName" value="Foo"/>
>
> <actors>
> <actor name="Self"/>
> </actors>
> </node>
>
I guess the <property> tag needs to be enhanced to be able to pass
variables into the sub process.
Chris
Re: Subprocess Support
Posted by ja...@mac.com.
On 20 Jan 2005, at 08:11, Glenn J Gonzales wrote:
> jastrachan@mac.com wrote:
>
>>
>> What do you mean by sub-process? Starting a child workflow process?
>>
>> FWIW I"ve a StartWorkflowTask which I could submit (as well as a
>> boolean decision node), once my previous patch is applied :)
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
> Interesting, how does the StartWorkflowTask work?
Its pretty trivial really...
import org.apache.agila.model.Connection;
import org.apache.agila.model.NodeContext;
import org.apache.agila.model.node.BaseNodeImpl;
import java.util.Map;
/**
* Starts a new workflow instance of the given name with the same
instance data as this workflow by default
*
* @version $Revision: 1.1 $
*/
public class StartWorkflowTask extends BaseNodeImpl {
private String workflowName;
public String getWorkflowName() {
return workflowName;
}
public void setWorkflowName(String workflowName) {
this.workflowName = workflowName;
}
public boolean doStart(NodeContext context) {
WorkflowService.getInstance().startWorkflow(getWorkflowName(),
getNewWorkflowInstanceData(context));
return true;
}
public Connection[] doEnd(NodeContext ctx) {
return getOutboundConnections();
}
protected Map getNewWorkflowInstanceData(NodeContext context) {
return context.getInstanceData();
}
}
Then to use it in the XML...
<node id="4" type="activity" class="StartWorkflowTask"
display_name="Start the Foo workflow">
<property name="workflowName" value="Foo"/>
<actors>
<actor name="Self"/>
</actors>
</node>
though the above is dependent on my previous patch to allow property
setting on tasks, so that you can set the workflow name you want to
start easily from inside the XML
James
-------
http://radio.weblogs.com/0112098/
Re: Subprocess Support
Posted by Glenn J Gonzales <gg...@exist.com>.
jastrachan@mac.com wrote:
>
> What do you mean by sub-process? Starting a child workflow process?
>
> FWIW I"ve a StartWorkflowTask which I could submit (as well as a
> boolean decision node), once my previous patch is applied :)
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Interesting, how does the StartWorkflowTask work?
Re: Subprocess Support
Posted by ja...@mac.com.
On 20 Jan 2005, at 05:35, Ramil Jason Yao wrote:
> Just joined the mailing list :)
>
> I'm currently working on the subprocess support for Agila,
> any ideas on how to approach this?
What do you mean by sub-process? Starting a child workflow process?
FWIW I"ve a StartWorkflowTask which I could submit (as well as a
boolean decision node), once my previous patch is applied :)
James
-------
http://radio.weblogs.com/0112098/
Re: Subprocess Support
Posted by Glenn J Gonzales <gg...@exist.com>.
Geir Magnusson Jr. wrote:
>
> I'd prefer a mechanism outside of the workflow graph itself - IOW,
> don't depend on the stopnode to do the right thing, because there is
> no guarantee you'll ever get there. The execution of the workflow
> could bomb, for example, in which case you won't get there, but you
> want the parent to know and continue.
>
> Further, outside control actions like stopping execution would also
> mean you don't get to a 'stop'.
>
Ah yes that's right. Speaking about stopping execution -- when a parent
instance is stopped, does it also mean that all child instances should
be stopped? It may make no sense to let the child instances continue if
an admin wants to stop the originating instance.
> In a previous message I outlined a way I've done this before, and it
> worked well. I think we should do a similar thing here.
Which one?
>
> The thing I did forget to mention is return data - how a subprocess
> communicates information back to the parent. There are two ways - a
> cleanly executing workflow can return data from it's stop node somehow
> - once a "stop"-type node is done executing, the engine can query it
> for return data, somehow package that up, and make it available to the
> client.
>
> A second way is to allow anyone w/ the right permission to get data at
> any time from a workflow.
>
> This is actually a specific case of a general feature I'd like to see,
> namely associate w/ every workflow an optional 'helper' class, one
> that can return semantically meaningful representations of the
> business state of the process.
This is what the logging service that Chris was talking about is
supposed to do. There was a disconnect with what kind of "logging" Chris
meant and the normal meaning (which is output). If you'll see from his
submission, the log service accepts business process state and produces
a Log object that stores it for when such information will be needed.
> Why? Because you may want to provide business summary inforamtion
> about the state of an instance, and can't expect a non-programmer
> (like a business-analyst or call-center person) to read the state data
> and derive something meaningful.
>
> So given that I haven't had a lot of coffee, and expect the above to
> be gibberish, let me try to sketch in code.
>
> There will be an interface :
>
> public interface SantasLittleHelper {
>
> public Map getReturnData();
>
> public Map getRawInstanceData();
>
> public Map getMeaningfulInstanceData();
>
> // and even provide the Renderer interface that tasks have so
> that a Helper can return a Renderer that can show something prettier,
> like HTML, portlet, etc
> }
>
> Then, you could produce an admin interface that given an instance,
> calls the helper, and the helper looks at the instance data, and
> returns a meaningful summary. Like I noted, we can even let it
> optionally provide renderers like tasks do so that they can format an
> appropriate presentation of the state for a business user.
Re: Subprocess Support
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jan 20, 2005, at 3:37 AM, Glenn J Gonzales wrote:
> Starting a subprocess involves:
>
> 1. Starting the new (sub) process instance -- obviously you don't want
> it to be done by the node because that would mean exposing services
> that shouldn't be exposed -- which means it has to be done inside of
> the core. (where?)
Well, the node can invoke it, through the NodeContext, using it's
containing Engine instance's API.
>
> 2. Once the subprocess has been started, you have to watch for it to
> end, find the token for the subprocess node, create an engine message
> and shoot it off to the queue. You also have to do a mapping-out of
> variable values that were mapped into the subprocess.
>
> I'm suggesting an approach similar to the one I suggested with the
> synchronizing nodes (forks/joins): inside doStart( ) of the subprocess
> node, it registers itself to the NodeContext as containing business
> process information that should be started (it returns false). The
> node context looks around and sends that information to another
> service, which stores token info and the subprocess data.
>
> That service then starts the process using the Agila engine, setting
> the variable mappings (from the orginial process) and adding an
> Agila-reserved variable into the subprocess. It then waits for a
> signal that the subprocess has finished so that it can create the
> engine message that would allow the original process to proceed from
> the subprocess node.
>
> I'm suggesting we modify the Agila StopNode so that it checks for that
> Agila-reserved variable and if it finds it, it would tell the
> NodeContext that it's part of a subprocess. The NodeContext then gives
> the variable value to the service, which uses it to look for the right
> node/token, creates the proper engine message and shoots it off to the
> queue, thus letting the original process pick up where it left off.
I'd prefer a mechanism outside of the workflow graph itself - IOW,
don't depend on the stopnode to do the right thing, because there is no
guarantee you'll ever get there. The execution of the workflow could
bomb, for example, in which case you won't get there, but you want the
parent to know and continue.
Further, outside control actions like stopping execution would also
mean you don't get to a 'stop'.
In a previous message I outlined a way I've done this before, and it
worked well. I think we should do a similar thing here.
The thing I did forget to mention is return data - how a subprocess
communicates information back to the parent. There are two ways - a
cleanly executing workflow can return data from it's stop node somehow
- once a "stop"-type node is done executing, the engine can query it
for return data, somehow package that up, and make it available to the
client.
A second way is to allow anyone w/ the right permission to get data at
any time from a workflow.
This is actually a specific case of a general feature I'd like to see,
namely associate w/ every workflow an optional 'helper' class, one that
can return semantically meaningful representations of the business
state of the process. Why? Because you may want to provide business
summary inforamtion about the state of an instance, and can't expect a
non-programmer (like a business-analyst or call-center person) to read
the state data and derive something meaningful.
So given that I haven't had a lot of coffee, and expect the above to be
gibberish, let me try to sketch in code.
There will be an interface :
public interface SantasLittleHelper {
public Map getReturnData();
public Map getRawInstanceData();
public Map getMeaningfulInstanceData();
// and even provide the Renderer interface that tasks have so that
a Helper can return a Renderer that can show something prettier, like
HTML, portlet, etc
}
Then, you could produce an admin interface that given an instance,
calls the helper, and the helper looks at the instance data, and
returns a meaningful summary. Like I noted, we can even let it
optionally provide renderers like tasks do so that they can format an
appropriate presentation of the state for a business user.
>
> Cheers,
> Glenn
>
> Ramil Jason Yao wrote:
>
>> Just joined the mailing list :)
>>
>> I'm currently working on the subprocess support for Agila, any ideas
>> on how to approach this?
>>
>> Ramil
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Subprocess Support
Posted by Glenn J Gonzales <gg...@exist.com>.
Starting a subprocess involves:
1. Starting the new (sub) process instance -- obviously you don't want
it to be done by the node because that would mean exposing services that
shouldn't be exposed -- which means it has to be done inside of the
core. (where?)
2. Once the subprocess has been started, you have to watch for it to
end, find the token for the subprocess node, create an engine message
and shoot it off to the queue. You also have to do a mapping-out of
variable values that were mapped into the subprocess.
I'm suggesting an approach similar to the one I suggested with the
synchronizing nodes (forks/joins): inside doStart( ) of the subprocess
node, it registers itself to the NodeContext as containing business
process information that should be started (it returns false). The node
context looks around and sends that information to another service,
which stores token info and the subprocess data.
That service then starts the process using the Agila engine, setting the
variable mappings (from the orginial process) and adding an
Agila-reserved variable into the subprocess. It then waits for a signal
that the subprocess has finished so that it can create the engine
message that would allow the original process to proceed from the
subprocess node.
I'm suggesting we modify the Agila StopNode so that it checks for that
Agila-reserved variable and if it finds it, it would tell the
NodeContext that it's part of a subprocess. The NodeContext then gives
the variable value to the service, which uses it to look for the right
node/token, creates the proper engine message and shoots it off to the
queue, thus letting the original process pick up where it left off.
Cheers,
Glenn
Ramil Jason Yao wrote:
>Just joined the mailing list :)
>
>I'm currently working on the subprocess support for Agila,
>any ideas on how to approach this?
>
>Ramil
>
>