工作流和审批流

      审批流是工作流比较简单的应用。审批流的特点是一个审批流模板对应一种单据。在审批流中仅处理单据的状态，如审批通过、审批不通过；审批流中会用到单据数据，如条件中、各种需要引用单据变量的地方。审批流没有涉及到多个单据之间的处理，因此审批流是相对简单的。从业界的大多数工作流来看，也仅仅是实现了审批流而已，比如协同办公、以及ERP中的一些单据的审批。工作流现在应该是处于初级阶段。

      如果需要做真正的多单据的工作流，即业务流。比如从采购申请、采购订单、收货单到采购发票，能够定制一个完整的采购流程，更进一步，采购能够跟库存、生产或者销售模块连接起来，就更为完善了。同时，如果这些流程能够定制的，比如标准流程是这样的，不同企业可以定制符合本企业需要的流程，就更完美了。在这一个过程中，我认为需要解决两个较复杂的问题。

    1、实体间架构映射问题。
          Biztalk中源架构（Source Schema）到目标架构（Target Schema）之间通过XSLT来建立映射。一份源架构的实例（就是一份Xml），可以参照或者生成一份目标架构的实例（新的Xml）。这是比较好的解决方式，当然，可以定义一份简单的映射关系对照表，通过代码来转换生成了。这个工作难度应该不大。
        
    2、实体的实例间多对多的关系。
          比如收货单到发票，1张收货单可以开n张发票，n张收货单也可能开1张发票。所以就存在单据实例间的多对多的关系。这种关系的处理，对于传统的功能性流程来说是比较简单的，通过多次参照就可以实现。单据实例间的关系是在两个单据数据之中来维护。但是对于利用工作流来处理这类问题时就变得比较棘手。第一个问题是是否引入流程实例的处理，如果没有流程实例，这跟传统的以功能为主的应用有何区别，仅仅是将流程通过图形化显示出来，这只是一个壳。如果引入了，就会带来第二个问题。那就是单据实例之间究竟具有什么约束？如果约束，那么只能处理1对1的关系，比如1张收货单，就必须有1张发票对应，这样整个流程就能流转下来。如果没有约束，录入发票时，通过什么条件来选择订单？从业务角度来看，应该是符合这个流程模板的所有流程实例的上一种订单。如果选择了别的流程实例关联的发票，则那个流程实例就要中止。所以，就会出现流程实例的分之和合并，注意，不是流程模板的活动的分之和合并，而是流程实例。此处的处理，是业务工作流的关键所在。

       考虑了几天，没有彻底想明白，写下来，供以后参考，希望做过这方面研究的看到了讨论一下。