业务公式:深入理解

来自企业管理软件文档中心
2018年10月16日 (二) 17:33Nathan讨论 | 贡献的版本

(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)
跳转至: 导航搜索

定义

业务公式是在服务器端执行的,根据客户端提交过来的表单请求,在执行这些请求的基础上,附带进行一系列对服务器端的数据表的其他操作的“程序”。

术语详解

客户端表单(本表单)

即客户端的模板中所显示的客户端的数据集。数据集就是客户端的一个json文件。在客户端请求服务器端的操作时,这个文件需要提交到服务器端来。在业务公式里,这个数据集叫“本表单”。

客户端请求

客户端向服务器可提出三种操作请求,分别是新建、保存和删除。这些操作是客户端向服务器端提出的,对本表单在服务器端所对应的数据所要进行的操作。这些操作,服务器是无条件执行的操作,并不是业务公式中所定义的操作。业务公式中所定义的操作,只是伴随这些操作的“附加操作”。如果定义的是在“保存后”,则服务器是先执行请求的操作,然后执行附加操作。如果定义的是保存前,则反过来。 所以,在定义业务公式时,首先要明确的是,是附加在客户端提出的什么请求上所执行的附加操作。

目标对象

即保存在服务器端的被业务公式选来进行附加操作的数据表对象。它和客户端的Json作为源对象是相对应的。但目标对象也可以选择是“本表单”对应的数据表对象,也可以是其他任何表单对应的服务器端的数据表对象。

数据表对象

在云表平台上的“数据表”和通常关系型数据库系统中的数据表的概念有些区别,云表里的“数据表”,默认是关系型数据库中的一对“主-从表”的整体。在业务公式里,通常把主表就叫“本表单”,而把从表叫做“明细”,和在定义模板时的“基本数据”和“明细数据”对应。在客户端,会把这个主从数据表按主从关系保存为一个json文件,客户端通过和服务器端交换这个json文件来实现数据的网络化流转。所以,“表单”,“数据表”,json文件,在本质上都是指一个流转于客户端和服务器端的“主从数据表”。这个主从表在客户端接受客户的交互操作,在服务器端可以接受储存相关的请求操作,并可在一个主从表接受储存请求操作的同时,附加一些对本主从表或其他的主从表的加工操作。但一个业务公式,只能对一个目标对象进行附加操作。

情况

在业务公式定义中的“情况”的含义,是指客户中提交请求的数据集的数据的状态。数据的某种取值或取值的组合,就代表着某种有业务上的含义的“情况”,表明客户端的请求是在什么“情况”下提交的。实际上,也就是告诉服务器,在执行附加操作前,需先查看在客户端发生的情况是什么。如果接下来的操作如果是以某种情况为前提,就要在这里进行定义。

数据源

业务公式用来告诉服务器,在对服务器端的某个目标数据集进行加工操作时,除了可用客户端提供过来的数据集外,还可以用服务器端本身就储存着的数据表或数据接口,先对本表单的数据进行扩展,然后使用经过扩展的数据表来对所选的目标表的内容来进行修改。
被扩展的对象包括对本表单的基本信息表的扩展和明细信息表的扩展;扩展方式包括横向扩展和纵向扩展两种方式。最终结果是将本表单的基本信息的每条记录,扩展成一个更宽,更长(多条记录的)一张大表,原来较小的明细表,也可以扩展为更宽更长的一张大表。

由于对数据源的扩展和对目标表的操作是可以在循环中进行操作的,每次循环的操作都可能修改数据源,因此,数据源的扩展,也可以做出动态扩展的效果。

数据接口

存储在服务器上的一些特殊的数据集,它们是通过对数据表的数据进行提炼、过滤而得到的,再用来为数据表的填充提供有规定格式和范围的一种业务基础数据。数据接口也是服务器端根据专门的定义来生成的。

运行机制

深入理解业务公式1.png

数据源扩展机制

深入理解业务公式2.png

操作周期和顺序

允许的设计组合的约束是:

1.对目标表的主表操作,要么使用源表的主表驱动,要么使用源表的明细驱动。系统没有提供分别定义主表的驱动和从表驱动两份驱动的机会。

2.对目标表的明细的操作驱动,也和对1.一样,要么使用源表的主表驱动,要么使用源表的明细驱动。系统没有提供分别定义主表的驱和从表驱动两份驱动的机会。

所以,允许的可能设计组合有四种:

1.源表主表驱动目标主表+源表主表驱动目标明细;

2.源表主表驱动目标主表+源表明细驱动目标明细;

3.源表明细驱动目标主表+源表主表驱动目标明细;

4.源表明细驱动目标主表+源表明细驱动目标明细。

这四种设计组合都有意义。

深入理解业务公式3.png