| 本帖最后由 乐乐 于 2014-5-22 11:58 编辑 业务公式的本质作用是：将一个或多个表单中的数据经过变换后写入到另外的表单中，从而实现一定的业务逻辑，例如出库业务公式，从出库单中获取出库商品的数量，来更新库存表中对应商品的库存数量，其中的数据变换规则是：当前库存数量-本次出库数量。 在业务公式中，提供数据的表单称为数据源，写入数据的表单称为目标表单。 云表的架构是服务器客户端模式，云表浏览器是客户端，用来提供用户交互界面，云表服务器提供表单存储，查询等功能；用户在云表浏览器中完成表单的数据录入工作，当点击保存按钮时，云表浏览器首先将界面上的表单数据打包并压缩，然后通过网络提交到云表服务器上，云表服务器端程序处于时时监听状态，一旦发现有保存表单请求从网络上到达时，便会取出随请求一起传来的数据包，解压出表单数据，保存到后台数据库对应的总表中，接着云表服务器端框架会触发“表单保存后”事件，定义在该事件中的业务公式将被执行。 业务公式中有一个默认的数据源叫“本表单”，“本表单”是指触发业务事件导致业务公式被执行的那张表单，例如，单号为CK001的出库单被保存后会触发“表单保存后”事件，在事件中定义了一个更新库存表数量的业务公式，在这个业务公式中本表单就是出库单CK001。 "本表单"从客户端提交到服务器端之后，被缓存在服务器内存中，"本表单"先被保存到数据库的总表中，保存到总表中的那张表单就不再被称为"本表单"，保存之后，"本表单"还继续存留在内存中没有消失，因为它要被留作给被执行的业务公式当做数据源使用。 业务公式会遍历数据源，对每一条记录执行一次操作，可以把数据源想像成人体的心脏，他是业务公式执行的原动力，对数据源中的每一条记录都会触发一次心跳，驱动后续操作的执行，数据源的记录也像血液一样被输送到后续操作中使用。 情况：可以看作是一个业务场景，可以定义多个业务场景，执行条件用来描述与区别这些业务场景，执行条件对数据源的记录进行逻辑判断，满足执行条件的源记录才能进入情况中，执行后续操作。 扩展数据源：每个情况都可以单独定义自己的扩展数据源，以前，只能使用"本表单"以及"本表单"的明细做为数据源，在复杂的业务场景下，这远远是不够的，云表提供了扩展数据源的功能，扩展数据源通过查询总表获得的临时数据表，业务公式提供了两种查询方式，一种是通过定义列表数据规范进行查询，一种是直接对总表和表单的明细进行查询。 数据源可以拥有多级扩展，子数据源对父数据源进行扩展，扩展也是按照逐行进行的，对父数据源中的每一条记录都会执行一次子数据源扩展，一个父数据源可以有多个子数据源，如果子数据源查询出了多条记录，默认情况只取第一条记录，除非子数据源的“多记录”选项被打勾，表明这个子数据源是作为父记录的明细表进行扩充，系统会遍历明细子数据源的每条记录，如果明细子数据源还有子数据源，将会以此类推，逐级扩展。一个父数据源允许有多个子数据源，但只允许有一个子数据源作为明细进行扩展。 |
-
云表业务公式扩展数据源原理图
+10
4 条回帖
关于扩展数据源的讲解形象易懂，但是我还有个小疑惑：选择了扩展数据源后，数据源的记录和本表单的记录的关系是独立的还是有什么关联？
