EOS51工作流--案例部分解说.doc

EOS工作流开发引言 为了使学习者能循序渐进、深入浅出，整个EOS工作流开发实践分成入门、进阶及深入三个阶段；三个阶段终始围绕同一个案例不断进行重构，在重构的过程中学习EOS WF的特性及开发技巧，并且体会EOS平台的快速开发、全面业务支撑环境与开放性带来的乐趣。 在接下来的三章中我们要使用的案例是在日常工作中经常会碰到的一个案例 请假，这个案例很好理解且不是特别复杂；开发过程将展示： 我们怎样获取客户的需求并不断满足客户的需求？ EOS WF中有哪些特性能够使我们能够随需应变？ EOS WF怎样和业务进行集成？ EOS WF怎样和外部进行交互？ EOS WF怎样和第三方系统进行集成？ 面对客户的一些非正常需求，EOS WF能省心省力吗？ … EOS WF入门 通过前面的学习，大家对Primeton EOS? WorkFlow有了个大概的认识，但基本上停留在理论的层次；在本节中我们通过两个案例版本的生成，来展示EOS WF的基本开发过程和EOS WF中基本元素的含义和用法。 一个小时的练习 客户需求 客户是一间规模不大的槟榔公司，公司里目前员工请假都是通过填写纸制的请假单，然后送总经理审批，批准后送HR部门登记即可。 一天总经理找到我，说“小刀，你不是在软件公司么？看看有什么东东能将我公司的请假业务用电脑管一下。” 分析设计 “嘿嘿！错了那么多年，你今天终于对了一次；EOS干这个太容易了。”，我心里一阵窃喜。 分析 客户从没有用过电脑，更没有系统的使用经验，恐怕他自己都不知道要做一个什么样的东东。 现有流程只有3步：填单(审批(HR登记 请假单内容不清楚，但估计和Primeton的差不多。 设计 流程设计 怎样来设计这个模型呢？ 槟榔大哥的请假业务目前就三个步骤，最简单的设计就是直接映像他的现实业务，我还不完全了解槟榔大哥的需求和愿景，我也不是HR管理的专家，故我不具备BPR的能力。算了，还是照抄他的现实模型，免得第一炮就打哑了，做人要低调。 相关设计 请假过程中最重要的信息就是请假单了，我现在并不知道客户的请假单具体要哪些信息，故只能参考自己公司的请假单，取几项典型性的属性；不过这不重要，EOS采用XML结构来描述业务实体，并使用XML DOM在内存中传递数据，具有良好的可扩展性，客户如果要增加 / 减少属性都不会费事。 这一次我只是想尽快给槟榔大哥看到一个能跑起来的版本，并不打算将数据持久化、界面美化工程等所有的工作都做完，看来EOS WF的表单数据特性能够很好的帮到我，就用它了。但我还是要对那些影响流程流向的属性要给予足够的考虑才行，如请假是否有批准属性，流程引擎需要它来决定流向，故我会放在一个让流程引擎能够访问到的地方，并将努力保证在以后的重构过程中尽量不去改动这个设计，做到心中有数吧。 下面我们列出请假单的简单描述： LEAVEMASTER //请假单 APPLIEDBY/ //请假人[填写请假单] LEAVETYPE/ //请假类型[填写请假单] LEAVEREASON/ //请假原因[填写请假单] STARTTIME/ //请假开始时间[填写请假单] ENDTIME/ //请假结束时间[填写请假单] ISAPPROVED/ //批准否？[总经理审批] APPROVECOMMENT/ //批注[总经理审批] APPROVEDBY/ //审批人[总经理审批] ISREGISTER/ //登记否？[HR登记] REGISTERBY/ //登记人[HR登记] /LEAVEMASTER 案例实现 创建项目 启动项目创建向导。 通过[文件/创建/EOS业务流程项目]菜单项启动项目创建向导。 输入项目名称 在[项目名称]中输入leave后，直接按完成按钮即可。 项目名称应根据项目的定义进行取名，特别是在多人协作开发模式下，统一命名是协作成功的关键。 项目创建完成 这是项目创建向导完成后的项目资源视图，向导会缺省的创建一个名为“pkg”的构件包；若你想采用不同的构件包名，你可以重命名或重新创建构件包来达成你的目的；我们整个例子中都采用缺省的构件包名 pkg。 建立流程 启动流程创建向导 通过wf文件夹的右键菜单项[新建/业务流程]来启动流程创建向导。 输入流程名称 本步骤主要是确定流程的存储参数及体现流程的可复制特性（通过模板技术）。根据EOS Studio中的默认命名规则，流程文件是以“wf”为前缀的，其余部分按Java的命名规范（/docs/codeconv/html/CodeConvTOC.doc.html）进行，故我们按照此约定命名我们的请假流程为“wfLeaveMain”；当然可以有自己的约定，但原则是“没有约定，先制定约定；有约定，就按约定执行，哪怕