Starting a future process

[Cheong Chung Onn]

Hi Paul,

Any plan about supporting the starting of a process scheduled in the
future? Do you have such usecase currently?

Regards
chung-onn

[Paul Lorenz]

I don't currently have a need for this, as we handle delays on tasks directly, rather than at the node level. So the task is generated by the node, and then delayed, rather than delaying execution of the node.

When you say starting a process in the future, I would think that the process starts now, but you have a means of delaying node execution (in this case, the start node), until some time in the future. Does this sound reasonable?

If so, I think this could be combined with the timeout feature that Vincent has a use for, where we have generic time event.

<node>
  <time-event type="first-execution">
    (5 days after someBusinessDate)
 </time-event>

  <time-event type="execution">
    (5 days after someBusinessDate)
 </time-event>

  <time-event type="event" id="foo">
    (5 days after someBusinessDate)
 </time-event>
</node>

If a node has an associated time event of type 'first-execution', it will not execute the node token when created, but will wait until the time specified by the rubric expression.

If the type is execution, the execute(..) method would be callled when the node token is created, and again when the time is hit. We might need a flag to control what happens if there isn't a node token active on that node anymore, by the time the date hits.

If the type is event, it calls a different method

Node.timeEvent( NodeToken token, String eventId)

Again, the behavior needs to be defined for when the timeout hits, but the token is no longer active.

We'll also need an interface for a TimeEventManager that handles invoking the methods at the appropriate time. Probably want to allow different implementations, one of which (perhaps the default), could use Quarts.

Finally, I want to see if this can be implemented without slowing down execution paths much in the case where this functionality  isn't used.

Let me know what you think.

cheers,
Paul

[Cheong Chung Onn]

Hi Paul,

Thanks for sharing your thoughts on the matter and giving such a
detailed explanation.

By starting future process, i actually mean starting the process later
in a future date. However, after reading your views, i do prefer your
approach as it allows other Nodes to have this Temporal sensitive
execution behavior. On the other hand, I am also mindful what PD's xml
offers i.e. it is cast on concrete, it can't be changed or configured
during runtime. To me this is both a good and a bad thing depending on
which side I am in.

Your example shows <time-event> is a child element of Node. I wonder
should <time-event> element be a sub-type of <guard> element?

I have an immediate need for this feature, my approach is to implement a
crontab service and periodically poll what are the outstanding tasks
needs to be started.

However after reading your approach, I am keen to work on it so that it
would benefit others with similar needs as well. There is however one
issue that is bothering me, how should the crontab service be
implemented? Should it be a standalone process or should it be in a JEE
container? What happens if this scheduling process is down? Should i
have yet another process monitoring it and respawn the scheduler when
needed. What's your thought on this?

Also I thought if sarasvati would to include a sort of IOC capability it
would make it even more flexible.

One other note, I have looked into Quartz, it looks good however I
thought we can push the envelope further by providing all these Time
related event stuff to use the iCalendar specs RFC 2445. Perhaps this
can be post 1.0 if we can get the basic Scheduling framework up first.

Finally, I have a less than a week to get this up, how do you think we
should approach this?

Regards
chung-onn

[Cheong Chung Onn]

Hi Paul,

I have decided to implement the future start process outside sarasvati
as I need to get it done within a week. This will give us more time to
decide on the approach/design.

Regards
chung-onn

[Paul Lorenz]

Response in-line.

On Sat, Aug 1, 2009 at 12:25 AM, Cheong Chung Onn <chun...@gmail.com> wrote:

Hi Paul,

Thanks for sharing your thoughts on the matter and giving such a
detailed explanation.

By starting future process, i actually mean starting the process later
in a future date. However, after reading your views, i do prefer your
approach as it allows other Nodes to have this Temporal sensitive
execution behavior. On the other hand, I am also mindful what PD's xml
offers i.e. it is cast on concrete, it can't be changed or configured
during runtime. To me this is both a good and a bad thing depending on
which side I am in.

I'm thinking that a <time-event> element is essentially a time event generated, and would be attached to a Node. When a token is generated on a node, the time events would then be generated and attached to the node token.

In pseudo code:

-- in process definition --
 <time-event type="event" id="foo" dateFormat="rubric">
     (5 days after tokenCreated)
  </time-event>
--------------------------------------------

-- when generating token --

