工做流和审批流

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

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

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

       考虑了几天，没有完全想明确，写下来，供之后參考，但愿作过这方面研究的看到了讨论一下。