在工作流系统中，业务流程按流程引擎定义的模型规则，定义成流程的一个一个节点。当流程实例运行时，流转到流程的各个节点，通过执行动作之类的操作提交关联的业务表单，导向流程的下一个节点，同时修改流程实例的状态，达到流程的流转。流程实例每流转一次，都会将当前节点的信息写入一个历史轨迹表，同时将下一节点的信息写入当前步骤表。当流程实例流转多次后，根据历史轨迹表的记录，就能追踪到此流程实例的实际运行轨迹。

      工作流系统的数据主要分为流程数据和业务数据，流程的历史轨迹表仅仅记录的是流程的数据，与业务数据业务表单无关，甚至是流程的上下文数据也记录不了。当流程实例在追踪历史轨迹的时候，作为监控使用，或者是历史步骤的再现，经常需要将此轨迹节点上关联的业务表单重新装入，查看监控当时的流程状态和业务状态。但流程的轨迹表仅记录的是流程的节点步骤信息。业务表的信息是不记录的，业务表记录的再现，只能通过流程数据和业务数据的关联去查找。查找出的业务记录只有一个{zh1}的状态，如果流程的多个节点对此业务数据做过修改，那么就很难在各个轨迹节点中还原出当时的状态。可能可以通过类似同一张单据在流程的多节点中流转的方式来达到，但如果多节点写了同一个字段的信息，就根本区别不出是流程的那个节点做的修改了，因为业务表没有记录轨迹。
  
      总结一下，实际上流程系统中的历史轨迹表，只记录的是流程实例运行的各节点的轨迹，没有记录业务数据的轨迹。
   
      当流程监控的时候要求对业务表的记录也做出xx的监控，那肯定需要建立业务表的轨迹表（或叫日志表），此业务轨迹表当属于业务系统的表，不属于工作流系统表。并且在业务轨迹表中增加一个 流程轨迹id字段 ,用于和流程的轨迹相关联。当流程流转时，产生流程的历史轨迹，同时也产生业务轨迹表的记录，并将流程的历史轨迹表记录id写入业务轨迹表中。当流程监控时，显示流程历史轨迹的同时，也可以通过轨迹表的id字段 关联出业务轨迹表中的业务记录，再现出当时的业务数据状态。此为流程轨迹表主键ID的一种用法。
   
      流程轨迹表的主键id，是流程实例运行轨迹的一个{wy}标志，与流程节点的id不一样，流程节点的id是流程定义节点中的{wy}标识，流程实例运行时，同一个节点，通过回退，循环，主动取回等可能会多次运行。但轨迹表的主键id则肯定是{wy}的，流程实例的每次流转都会生成轨迹表的新记录。当流程运行到节点上，关联的业务表单填写的是多条业务记录时，如主从表的录入，从表在流程的不同节点上多次填写。当流程监控时，需要再现出每个节点关联的从表业务记录时，就定位不了业务记录。如果在业务从表中增加一个 流程轨迹主键id 字段，在流程节点提交的时候，将此轨迹id写入 业务从表中，就能将流程的轨迹和业务从表记录关联起来了。此处如果写入业务从表的是流程节点id是不行的，流程回退，取回，一个节点重复执行时，就标识不了了。  此为流程轨迹主键id的另一种用法。
  
       流程轨迹主键id 还有一种更为巧妙的用法，作为流程主动取回后，再次发送，流程下一节点是否可执行的判断标志。流程实例的每次执行操作之前将流程轨迹id传递到前台，等待用户执行操作。提交操作时，取道页面传递回来的轨迹主键id，和流程轨迹表中当前步骤的轨迹id相比较，如果一致，则可以继续操作，如果不同，则表示流程轨迹已经发生了变化，需要再次打开链接重新执行此节点的操作。