Re: [concern-users] Handling "business days" in timeouts and other timings

[Andy D. <an...@ma...>]

I'm willing to implement this.  I could create an interface called, say, 
"TimeUnit":

public interface TimeUnit extends Node
{
  public long translate(long timestamp, long timevalue);
}

The main difference here is that Con:cern would pass in whatever value is 
specified in the "timeout" attribute directly, without modifying it in any 
way (for example, I believe it multiplies it by 1000 now in order to convert 
from seconds to millis).

TimeUnits could be registered in the process definition:

<process name="..." subject="...">
  ...
  <timeunit name="business" 
class="com.marathon.workflow.concern.BusinessTimeUnit">
    ... environment entries could go here ...
  </timeunit>
  ...
</process>

If desired, someone could even install multiple timeunits (with different 
names, of course).  Con:cern would always install a default timeunit of 
"seconds", and if no timeunit is specified for an activity then it would use 
"seconds".  "seconds" would simply do this:

public class SecondsTimeUnit implements TimeUnit
{
  ...
  public long translate(long timestamp, long timevalue) {
    return timestamp + (timevalue * 1000);
  }
  ...
}


We could then add an optional "timeunit" attribute to activity:
  <activity name="Review Entry" 
class="com.marathon.workflow.concern.MAsynchronousActivity" 
asynchronous="true" user="true" optional="false" timeout="86400" 
timeunit="business">

Which would lookup the TimeUnit instance based on the name and use it to 
convert from the time value specified in "timeout".  Again, if "timeunit" is 
omitted, then "seconds" would be used, which would provide backward 
compatible behavior.  The only other question would then be other times (such 
as retry time, etc).  Would "timeunit" apply the same to those as well?

  - Andy


On Tuesday 28 June 2005 09:52 am, Holger Engels wrote:
> Quoting Andy Depue <an...@ma...>:
> > I would like the ability to specify some of my timeouts in "business
> > days".
>
> me too! our approach at the moment is, that we ignore the timeout (return
> from the escalate method without doing anything), if it falls into excluded
> time. this is exact as long as the excluded period is at least as long as
> the timeout.
>
> my proposal would be to define a calendar interface with a method
>
>   long translate(long timestamp, long businessMillis)
>
> .. you pass in the current timestamp and a delay of 3 * 8 * 3600000 (3d).
> it will return the same time, but three days later.
>
> This also works, if a delay spans multiple excluded periods.
>
> regards,
>
> Holger
>
> >  <activity name="Review Entry"
> > class="com.marathon.workflow.concern.MAsynchronousActivity"
> > asynchronous="true" user="true" optional="false" timeout="86400">
> >
> > timeout="86400" represents 24 hours (1 day), but if this activity is
> > started at 4:00 PM on Friday, I'd like it to not timeout until 4:00 PM on
> > Monday.  If started at 4:00 PM on Monday, then it should timeout at 4:00
> > PM on Tuesday, and so on.  Has anyone else needed to solve this issue? 
> > If so, what was your approach?  Ideally, it would be neat if I could do
> > something like this:
> >
> >  <activity name="Review Journal Entry"
> > class="com.marathon.workflow.concern.MAsynchronousActivity"
> > asynchronous="true" user="true" optional="false" timeout="86400"
> > time-unit="business-seconds">
> >
> > For now, I'm taking the approach of using an environment variable:
> >
> >  <activity name="Review Entry"
> > class="com.marathon.workflow.concern.MAsynchronousActivity"
> > asynchronous="true" user="true" optional="false" timeout="86400">
> >    <env-enry>
> >      <env-entry-name>time-unit</env-entry-name>
> >      <env-entry-type>java.lang.String</entry-entry-type>
> >      <env-entry-value>business-seconds</entry-entry-value>
> >    </env-entry>
> >  </activity>
> >
> > And then manually adjusting the return value of "getTimeout()" from my
> > AsynchronousActivity implementation.
> > If this functionality were moved into the Con:cern core, we would
> > probably want to use an interface that the end-developer can implement,
> > much like Quartz does.  Quartz allows you to handle "business" days via
> > this interface:
> >
> >  public interface Calendar {
> >    public boolean isTimeIncluded(long timeStamp);
> >    public long getNextIncludedTime(long timeStamp);
> >  }
> >
> > You just do this to adjust time:
> >  long now = System.currentTimeMillis();
> >  if(!calendar.isTimeIncluded(now + timeout)) {
> >    return (calendar.getNextIncludedTime(now + timeout) - now);
> >  } else {
> >    return timeout;
> >  }
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > concern-users mailing list
> > con...@li...
> > https://lists.sourceforge.net/lists/listinfo/concern-users
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> concern-users mailing list
> con...@li...
> https://lists.sourceforge.net/lists/listinfo/concern-users