10. Scheduler(日程安排程序)
This chapter describes how to work with timers in jBPM.
Upon events in the process, timers can be created. When a timer expires(終止), an action can be executed or a transition can be taken.
10.1. Timers
The easiest way to specify a timer is by adding a timer element to the node.
<state name='catch crooks'>
<timer name='reminder'
duedate='3 business hours'
repeat='10 business minutes'
transition='time-out-transition' >
<action class='the-remainder-action-class-name' />
</timer>
</state>
<state name='catch crooks(騙子)'>
<timer name="reminder(提示)" duedate(到期日)="3 business hours" repeat="10 buesiness minutes" transition='time-out-transtion'>
<action class='the-remainder-action-class-name'/>
</timer>
</state>
A timer that is specified on a node, is not executed after the node is left. Both the transition and the action are optional. When a timer timer is executed, the following events occur in sequence :
an event is fired of type timer
if an action is specified, the action is executed.
if a transition is specified, a signal will be sent to resume execution over the given transition.
Every timer must have a unique name. If no name is specified in the timer element, the name of the node is taken as the name of the timer.
The timer action can be any supported action element like e.g. action or script.
Timers are created and cancelled by actions. The 2 action-elements are create-timer and cancel-timer. Actually, the timer element shown above is just a short notation(符號) for a create-timer action on node-enter and a cancel-timer action on node-leave.
2 action-elements :
create-time node-enter
cancel-time node-leave
Scheduler deployment
Process executions create and cancel timers. The timers are stored in a timer store. A separate timer runner must check the timer store and execute the timers when they are due.
10.2. Scheduler deployment
Process executions create and cancel timers. The timers are stored in a timer store. A separate timer runner must check the timer store and execute the timers when they are due.
三個Actor:
process executions(流程執行):
a. scheduler timer (日期安排計時器)
b. cancel timer (取消計時器)
timer store(計時器儲存) --->cancel timer--->scheduler timer
timer runner(計時器運行者) --->execute timers that are due
Scheduler Service
timer runner
The following class diagram shows the classes that are involved in the scheduler deployment. The interfaces SchedulerService and TimerExecutor are specified to make the timer execution mechanism pluggable.
process execution(actor) ---> SchedulerInstance ---> SchedulerService (接口)<----SchedulerServiceImpl(接口實現)
--->JBPM_TIMER database
/SchedulerMain |||
Runnable(接口)----TimerRunner(實現接口)--------->TimerExecutor（接口）<---------TimerExecutorImpl(接口實現)
\SchedulerServlet
----------------------------------------------------------
11. Business calendar (商業日歷)
This chapter describes the business calendar of jBPM. The business calendar knows about business hours and is used in calculation(計劃) of due（預期的） dates for tasks and timers<任務和計時器>.
The business calendar is able to calculate(計劃) a date by adding a duration(持續時間) and a date.
11.1. Duration(持續時間)
A duration is specified in absolute or in business hours. Let's look at the syntax:
<quantity> [business] <unit>
Where <quantity> is a piece of text that is parsable with Double.parseDouble(quantity). <unit> is one of {second, seconds, minute, minutes, hour, hours, day, days, week, weeks, month, months, year, years}. And adding the optional indication business means that only business hours should be taken into account for this duration. Without the indication business, the duration will be interpreted as an absolute time period.
<quantity> [business] <unit>
<數量>[商業]<單元>
這里<quantity>是一段文字，用來解析使用Double.parseDouble(quantity). <單元>是{秒、分等等}中的一種。并且增加可選的指示商業意味著僅僅商業時間被考慮為這一段時間。 沒有這個指示商業，持續時間將被解釋為一個完全的時間區域。
11.2. Configuration(配置)
The file org/jbpm/calendar/jbpm.business.calendar.properties specifies what business hours are. The configuration file can be customized and a modified copy can be placed in the root of the classpath.
This is the example business hour specification that is shipped by default in jbpm.business.calendar.properties:
hour.format=HH:mm
#weekday ::= [<daypart> [& <daypart>]*]
#daypart ::= <start-hour>-<to-hour>
#start-hour and to-hour must be in the hour.format
#dayparts have to be ordered
weekday.monday= 9:00-12:00 & 12:30-17:00
weekday.thuesday= 9:00-12:00 & 12:30-17:00
weekday.wednesday= 9:00-12:00 & 12:30-17:00
weekday.thursday= 9:00-12:00 & 12:30-17:00
weekday.friday= 9:00-12:00 & 12:30-17:00
weekday.saturday=
weekday.sunday=
day.format=dd/MM/yyyy
# holiday syntax: <holiday>
# holiday period syntax: <start-day>-<end-day>
# below are the belgian official holidays
holiday.1= 01/01/2005 # nieuwjaar
holiday.2= 27/3/2005 # pasen
holiday.3= 28/3/2005 # paasmaandag
holiday.4= 1/5/2005 # feest van de arbeid
holiday.5= 5/5/2005 # hemelvaart
holiday.6= 15/5/2005 # pinksteren
holiday.7= 16/5/2005 # pinkstermaandag
holiday.8= 21/7/2005 # my birthday
holiday.9= 15/8/2005 # moederkesdag
holiday.10= 1/11/2005 # allerheiligen
holiday.11= 11/11/2005 # wapenstilstand
holiday.12= 25/12/2005 # kerstmis
business.day.expressed.in.hours= 8
business.week.expressed.in.hours= 40
business.month.expressed.in.business.days= 21
business.year.expressed.in.business.days= 220
----------------------------------------------------
13. jBPM Process Definition Language (JPDL) (jBPM流程定義語言)
JPDL specifies an xml schema and the mechanism to package all the process definition related files into a process archive(存檔).
13.1. The process archive
A process archive is a zip file. The central file in the process archive is processdefinition.xml. The main information in that file is the process graph. The processdefinition.xml also contains information about actions and tasks. A process archive can also contain other process related files such as classes, ui-forms for tasks, ...
13.1.1. Deploying a process archive
Deploying process archives can be done in 3 ways: with the process designer tool, with an ant task or programatically.
三種部署方式：
a.流程設計工具
b.ant任務處理
c.程序
Deploying a process archive with the designer tool is still under construction.
Deploying a process archive with an ant task can be done as follows:
<target name="deploy.par">
<taskdef name="deploypar" classname="org.jbpm.jpdl.par.ProcessArchiveDeployerTask">
<classpath --make sure the jbpm-[version].jar is in this classpath--/>
</taskdef>
<deploypar par="build/myprocess.par" />
</target>
To deploy more process archives at once, use the nested fileset elements. The file attribute itself is optional. Other attributes of the ant task are:
cfg:
cfg is optional, the default value is 'hibernate.cfg.xml'. The hibernate configuration file that contains the jdbc connection properties to the database and the mapping files.
properties:
properties is optional and overwrites *all* hibernate properties as found in the hibernate.cfg.xml
createschema:
if set to true, the jbpm database schema is created before the processes get deployed.
Process archives can also be deployed programmatically with the class org.jbpm.jpdl.par.ProcessArchiveDeployer
13.1.2. Process versioning
Process definitions should never change because it is extremely difficult (if not, impossible) to predict(預知) all possible side effects of process definition changes.
To get around this problem, jBPM has a sophicticated process versioning mechanism. The versioning mechanism allows multiple process definitions of the same name to coexist(共存) in the database. A process instance can be started in the latest version available at that time and it will keep on executing in that same process definition for its complete lifetime. When a newer version is deployed, newly created instances will be started in the newest version, while older process instances keep on executing in the older process defintions.
Process definitions are a combination of a declaratively specified process graph and optionally, a set of related java classes. The java classes can be made available to the jBPM runtime environment in 2 ways : by making sure these classes are visible to the jBPM classloader. This usually means that you can put your delegation classes in a .jar file next to the jbpm-[version].jar. The java classes can also be included in the process archive. When you include your delegation classes in the process archive (and they are not visible to the jbpm classloader), jBPM will also apply versioning on these classes. More information about process classloading can be found in Section 13.2, “Delegation”
When a process archive gets deployed, it creates a process definition in the jBPM database. Process definitions can be versioned on the basis of the process definition name. When a named process archive gets deployed, the deployer will assign a version number. To assign this number, the deployer will look up the highest version number for process definitions with the same name and adds 1. Unnamed process definitions will always have version number -1.