审批流是工作流比較简单的应用。审批流的特点是一个审批流模板相应一种单据。在审批流中仅处理单据的状态，如审批通过、审批不通过；审批流中会用到单据数据，如条件中、各种须要引用单据变量的地方。审批流没有涉及到多个单据之间的处理，因此审批流是相对简单的。从业界的大多数工作流来看，也不过实现了审批流而已，比方协同办公、以及ERP中的一些单据的审批。工作流如今应该是处于0基础阶段。
假设须要做真正的多单据的工作流，即业务流。比方从採购申请、採购订单、收货单到採购发票，可以定制一个完整的採购流程，更进一步，採购可以跟库存、生产或者销售模块连接起来，就更为完好了。同一时候，假设这些流程可以定制的，比方标准流程是这种，不同企业可以定制符合本企业须要的流程，就更完美了。在这一个过程中，我觉得须要解决两个较复杂的问题。
1、实体间架构映射问题。
Biztalk中源架构（Source Schema）到目标架构（Target Schema）之间通过XSLT来建立映射。一份源架构的实例（就是一份Xml），能够參照或者生成一份目标架构的实例（新的Xml）。这是比較好的解决方案，当然，能够定义一份简单的映射关系对比表，通过代码来转换生成了。这个工作难度应该不大。
2、实体的实例间多对多的关系。
比方收货单到发票，1张收货单能够开n张发票，n张收货单也可能开1张发票。所以就存在单据实例间的多对多的关系。这样的关系的处理，对于传统的功能性流程来说是比較简单的，通过多次參照就能够实现。单据实例间的关系是在两个单据数据之中来维护。可是对于利用工作流来处理这类问题时就变得比較棘手。第一个问题是是否引入流程实例的处理，假设没有流程实例，这跟传统的以功能为主的应用有何差别，仅仅是将流程通过图形化显示出来，这仅仅是一个壳。假设引入了，就会带来第二个问题。那就是单据实例之间到底具有什么约束？假设约束，那么仅仅能处理1对1的关系，比方1张收货单，就必须有1张发票相应，这样整个流程就能流转下来。假设没有约束，录入发票时，通过什么条件来选择订单？从业务角度来看，应该是符合这个流程模板的全部流程实例的上一种订单。假设选择了别的流程实例关联的发票，则那个流程实例就要中止。所以，就会出现流程实例的分之和合并，注意，不是流程模板的活动的分之和合并，而是流程实例。此处的处理，是业务工作流的关键所在。
考虑了几天，没有彻底想明确，写下来，供以后參考，希望做过这方面研究的看到了讨论一下。