for (TimeEventSpecifier t : node.getTimeEventSpecifiers () )
{
  token.addTimeEvent( new TimeEvent( t.getEventType(), t.getEventId(), t.evalTime( rulesContext ) );
}

if ( !token.hasInitialExecutionTimeEvent() )
{
  node.execute( this, token );
}

-----------------------------------------------

So it allows static definitions, but you could also add time events to the node token at run time.

 

Your example shows <time-event> is a child element of Node. I wonder
should <time-event> element be a sub-type of <guard> element?

Hmm, you can only have 1 guard. Maybe you could elaborate on this some more? Or did you want to be able to specify guards on time events?

<time-event ...>
  <if>Order.isExpedited or Customer.isGoldLevel</if>
  <time-out>(5 days after tokenCreated</time-out>
</time-event>

 

I have an immediate need for this feature, my approach is to implement a
crontab service and periodically poll what are the outstanding tasks
needs to be started.

However after reading your approach, I am keen to work on it so that it
would benefit others with similar needs as well. There is however one
issue that is bothering me, how should the crontab service be
implemented? Should it be a standalone process or should it be in a JEE
container? What happens if this scheduling process is down? Should i
have yet another process monitoring it and respawn the scheduler when
needed. What's your thought on this?

I don't think Sarasvati should concern itself with the reliablily of the scheduling service. Quartz or the EE container should be reliable and/or be able to monitor itself.
 

Also I thought if sarasvati would to include a sort of IOC capability it
would make it even more flexible.

I'm not against this, I'm just not sure how it would work. The place I see injection being most useful would be on the node. However, nodes are shared resources (or should be), for performance reasons. Maybe we could hack it by creating a node copy/proxy when a node token is executed. However, I'm not clear on how this would work.
 

One other note, I have looked into Quartz, it looks good however I
thought we can push the envelope further by providing all these Time
related event stuff to use the iCalendar specs RFC 2445. Perhaps this
can be post 1.0 if we can get the basic Scheduling framework up first.

Finally, I have a less than a week to get this up, how do you think we
should approach this?

Regards
chung-onn

I think it might be useful if you gave some example of how you see this being used. I tend to see event being generated based on business data associated with the workflow, or off times in the workflow (such as node create time), as opposed to static times.

cheers,
Paul
 

[Paul Lorenz]

Ok, sounds good. I think this complicated enough that it will take some time to spec out.

cheers,
Paul

[Cheong Chung Onn]

Paul Lorenz wrote:
>
> Response in-line.
>
>
> On Sat, Aug 1, 2009 at 12:25 AM, Cheong Chung Onn <chun...@gmail.com

> <mailto:chun...@gmail.com>> wrote:
>
>
> Hi Paul,
>

First I need to confess that I have not seen or used any BPM engine
other than JBPM 2.0 :). Whatever I suggest or comment may not be sound.
My need for future event facility stems from the fact that my user wants
to be able to schedule to start a workflow process some time in the
future. I already have a simple workaround to this by using a crontab
like service to check if the due-date has expired, if yes - then
Process#start.

A thought struck me after mulling over the your example -> Token ==
TimeEvent or perhaps we can have a Temporal Node

<time-node>
<arc waitFor="2 days" to="checkMyLetterbox"/>
<arc on="every tues" to="meeting"/>
<arc is="date predicate" to="sendEmail"/>
</time-node>

>
>
>
>
>
> Your example shows <time-event> is a child element of Node. I wonder
> should <time-event> element be a sub-type of <guard> element?
>
>
> Hmm, you can only have 1 guard. Maybe you could elaborate on this some
> more? Or did you want to be able to specify guards on time events?

Yes I understand there can only be 1 guard. I saw the Rubric API page,
it mentioned about creating a time predicate hence i thought that a
time-event can be a subclass of guard.

>
> <time-event ...>
> <if>Order.isExpedited or Customer.isGoldLevel</if>
> <time-out>(5 days after tokenCreated</time-out>
> </time-event>
>
>
>
>
> I have an immediate need for this feature, my approach is to
> implement a
> crontab service and periodically poll what are the outstanding tasks
> needs to be started.
>
> However after reading your approach, I am keen to work on it so
> that it
> would benefit others with similar needs as well. There is however one
> issue that is bothering me, how should the crontab service be
> implemented? Should it be a standalone process or should it be in
> a JEE
> container? What happens if this scheduling process is down? Should i
> have yet another process monitoring it and respawn the scheduler when
> needed. What's your thought on this?
>
>
>
> I don't think Sarasvati should concern itself with the reliablily of
> the scheduling service. Quartz or the EE container should be reliable
> and/or be able to monitor itself.

Agreed.

>
>
>
> Also I thought if sarasvati would to include a sort of IOC
> capability it
> would make it even more flexible.
>
>
> I'm not against this, I'm just not sure how it would work. The place I
> see injection being most useful would be on the node. However, nodes
> are shared resources (or should be), for performance reasons. Maybe we
> could hack it by creating a node copy/proxy when a node token is
> executed. However, I'm not clear on how this would work.

Initially I did think that having IOC for Node would give it another
degree of flexibility well I am still very happy using Sarasvati without
it :)

>
>
>
> One other note, I have looked into Quartz, it looks good however I
> thought we can push the envelope further by providing all these Time
> related event stuff to use the iCalendar specs RFC 2445. Perhaps this
> can be post 1.0 if we can get the basic Scheduling framework up first.
>
>
> Finally, I have a less than a week to get this up, how do you think we
> should approach this?
>
> Regards
> chung-onn
>
>
>
> I think it might be useful if you gave some example of how you see
> this being used. I tend to see event being generated based on business
> data associated with the workflow, or off times in the workflow (such
> as node create time), as opposed to static times.

I agree with your views about events. Btw, my colleague introduced
cron4j today, it seems simple, lightweight and comprehensive. I would be
exploring it, perhaps I would see how to use it for Sarasvati.

http://www.sauronsoftware.it/projects/cron4j/index.php

Regards
chiung-onn