专利名称：对应数据的输入状态进行工作流控制的方法及系统的制作方法
技术领域：
本发明涉及利用计算机进行工作流控制的方法及执行工作流控制的计算机系统，尤其涉及对企业内的业务处理及企业间交易业务进行工作流控制的方法及系统。
一般情况下，企业内的业务处理大多是多次进行由多个作业步骤序列构成的业务状态来完成。在从某个作业步骤进行到下一个作业步骤过程中，通过单据、帐票不断地传递数据，完成一系列的作业步骤。在利用电子计算机的工作流系统中，以单据或帐票为单位的信息被保存在电子计算机的存储装置中，利用网络进行数据传送将之传递给承担下一个作业的承担者。例如，日经信息战略1994年7月号P66-P76(日经BP公司)公开了这种工作流系统。
与之相对应地，企业间交易是在进行交易的企业之间往来作为各自企业进行业务处理的一部分结果的单据、帐票。因此，企业间交易可以看成是企业内的业务处理从企业内传递延伸到其它企业的行为。作为利用电子计算机进行这样的企业间交易的系统之一，有利用EDI(Eletrnic DataInterchange)的企业间交易系统。这是事先在进行交易的2个公司之间交换合同并根据由此确定的方式、数据形式及其它规则，以单据、帐票的形式进行数据的往来的过程。即，由进行交易的对方确定相当于企业内规定的业务处理规则的条款并根据该条款进行交易。例如，北泽博著“EDI入门”(软研究中心，1991年)便公开了这种EDI技术。
因过去的利用EDI进行企业间交易的系统是对每个公司确定交易规则，所以，对每个交易对方必须对应其规则改变交易方法。因此，将产生因交易的内容而必须改变处理方法的情况。作为典型实例举订购处理为例。在进行订购的企业内，订购后、入库检验、赊购总计和业务状态滚动地变化，但在企业间交易的业务状态中，订购后，是接收订购的企业进行接收订货处理。另外，订货方根据其订货内容并非总是一样，有时候根据订货内容其数据的送交目的地、送交方法会有很大变化。但是，如先前所述的那样，在企业间交易系统中，因为每个交易方企业的规则不同，不同企业很难按照同一处理程序进行处理，所以，存在要实现对应其订购内容随机应变地变更数据传递方法或送交目的地的系统是极其困难的问题。
本发明的目的在于不管是企业内业务处理还是企业间交易，都能提供一个原则上部门间或企业间必要的数据交付由工作流控制系统进行，并不使用户应用程序或业务处理承担者意识到这样的数据交付的工作流控制方法及系统。
本发明的工作流控制方法的特征如下在检知到与业务处理中事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据在部门内的工作流序列中规定的下一个应该处理的承担者的部门内的工作流规则，判定下一个承担者是否为应该处理事件的状态，如果下一个承担者已达到应该处理事件的状态，则对下一个承担者发布动作通知；在检知到与该事件数据有关的业务处理结束时，根据事件数据的数据输入状态，根据在涉及部门间的工作流序列中规定的下一个应该处理的部门的部门间工作流规则，判定下一个部门是否为应该处理事件的状态，如果下一个部门已达到应该处理事件的状态，则对下一个部门发布动作通知；而后，接收对下一个部门的动作通知并根据部门内的工作流规则进行下一个作业步骤。
另外，本发明的工作流控制系统的特征在于具有控制部门内的工作流的第1代理部；控制部门间的工作流的第2代理部；进行第2代理部和其它的第2代理部之间的数据传送的第3代理部。
第1代理部具有以下单元即在检知到与业务处理中事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据在部门内的工作流序列中规定的下一个应该处理的承担者的部门内的工作流规则，判定下一个承担者是否为应该处理事件的状态，如果下一个承担者已达到应该处理事件的状态，则对下一个承担者发布动作通知的单元；接收对下一个部门的动作通知并根据部门内的工作流规则进行上述部门内工作流控制的单元。
第2代理部具有以下单元即在检知到与业务处理中该事件数据有关的业务处理结束时，根据事件数据的数据输入状态，根据在涉及部门间的工作流序列中规定的下一个应该处理的部门的部门间工作流规则，判定下一个部门是否为应该处理事件的状态，在下一个部门已达到应该处理事件的状态时，判定下一个部门是属于该第2代理部管理范围内的部门还是属于其管理以外的部门，在属于管理范围内的部门时，对管理范围内的第1代理部发布动作通知，在属于管理范围之外的部门时，则对第3代理部进行数据送交委托的单元；从第3代理部接收动作通知并对作为目的地的第1代理部发布动作通知的单元。
第3代理部具有接收来自第2代理部的数据送交委托并确定管理范围内一个部门的第2代理部，以及对所确定的第2代理部送交动作通知的单元。
上述所谓下一个部门是普通用语表现的功能部门，第2代理部只判定该功能部门是自己管理范围内的功能部门还是管理范围之外的功能部门即可。另外，在同时接收到来自第3代理部的动作通知和目的地功能部门时，因该功能部门是管理范围内的功能部门，故参照列表确定作为目的地的第1代理部。此外，第3代理部只接收目的地功能部门，并参照列表判定关于作为目的地的第2代理部的标识符即可。进而，作为参照的列表，如果第3代理部以事件数据的内容为条件作成可设定对应的目的地之类的列表，则第3代理部可匹配事件数据的内容和该列表上的事件数据的条件来确定目的地。此外，如果第2代理部也对参照的列表同样地以事件数据的内容为条件生成可设定对应的目的地之类的列表，则第2代理部也可以匹配事件数据的内容和该列表上的事件数据的条件确定目的地。
如上所述这样，因工作流控制系统根据事件数据的内容自动地判定数据送交目的地并进行数据的送交，所以，即使用户应用程序或业务处理承担者对数据送交没有意识到也可以进行企业内的部门间及企业间的数据送交，能够准确且高效地控制涉及多个企业间的工作流。此外，在数据送交方法出现变更时，只要变更第2代理部所管理的工作流规则即可，而在数据送交目的地出现变更时，只要变更第2代理部及第3代理部在确定数据送交目的地时所参照的列表即可。
工作流控制系统对应交易内容确定数据送交方法及数据送交目的地，实现涉及多个企业间的高可靠性、高效率的工作流控制。此外，工作流控制系统对应介于企业间的网络种类确定通信方式，由于进行数据的压缩或加密，所以，用户应用程序也无需刻意地进行数据传送时的数据的加工及安全的确保。
图1是概略地示出系统构成例子的图。
图2是示出实施形态的系统构成要素图。
图3所示是保存在业务数据库112中的一个事件数据例子的图。
图4所示是部门内工作流规则119的数据例子的图。
图5所示是任务表120的数据例子的图。
图6所示是在从商务代理部123接收到A/N发布指示时的任务代理部122的处理流的流程图例。
图7所示是在从用户应用程序111接收到处理结束通知时的任务代理部122的处理流的流程图例。
图8所示是事件状态转移基准表113的数据例子的图。
图9所示是可执行动作表114的数据例子的图。
图10所示是逻辑任务结点定义表115的数据例子的图。
图11所示是担当商务代理表116的数据例子的图。
图12所示是部署定义表117的数据例子的图。
图13所示是在从用户应用程序111接收到处理结束通知时的商务代理部123的处理流的流程图例。
图14所示是在从其它的商务代理部123接收到A/N发布委托时的商务代理部123的处理流的流程图例。
图15所示是送交目的地特定表124的数据例子的图。
图16所示是访问规则定义表125的数据例子的图。
图17所示是访问代理部127的处理流的流程图例。
图18所示是网络转接部128的处理流的流程图例。
下面，使用图面对本发明之一实施形态进行说明。
图1是概略地示出系统构成例之图。图1中，A公司100、B公司104及C公司105是参加企业间交易的企业，106是不属于任何一个企业的提供者。A公司100由X部门101、Y部门102及Z部门103构成。其中，X部门101、Y部门102、Z部门103、B公司104、C公司105及提供者106以各自的部门、企业或者提供者所管理的计算机系统为代表。与A公司100处于同一所在地的X部门101和Y部门102通过LAN(局域网)107连接，X部门101、Y部门102和位于其它所在地的Z部门103经由LAN(局域网)107及网络108连接。A公司100的X部门101、Y部门102和B公司104通过提供者106及网络109连接。此外，A公司100的X部门101、Y部门102和C公司105通过提供者106及网络110连接。网络108、109、110是LAN(局域网)以外的专用线、WAN、因特网等网络。在X部门101和Y部门102的通信中提供者106不介入，但在X部门101、Y部门102和Z部门103、B公司104及C公司105之间的通信中提供者106将介入。
图2是展开表示图1的系统构成的构成图。在A公司100的X部门101，设置有包括至少一台保存有用户应用程序111-AX、任务代理部122-AX及任务规则定义数据库(DB)121-AX的计算机的计算机系统。
A公司100的Y部门102也同样地设置有至少具有一台保存有用户应用程序111-AY、任务代理部122-AY及任务规则定义数据库(DB)121-AY的计算机的计算机系统。
另外，作为X部门101及Y部门102共有的计算机系统，设置有至少具有一台保存有商务代理部123-A、商务规则定义DB118-A及业务数据库(DB)112-A的计算机的计算机系统。
B公司104的计算机系统保存用户应用程序111-B、任务代理部122-B、任务规则定义DB121-B、商务代理部123-B及商务规则定义DB118-B，并共用A公司的业务DB112。
没有图示的A公司100的Z部门103的计算机系统也和B公司104一样，保存用户应用程序111-AZ、任务代理部122-AZ、任务规则定义DB121-AZ、商务代理部123-AZ及商务规则定义DB118-AZ，并共用业务DB112。
C公司105的计算机系统虽然保存用户应用程序111-C、任务代理部122-C、任务规则定义DB121-C、商务代理部123-C及商务规则定义DB118-C，但不共用A公司的业务DB112、也不能访问业务DB112。
提供者106的计算机系统保存访问规则定义DB126、访问代理部127及网络转接部128。
还有，不带后缀的参照序号是用带后缀的参照序号所表示的构成要素总称。
业务DB112由可访问的用户应用程序111访问，并对于每个事件以数据的形式保存业务处理的结果。任务规则定义DB121由部门内工作流规则119及任务表120构成。部门内工作流规则119规定部门内工作流的序列和通过任务表现的作业担当。
任务表120规定任务和实际承担者的对应关系。任务代理部122在接收来自商务代理部123的指示转移到下一个事件状态的动作通知(A/N)时，参照部门内工作流规则119及任务表120确定进行下一个业务处理的承担者，并对该承担者的用户应用程序111发布A/N。
另外，在接收到来自用户应用程序111的处理结束通知时，任务代理部122参照部门内工作流规则119，判定是否进入下一个事件状态，在进入下一个时，参照任务表120对下一个承担者的用户应用程序111发布A/N。即任务代理部122分别设置在X部门101、Y部门102、Z部门103，进行各部门内的工作流控制。
商务规则定义DB118分别设置在A公司100、B公司104及C公司105，由事件状态转移基准表113、可执行动作表114、逻辑任务结点定义表115、担当商务代理表116及部署定义表117构成。事件状态转移基准表113规定工作流为进行涉及包括其它公司在内的部门间的序列控制的事件的状态转移规则。可执行动作表114规定转移到各个事件状态时的应取的动作，逻辑任务结点定义表115规定执行该动作的逻辑任务结点。逻辑任务结点是部门的名称，是用具有功能部门含意的普通用语表现的部门名称。担当商务代理表116规定各个逻辑任务结点是属于该商务代理部123的管理范围内还是属于其管理范围之外(即，是否属于该商务代理部以外的商务代理部的管理之下)。部署定义表117对应该商务代理部管理范围内的逻辑任务结点规定现实担当部署的名称。
商务代理部123在接收到来自用户应用程序111的处理结束通知时，参照事件状态转移基准表113判定是否转移到了应该顺序控制的事件的事件状态。如果事件状态已转移，则参照可执行动作表114及逻辑任务结点定义表115确定下一个应该执行的动作和其逻辑任务结点，并参照担当商务代理表116，判定该逻辑任务结点定义是否为自己管理范围内的部门。如果是自己管理范围内的逻辑任务结点，则参照部署定义表117取得现实进行作业的部署的名称并将A/N送交给管理其部署的任务代理部122。
如果逻辑任务结点是管理范围之外的部门，则商务代理部123对访问代理部127进行数据送交委托。此外，商务代理部123在通过访问代理部127接收到来自其它的商务代理部123的A/N发布委托时，参照部署定义表117取得对应所指定的逻辑任务结点的现实的部署名，并向管理其部署的任务代理部122送交A/N。如上述这样，商务代理部123在起动自己管理范围内的任务代理部122的同时，可以如从X部门101、Y部门102到Z部门，从X部门101、Y部门102到B公司104那样，对涉及其它部门或企业的工作流按照称之为逻辑任务结点的功能部门名进行工作流控制。
访问规则定义DB126由送交目的地特定表124及访问规则保存表125构成。送交目的地特定表124规定对应逻辑任务结点的物理任务结点。这里所谓的称之为物理任务结点，是指象Z部门103、B公司104、C公司105那样具有商务代理部123的公共事业所或企业的标识符。访问规则保存表125规定在由各物理任务结点向其它的物理任务结点发送数据时的通信协议、安全方式等。
访问代理部127接收来自商务代理部123的数据送交委托，并参照送交目的地特定表124确定对应所指定的逻辑任务结点的数据送交目的地的物理任务结点。另外，在接收到来自不能访问业务DB112的物理任务结点的对业务DB112的数据送交委托时，根据所接收的事件的数据项目值更新业务DB112。另外，如果数据送交目的地是不能访问业务DB112的物理任务结点，则增添从业务DB112取得的事件的数据项目值。
网络转接部128接收来自访问代理部127的数据送交委托，参照访问规则保存表125，在进行数据的加工之后，经由网络向所指定的物理任务结点送交数据。如上述这样，访问代理部127把逻辑任务结点变换成对应的物理任务结点，并从物理任务结点相对于其它的物理任务结点进行数据传送的。
B公司104及C公司105也分别具有专用或与其它公司共用的提供者106。B公司104、C公司105侧的提供者106用访问代理部127接收A公司100送来的数据，用网络转接部128进行数据复原及加密数据的解密并分别传送给B公司104及C公司105。由B公司104或C公司105传送给A公司100的数据途经保存在B公司104、C公司105侧的提供者106的访问代理部127、网络转接部128、网络、A公司100侧的访问代理部127及网络转接部128这样的路径，传递给管理A公司的X部门101、Y部门102的商务代理部123。A公司100的X部门101、Y部门102和A公司侧的提供者106一起可以确保B公司104、C公司105和其提供者106之间的安全，且在数据转送时不进行数据的加工。
用户应用程序111是保存在客户机那样的计算机中的程序。任务代理部122、商务代理部123、访问代理部127及网络转接部128是保存在服务器那样的计算机中的程序。任务规则定义DB121、商务规则定义DB118、业务DB112及访问规则定义DB126保存在连接在服务器那样的计算机的存储装置上。可以把商务代理部123及访问代理部127的程序分别保存在存储介质中，经由连接在计算机上的驱动装置或通过网络的程序传送读入到计算机的主存储装置内运行。
图3是示出保存在业务DB112上的一个事件数据例子的图。一个事件数据包括事件序号20、订货单位21、总计金额22、接收订货签字23及事件状态24。此外，在一个事件中，每个所订购的商品都具有品种名称25、订购数量26、订货金额27、交货期限28及批准签字29各数据项目。总计金额22是对该事件的所有品种总计订货金额27的结果，是可自动地计算的数据项目。事件状态24表示在关于该事件的工作流序列中现在的状态。接收订货签字23是表示确定已接收订货的的签字。批准签字29是表示管理者已批准的签字。图3中被记载为“未输入”的数据项目表示数据尚未被输入。另外，与事件状态24表示的各状态相对应，具有表示在该状态下各逻辑任务结点能否访问从事件序号20到批准签字29各数据项目的列表30。“可以参照”表示只能进行数据的参照，“不可参照”表示不允许参照，“可以更新”表示可以进行数据输入或者数据更新。
图4是示出部门内工作流规则119的数据例之图，与各事件状态相对应表示输入了数据的任务和应该输入的数据项目。品种名称、订购数量、订货金额、订货单位及交货日期是对应示于图3的事件具有的数据项目的内容。在输入了品种名称和订购数量时，转移到事件状态1。承担者(多个也可以)输入品种名称、订购数量、订货金额、订货单位及交货日期各数据，如果通过计算机计算并自动地输入总计金额，则转移到事件状态2。在输入了主管人员的批准后，如果订货金额或总计金额为100万日元以上，则转移到事件状态3，否则结束工作流。在事件状态3的状态下输入了科长的批准后，如果订货金额或总计金额为300万日元以上，则转移到事件状态4，否则结束工作流。在该列表，“输入”表示在该事件状态需要数据输入，“-”表示没有数据输入。在区分列有“必须”的，表示在工作流序列中必须经由该状态，在不是如此的情况则表示根据条件执行该序列。上述的处理由任务代理部122执行。
图5是示出任务表120的数据例子的图。任务表120逐个任务地登录个人名和所承担的商品及所管理的个人名的范围。
图6是表示任务代理部122的处理流的流程图，特别是表示任务代理部122接收商务代理部123发出的A/N发布指示并对相符的用户应用程序111发布A/N的处理流。任务代理部122接收商务代理部123发出的A/N发布指示(步骤31)。该A/N发布指示包含事件序号20。任务代理部122参照业务DB112取出被指定事件序号的事件(步骤32)，按照该事件状态24参照部门内工作流规则119(图4)判定下一个任务(步骤33)，并参照任务表120确定适合符合事件条件的下一个承担者的个人名(步骤34)。进而对该承担者的用户应用程序111发布A/N(步骤35)。并利用没有图示的列表使承担者和用户应用程序111能够对应。
在某部门内的任务代理部122接收到管理该部门的商务代理部123发出的A/N发布指示时，事件为开始其部门内的处理的状态。例如，如图3所示的那样，是除了事件序号20只输入有品种名称25及订购数量26的状态。
图7是表示任务代理部122的处理流的流程图，特别是表示任务代理部122接收关联部门内的某用户应用程序111发出的处理结束通知并对同一部门内的其它的用户应用程序111发布A/N的处理流。
如果某用户应用程序111终止事件的处理，结束对业务DB112的数据写入，则把该旨意通知给任务代理部122，任务代理部122接收该结束通知(步骤41)。该结束通知包含事件序号20。任务代理部122参照业务DB112取出被指定事件序号的事件，并参照对应该事件的部门内工作流规则119(步骤42)。若事件的数据输入状态不满足部门内工作流规则119的数据输入状态，例如为否决批准的情况，则判定现在的事件状态的处理未结束(步骤43NO)，并结束处理。如果判定为现在的事件状态的处理结束(步骤43YES)，则判定进行下一个的事件状态的处理的承担者是否被部门内工作流规则所定义(步骤44)。如果部门内没有下一个承担者(步骤44NO)，则结束处理。如果有下一个承担者(步骤44YES)，则把事件状态24更新成下一个状态(步骤45)。然后，参照任务表120确定符合下一个事件状态的任务的承担者(步骤46)，并对该承担者的用户应用程序111发布A/N(步骤47)。
在用户应用程序111及任务代理部122不能直接访问业务DB112时，由于任务代理部122除了接收来自商务代理部123的A/N发布指示外，还读取其想访问的数据并接收所保存的局部文件的名称，所以，在步骤32，取出由该文件所指定的事件，并在下面如上述那样执行步骤33、步骤34及步骤35。此外，对新的事件的事件状态24，在部门内设定初始状态为开始事件处理时的事件状态。任务代理部122向所确定的用户应用程序111发送附加有所接收的局部文件名称的A/N。另外，在接收到来自用户应用程序111的带有局部文件名称的结束通知时，任务代理部122取出根据在步骤42指定的局部文件所指定的事件，并在下面如上述那样执行步骤42～47。在步骤47向所确定的承担者的用户应用程序111发布指定了局部文件名称的A/N。
图8所示是事件状态转移基准表113的数据例之图。事件状态转移基准表113是定义使事件状态转移的条件的列表，特别是定义由某个部门向其它部门或由某个部门向其它企业发动有所的时机的事件状态和状态转移的条件。在本例，“输入”表示在该事件状态下被输入数据的数据项目，数据并非必须确定，在后面的事件状态中可以修正该数据。此外“X”表示在该事件状态不能输入数据的数据项目。“可以输入”表示既可以在该事件状态进行数据输入，也可以在后面的事件状态进行数据输入的数据项目。即，如果只有“可以输入”的项目未输入而其它的“输入”项目已全部输入结束，则可以转移到下一个事件状态。换一个角度来看，也可以认为“可以输入”的项中输入有缺省值。“-”表示在前面的事件状态已经确定了数据的数据项目。例如，如“触发条件”项目所示的那样，如果在“等待订购处理”的事件状态输入有事件序号、品种名称、订购数量及交货日期，则可以转移到下一个事件状态。另外，如果“正在订购处理”事件状态中输入批准签字，则进一步转移到下一个事件状态。还有，如果在“等待接收订货确认”输入接收订货签字，则所有的数据项目确定，转移到下一个事件状态。
图9所示是可执行动作表114的数据例子的图。可执行动作表114在达到由事件状态转移基准表113定义的事件状态时定义可执行的动作。
图10所示是逻辑任务结点定义表115的数据例之图。逻辑任务结点定义表115定义执行动作的逻辑任务结点。逻辑任务结点是用普通用语表现部门的名称的说法，在此所说的部门意味着功能部门，一般地，公共事业所或企业那样的物理的结点不象X部门101、Y部门102、B公司104那样地一致。
图11所示是担当商务代理表116的数据例子的图。担当商务代理表116与由逻辑任务结点定义表115所定义的逻辑任务结点相对应，定义承担的代理。在承担代理的项目中，逐个逻辑任务结点地定义管理它们的商务代理部123或访问代理部127。即便是本公司部门，但在是商务代理部123的管理范围之外的情况或者其它公司部门则均由访问代理部127承担。
图12所示是部署定义表117的数据例之图。部署定义表117对应该商务代理部123所管理的逻辑任务结点(功能部门)的标识符，定义现实的承担部门的标识符和选择其承担部门的条件。此处，选择条件是根据事件数据的内容判定而得到的。此外，如果承担部门根据处于哪一个任务代理部122的管理之下来附加与承担部门相关的任务代理部122的标识符(或者任务代理部122所在的服务器的标识符)，则通过参照部署定义表117可以特定目的地任务代理部122和其所管理的部署名。
图13所示是商务代理部123的处理流的流程图，特别是表示商务代理部123接收用户应用程序111发出的处理结束通知并向其它的部门发布A/N的处理流。如果商务代理部123接收由用户应用程序111发出的包括事件序号20的处理结束通知(步骤51)，便参照业务DB112取出指定了事件序号的事件，参照对应该事件的事件状态转移基准表113(步骤52)。进而匹配对应现在的事件状态24的事件状态转移基准表113上的事件状态的数据输入条件，判定是否应该转移事件的状态(步骤53)。如果不满足事件状态转移的条件(步骤53NO)，则结束处理。而在满足事件状态转移的条件时(步骤53YES)，则把事件状态24更新成下一个状态(步骤54)。
接着，参照对应该条件的可执行动作表114(图9)，读取可执行的动作，进而参照逻辑任务结点定义表115(图10)读取下一个进行处理的逻辑任务结点(步骤55)。然后，参照担当商务代理表116(图11)，判定承担进行下一个处理的逻辑任务结点的代理部(步骤56)。如果承担代理部是自己(步骤57YES)，则参照部署定义表117(图12)确定现实的承担部门(步骤58)。在承担部门有条件的情况下，参照事件数据确定合乎条件的承担部门。然后，向所确定的部门的任务代理部122送交A/N(步骤59)。如果承担代理部不是自己(步骤57NO)，则对访问代理部127进行数据送交的委托(步骤60)。该数据送交的委托包括有事件序号20、数据送交目的地的逻辑任务结点。
如上述这样，为了在用于部门内的工作流序列的控制的同时也能用于部门间的工作流序列的控制，用户应用程序111向任务代理部122和商务代理部123双方发送结束报告，。此外，业务处理的序列不一定必须顺序进行存在即使某个部门内的处理没有完结也可以先行开始在其它部门的业务处理的可能性。例如，示于图4的工作流序列例的情况，对于订货金额是100万日元以上的品种，如果没有科长级的签字则不能完结部门内的处理，但对于其它的品种，例如，如果有主任级的批准签字便可完结处理。这样，对于部门内的处理完结了的部分，其它部门可先行领回进行处理。
在用户应用程序111及商务代理部123不能访问业务DB112时，商务代理部123从用户应用程序111接收事件序号20和保存该事件的局部文件的名称。然后，取出由指定的局部文件所指定的事件数据，并匹配对应于现在的事件状态24的事件状态转移基准表113上的事件状态的数据输入条件，判定是否应该转移事件的状态。在状态不转移时，结束处理。在事件的状态应该转移时，参照逻辑任务结点定义表115读取进行下一个处理的逻辑任务结点和处理结束的逻辑任务结点，执行步骤56及步骤57。如果承担代理部是自己，则执行步骤58，向确定的部门的任务代理部122送交附加有该局部文件名称的A/N。如果承担代理部不是自己，则进行对访问代理部127的数据送交委托。该数据送交委托包括有事件序号20、数据送交目的地的逻辑任务结点、处理结束的逻辑任务结点、包含在该事件的数据项目名称和其实例值、及下一个应该转移的事件状态24的值。
图14是表示商务代理部123的处理流的流程图，特别是表示商务代理部123接收来自其它的商务代理部123的A/N发布委托并对相符的部门发布A/N的处理。商务代理部123经由访问代理部127和网络转接部128接收来自其它的商务代理部123的A/N发布委托(步骤61)。该A/N发布委托包括事件序号20和数据送交目的地的逻辑任务结点。然后，参照业务DB112取出所指定的事件序号的事件(步骤62)，参照部署定义表117确定对应逻辑任务结点的现实的承担部门(步骤63)。在承担部门有条件的情况下，参照事件数据决定符合条件的承担部门。最后，向管理所确定的部门的任务代理部122送交A/N(步骤64)。该A/N包含有事件的事件序号20。
在用户应用程序111及商务代理部123不能访问业务DB112时，商务代理部123除了接收来自其它的商务代理部123的事件序号20和数据送交目的地的逻辑任务结点外，还接收数据项目名称和其实例值。如果具有所指定的事件序号的事件是新的事件，则商务代理部123在局部文件上追加具有该事件序号的事件数据。如果是已经登录在局部文件上的事件，则根据接收的数据更新文件中的事件数据。然后，如上述那样，执行步骤63及步骤64。向所确定的部门的任务代理部122送交附加有局部文件的名称的A/N。
图15是表示送交目的地特定表124的数据例子的图。送交目的地特定表124定义对应逻辑任务结点的物理任务结点和选择该物理任务结点的条件。物理任务结点的目的地为适当的管理该物理任务结点的商务代理部123所在的服务器(主机)。因此，也可以定义与该商务代理部123有关的标识符或者其服务器标识符。另外，物理任务结点的选择条件可以根据事件数据的内容判定并获取。
图16是表示访问规则保存表125的数据例子的图。访问规则保存表125对于每个物理任务结点设定对业务DB112的访问的可否，并对应目的地的物理任务结点设定网络的种类、编码/解码方式及安全模式。网络的种类是物理网络的种类、通信协议等。编码/解码方式设定数据压缩和复原的方式，安全模式设定加密的方式。但是，如果不需要根据网络的种类或目的地的物理任务结点加密，则按照其旨意进行设定。
图17是表示访问代理部127的处理流的流程图。访问代理部127接收来自商务代理部123的数据送交委托(步骤71)。该数据送交委托包括事件序号20和数据送交目的地的逻辑任务结点。另外，在数据送交目的地的逻辑任务结点是不能访问业务DB112的部门时，将关于该事件进一步包括数据项目名称和其实例值、处理结束的逻辑任务结点及下一个应该转移的事件状态24的值。访问代理部127参照业务DB112取出指定事件序号的事件，根据接收的数据项目值更新业务DB112(步骤72)。但是，该更新仅限于参照业务DB112，相对该事件的现在的事件状态24，数据送交目的源的逻辑任务结点为“可以更新”的数据项目，如果有其它的数据项目名称将被忽视。在进行了该更新后，再利用接收的该事件的事件状态24的事件状态24的值进行更新。然后，参照送交目的地特定表124特定对应数据送交目的地的逻辑任务结点的目的地物理任务结点(步骤73)。在送交目的地有条件的情况下，参照事件数据选择符合条件的送交目的地。
接着，判定是否有多个目的地物理任务结点(步骤74)。如果目的地物理任务结点是单一的(步骤74NO)，则步骤转移到77。如果目的地物理任务结点是多个(步骤74YES)，则根据事件的种类判定目的地物理任务结点是否应该是单一的(步骤75)。在得到目的地物理任务结点是多个时(步骤75NO)，则步骤转移到77。在目的地物理任务结点只限于一个时(步骤75YES)，则对送来数据送交委托的商务代理部123发送错误通知(步骤76)。
该错误通知是要求对用户应用程序111发送单一指定的送交目的地的A/N的通知。例如，在示于图15的送交目的地特定表124的例中，因为在品种名称叫作VTR的条件下作为物理任务结点可以选择B公司和C公司两个公司，所以，事件在商品订购时被判定为错误。但是，在事件估价委托的情况下，由于数据送交目的地有多个也可以，所以，不判定为错误。事件的种类根据事件序号20或事件具有的项目名称(属性名称)来判定。
在步骤77，访问代理部127相对目的地物理任务结点参照访问规则保存表125，判定目的地物理任务结点是否能够访问作为对象的业务DB112(步骤77)。在数据送交目的地不能访问业务DB112时(步骤77NO)，数据送交目的地的逻辑任务结点参照业务DB112对该事件的现在的事件状态24附加“可以参照”及“可以更新”的数据项目名称和其实例值，并进行对网络转接部128的数据送交委托(步骤78)。在数据送交目的地可以访问业务DB112时(步骤77YES)，则进行对网络转接部128的数据送交委托(步骤79)。这些数据送交委托任一个都包括有事件的事件序号20、目的地的逻辑任务结点及物理任务结点。
图18是表示网络转接部128的处理流的流程图。网络转接部128接收来自访问代理部127的数据送交委托(步骤81)，并参照访问规则保存表125确定到达数据送交目的地的网络的种类等(步骤82)。进而，按照该确定对传送来的数据进行加工，并对所指定的物理任务结点的商务代理部123送交A/N发布委托。
另外，虽然有点偏离本发明的原则，但也可以不是这样利用代理部来确定数据送交目的地，而是作业步骤的承担者通过用户应用程序111指定送交目的地。例如，在进行图15的品种名称VTR的订购或估价处理时，承担者将其委托目的地只指定为B公司的情况等便与此相当。该情况下，由该承担者进行的指定也优先于访问代理部127的判断。下面，对承担者指定数据送交目的地时的处理流进行说明。
首先，承担者根据用户应用程序111的引导进行业务处理，在处理结束时，对任务代理部122和商务代理部123发布结束通知。此时，指定数据送交目的地。任务代理部122接收它们并如上述那样控制部门内的工作流。商务代理部123接收来自用户应用程序111的通知，并判断是否发生了事件状态的转移。进而，在判断为发生了状态转移时，确定属于由没有图示的表所指定的数据送交目的地的逻辑任务结点。然后，参照担当商务代理表116判断哪里的商务代理正在管辖着该逻辑任务结点。
如果是自己管辖时，则对管辖该数据送交目的地的任务代理部122发布A/N。如果是其它部门或者公司以外管辖时，则进行对访问代理部127的数据送交委托。这里，访问代理部127代之参照送交目的地特定表124(图15)特定对应逻辑任务结点的物理的数据送交目的地，优先用户应用程序111所指定的数据送交目的地，并将其看成是目的地的物理任务结点。此后，如上述那样，判断其数据送交目的地所属的逻辑任务结点是否可以访问业务DB112，有必要的话，附加业务DB112上的事件的数据项目名称和实例值，并对网络转接部128进行数据送交委托。进而，网络转接部128进行数据的加工，并向指定的数据送交目的地进行数据的送交。
另外，在构成企业间交易系统的多个企业中，也可以有不设置商务代理部123的企业。虽然这样的企业不能进行涉及上述那样的企业间的工作流控制，但却可以经由访问代理部127接收由其它企业指定了数据送交目的地及数据送交目的源的事件数据，并可以经由访问代理部127对数据发送目的源企业送交回复数据。
进而，在图2所示的实施例中，访问代理部127、访问规则定义数据库126及网络转接部128作为提供者106是独立于A公司的计算机系统的，但也可以在A公司这样的企业所具有的计算机系统中实现。
权利要求
1．一种利用电子计算机进行的工作流控制方法，其特征在于在检测到业务处理中与事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据在部门内的工作流序列中规定下一个应该进行处理的承担者的部门内的工作流规则，判定下一个承担者是否处于应该处理的事件状态，如果下一个承担者达到应该处理的事件状态，则对下一个承担者发布动作通知。
2．权利要求1所记载的工作流控制方法，其特征在于当检测到与该事件数据有关的作业步骤结束时，按照该事件数据的数据输入状态，根据涉及部门间的工作流序列中规定下一个应该处理的部门的部门间的工作流规则，判定下一个部门是否处于应该处理的事件状态，如果下一个部门达到应该处理的事件状态，则对下一个部门发布动作通知，接收对下一个部门的动作通知并根据部门内的该工作流规则进行下一道作业步骤。
3．权利要求2所记载的工作流控制方法，其特征在于该下一个部门是用普通用语表现的功能部门，参照保存该功能部门的标识符和现实所存在的部门的标识符的对应关系的列表，把该下一个部门的标识符变换成现实的部门的标识符之后，对下一个部门发布动作通知。
4．权利要求3所记载的工作流控制方法，其特征在于该列表是对应该事件数据的内容设定对应该功能部门的实际部门的列表，通过使该事件数据的内容和该列表的事件数据的内容进行匹配来确定现实部门。
5．权利要求2所记载的工作流控制方法，其特征在于该事件数据是保存在业务数据库中的数据，在该下一个部门不能访问该数据库时，向该下一个部门同时送交该动作通知和包含在该事件数据中的数据项目名称和其实例值。
6．一种利用电子计算机进行工作流控制的计算机系统，其特征在于具有控制部门内的工作流的第1代理部，上述第1代理部具有在检测到业务处理中与事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据在部门内的工作流序列中规定下一个应该处理的承担者的部门内的工作流规则(119)，判定下一个承担者是否处于应该处理的事件状态，如果下一个承担者达到应该处理的事件状态，则对下一个承担者发布动作通知的单元；和接收对下一个部门的动作通知并根据部门内的该工作流规则进行上述的部门内的控制的单元。
7．权利要求6所记载的计算机系统，其特征在于，其进一步具有控制上述部门间的工作流的第2代理部；进行第2代理部和其它的第2代理部之间的数据传送的第3代理部；第2代理部具有在检测到与该事件数据有关的作业步骤的结束时，根据该事件数据的数据输入状态，根据涉及部门间的工作流序列中规定下一个应该处理的部门的部门间工作流规则，判定下一个部门是否处于应该处理的事件状态，在下一个部门达到应该处理的事件状态时，判定该下一个部门是属于该第2代理部管理范围内的部门还是属于其管理范围之外的部门，在是属于管理范围内的部门时，对管理范围内的第1代理部发布动作通知，在是属于管理范围之外的部门时，对第3代理部进行数据送交委托的单元；和从第3代理部接收动作通知并对作为目的地的第1代理部发布动作通知的单元；第3代理部具有接收来自第2代理部的数据送交委托并确定管理该下一个部门的第2代理部，向所确定的第2代理部送交动作通知的单元。
8．权利要求7所记载的控制工作流的计算机系统，其特征在于该所谓下一个部门是用普通用语表现的功能部门，上述第3代理部具有参照保存该功能部门的标识符和与上述第2代理部有关的标识符的对应关系的第3列表，在把从上述第2代理部接收的该下一个部门的标识符变换成与其它的第2代理部有关的标识符之后，对该其它的第2代理部送交动作通知的单元；该其它的第2代理部具有参照保存该功能部门的标识符和与上述第1代理部有关的标识符的对应关系的第2列表，在把从上述第3代理部接收的该下一个部门的标识符变换成与上述其它的第2代理部管理范围内的第1代理部有关的标识符之后，对作为目的地的该第1代理部发布动作通知的单元。
9．权利要求8所记载的控制工作流的计算机系统，其特征在于上述第3列表是根据该事件数据的内容设定与对应该功能部门的第2代理部有关的标识符的列表，上述第2列表是根据该事件数据的内容设定与对应该功能部门的第1代理部有关的标识符的列表，上述第3代理部具有匹配该事件数据的内容和上述第3列表的事件数据的内容并确定作为动作通知的送交目的地的第2代理部的单元，上述第2代理部具有匹配该事件数据的内容和上述第2列表的事件数据的内容并确定成为动作通知的送交目的地的第1代理部的单元。
10．权利要求7所记载的控制工作流的计算机系统，其特征在于该事件数据是保存在业务数据库中的数据，上述第3代理部具有在该下一个部门不能访问该数据库时，向该下一个部门同时送交该动作通知和包含在该事件数据中的数据项目名称和其实例值。
11．一种计算机程序，记录在计算机可读取的记录介质上，该程序运行在利用计算机进行工作流控制的计算机系统上，该计算机系统具有控制部门内的工作流的第1代理部，上述第1代理部具有完成如下功能的处理单元，即在检测到业务处理中与事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据在部门内的工作流序列中规定下一个应该处理的承担者的部门内的工作流规则，判定下一个承担者是否处于应该处理的事件状态，如果下一个承担者达到应该处理的事件状态，则对下一个承担者发布动作通知。
12．权利要求11所记载的程序，其特征在于上述的计算机系统进一步具有控制上述部门间的工作流的第2代理部和进行第2代理部和其它的第2代理部之间的数据传送的第3代理部，上述第1代理部进而具有接收对应下一个部门的动作通知并根据部门内的该工作流规则进行上述部门内的工作流控制的处理单元，上述第3代理部具有接收来自第2代理部的数据送交委托并确定管理该下一个部门的第2代理部，向所确定的第2代理部送交动作通知的处理单元，执行第2代理部的处理的该程序包括以下运行步骤(a)在检测到与该事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据涉及部门间的工作流序列中规定下一个应该处理的部门的部门间的工作流规则，判定下一个部门是否处于应该处理的事件状态，(b)在下一个部门达到应该处理的事件状态时，判定该下一个部门是属于该第2代理部管理范围内的部门还是属于管理范围之外的部门，在属于管理范围内的部门时，对管理范围内的第1代理部发布动作通知，在属于管理范围之外的部门时，对上述第3代理部进行数据送交委托，(c)接收来自上述第3代理部的动作通知并对作为目的地的第1代理部发布动作通知。
13．一种被实体化在计算机可读取的记录介质上的计算机程序，该程序运行在利用计算机进行工作流控制的计算机系统上，其特征在于该计算机系统具有控制部门内的工作流的第1代理部，上述第1代理部具有在检测到业务处理中与事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据在部门内的工作流序列中规定下一个应该处理的承担者的部门内的工作流规则，判定下一个承担者是否处于应该处理的事件状态，如果下一个承担者达到应该处理的事件状态，则对下一个承担者发布动作通知的处理单元。
14．权利要求13所记载的程序，其特征在于上述的计算机系统进一步具有控制上述部门间的工作流的第2代理部和进行第2代理部和其它的第2代理部之间的数据传送的第3代理部，上述第1代理部进而具有接收对下一个部门的动作通知并根据部门内的工作流规则进行上述部门内的工作流控制的处理单元，上述第2代理部具有在检测到与该事件数据有关的作业步骤结束时，根据该事件数据的数据输入状态，根据涉及部门间的工作流序列中规定下一个应该处理的部门的部门间的工作流规则，判定下一个部门是否处于应该处理的事件状态，在下一个部门达到应该处理的事件状态时，判定该下一个部门是属于该第2代理部管理范围内的部门还是属于其管理范围之外的部门，在是属于管理范围内的部门时，对管理范围内的第1代理部发布动作通知，在是属于管理范围之外的部门时，则对第3代理部进行数据送交委托的单元；从第3代理部接收动作通知并对作为目的地的第1代理部发布动作通知的单元，执行第3代理部的处理的该程序包括以下运行步骤(a)接收来自第2代理部的数据送交委托并确定管理该下一个部门的第2代理部，(b)向所确定的第2代理部送交动作通知。
15．权利要求1所述的工作流控制方法，其特征在于，具有如下步骤确定执行应该进行工作流控制的业务处理的多个部门，对于上述各个部门设置第1代理部；根据上述业务处理的运行，确定转移的多个业务状态，对应上述各个业务状态确定管理数据输入的第1代理部；生成使上述各个业务状态和与上述业务处理相关的数据库内的数据的输入状态相对应的工作流规则；在数据输入时，至少由第1代理部参照上述工作流规则；作为参照结果，在从有数据输入的部门直到改变到其它部门的业务状态期间，由与前者的部门相关联的第1代理部继续执行业务状态。
16．权利要求15所记载的工作流的控制方法，其特征在于将上述多个部门分配成每一个块包含至少一个部门的多个部门块，并对应上述的每一个部门块设置第2代理部；作为参照结果，在从有数据输入的部门改变业务状态到其它部门时，如果后者的部门和前者的部门属于同一个部门块，则与该同一个部门块相关联的第2代理部向与后者的部门相关联的第1代理部发布动作通知，并指示该业务状态的执行，否则与前者的部门相关联的第2代理部通知与后者的部门相关联的第2代理部，与后者部门相关联的第2代理部向与后者部门相关联的第1代理部发布动作通知，并指示其业务状态的执行。
17．一种工作流控制系统，其特征在于，包括执行应该进行工作流控制的业务处理的多个部门；对应上述的每一个部门设置第1代理部，根据上述业务处理的运行确定转移的多个业务状态，对应每一个上述业务状态确定管理数据的输入的第1代理部；保存与上述业务处理相关的数据的数据库；使每一个上述的业务状态和上述数据库内的数据的输入状态对应的工作流规则；在数据输入时至少第1代理部参照上述工作流规则；作为参照结果，在从有数据输入的部门改变到其它部门的业务状态期间，由与前者的部门相关联的第1代理部继续执行业务状态。
18．权利要求17所记载的工作流控制系统，其特征在于将上述多个部门分配成每一个块包含至少一个部门的多个部门块，并对应上述的每一个部门块设置第2代理部；作为参照结果，在从有数据输入的部门改变业务状态到其它部门时，如果后者的部门和前者的部门属于同一个部门块，则与该同一个部门块相关联的第2代理部对与后者的部门相关联的第1代理部发布动作通知，并指示其业务状态的执行，否则与前者的部门相关联的第2代理部通知与后者的部门相关联的第2代理部，与后者部门相关联的第2代理部向与后者部门相关联的第1代理部发布动作通知，并指示其业务状态的执行。
全文摘要
本发明用于对企业内的业务处理及企业间交易进行工作流控制,进行必要的数据送交。任务代理部检测用户应用程序的处理结束,并参照任务规则定义DB进行部门间的工作流控制。另外,商务代理部也检测该用户应用程序的处理结束,并进行涉及部门间的工作流控制,如果应该进行下一个处理的部门是其它企业,则对访问代理部进行数据送交委托。访问代理部参照访问规则定义DB对目的地企业发布动作通知。
文档编号G06Q10/00GK1218233SQ98122548
公开日1999年6月2日 申请日期1998年11月20日 优先权日1997年11月21日
发明者森俊彦, 曾我伸子, 细田直文, 曾我修治, 矢加部太郎 申请人:株式会社日立制作所