用外部数据源实现关联企业业务流程贯通
我们知道Excel服务器软件是支持多应用系统（俗称“多帐套”）的，一个大型的企业集团，通常包含若干成员企业，如果说整个集团使用一套Excel服务器软件，一种做法是整个集团建一个应用系统，也就是一个数据库，包含所有成员企业的信息；另一种比较常见的做法，则是针对每个成员企业分别建立其应用系统（“帐套”），各成员企业的信息相对独立，在不同的数据库中。
分别建不同的应用，各企业均有自己独立的一套组织机构/角色/用户，以及相应的业务模板和数据，对系统的管理和设计各自独立进行，管理简便，易于分而治之；但是有一种情况我们需要考虑，就是完全的“独立”往往不存在，实际业务中，同一集团下属各企业之间往往是上下游或协作的关系，存在紧密的业务联系，体现在信息系统中，则是两个应用系统的数据能够互相访问，业务流程能够衔接。
建立两个应用系统之间的联系，一种简便灵活的方式是通过外部数据源。我们通过一个实际的例子来看一看外部数据源能帮我们做到什么。一家汽车集团，有两家成员企业-----整车厂和轮胎厂，它们之前存在供销关系，整车厂下达采购订单，传递到轮胎厂，轮胎厂接到后形成自己的销售订单，安排出库。为了完成这样的两个应用系统之间的业务衔接，我们需要解决好如下的几个问题：
1、整车厂的采购需求如何传递到轮胎厂？
2、采购需求已经传递出去之后，还能不能再改，怎么改？
3、轮胎厂已接获的采购需求，进行到何种程度，整车厂如何得到反馈？
一种可行的方案是，我们在两个应用中各自建立到对方数据库的外部数据源，为了尽量使得系统的设计简洁，减少数据一致性维护的需要，我们可以遵循一个原则，就是，对外部数据源的使用保持单向，即，轮胎厂从整车厂的外部数据源获得数据，但是绝不往回写；同样，整车厂从轮胎厂的外部数据源读取数据，也绝不往回写，就像下面的图示：
下面具体来看看两厂之间的供销业务衔接如何实现。
问题1，整车厂的采购需求如何传递到轮胎厂？
首先，作为准备条件，整车厂的采购订单模板，在设计上要满足两个条件：1）一定要有一个订单号并保持唯一，这样我们才能追踪每个采购订单的执行情况和变动情况；2）要有一个最后修改时间字段，记录采购订单最后一次被修改的时间；3）有一个状态字段，标识其在下游厂家的执行情况。
其次，我们在轮胎厂的应用中建立一个外部数据源，指向整车厂的数据库，并且对整车厂的采购订单相关的数据表进行注册。
第三，在轮胎厂的应用中，定义一个采购需求模板，它能够从整车厂导入产生的采购订单，这个模板的设计有几个要点，1）它要包含原始的整车厂采购订单的信息；2）它是定时自动填报的，具体定时的时间间隔，根据业务需要决定，可以一天一次、几小时一次、甚至1分钟一次；3）它要包含一个状态字段，用来标识收到的采购订单在轮胎厂是否已进入后续处理，这个状态字段，将能决定一份已经接收过来的采购订单是否还能再修改或撤销；4）这个模板上有一个字段，用于记录每次导入的时间点，将这个时间点与整车厂采购订单中的“最后修改时间”比较，就能够区分每次导入所应当涉及的整车厂采购订单是哪些。
最终，这个用来接收来自整车厂采购订单数据的模板大约长这样：
它的主表上只有两个字段：本次导入时间和上次导入时间，前者通过系统变量当前日期时间在保存时产生，后者在新建时通过表间公式得到。
在这个模板上，我们先通过3条提数公式，完成对模板上数据的填充：
首先，表一新建，就利用表间公式提取上次导入时间：
接下来，从整车厂外部数据源中提取自上次导入时间以来新建的或更新的采购订单，填充明细表的前5列：
最后，结合过去已导入的信息，判断本次从外部数据源读取的采购订单中，哪些是曾经导入过的，哪些已经进入了后续流程。
获得了上述信息之后，保存表单，实际把来自整车厂外部数据源的数据保存到轮胎厂的应用数据库中。
对于自上次导入以来新增的采购订单，我们会相应地新建一份《销售订单》（上游厂的采购，相当于下游厂的销售），而对于自上次导入以来被修改的采购订单，如果尚未进入下一流程，则直接修改上次导入的信息，如果在本厂已经进入下一流程了，就什么也不做了。至于何谓“进入下一流程”，取决于实际业务是怎样进行的，作为一个例子，我们这里采用一个简单的标准，就是导入生成的销售订单已经被审批。
上述操作用过一条新建表单公式，以及一条回写修改公式实现：
问题2，采购需求已经传递出去之后，还能不能再改，怎么改？
这个问题涉及到两方面内容。
首先，站在轮胎厂的角度，如果已经接收了来自整车厂的采购订单，形成了本厂的销售订单，之后整车厂的采购订单内容发生了变化，再次传过来了，本厂的销售订单要不要变？正确的回答是：根据实际业务的要求来做，我们上面举例的情况是，如果上次导入的销售订单还没有审批，则根据最新传过来的信息更新销售的订单的内容，但是已审批过的销售订单就不能再动了；
另一方面，站在整车厂的角度，面临的问题是，已经传达给轮胎厂的采购订单，还能不能再改（或者是）再删了？正确的回答依然是：根据实际业务的要求来做，假如说，整车厂的采购订单是否还能修改或撤销，必须考虑到其在轮胎厂的执行情况，就需要有一种把信息从轮胎厂再反馈回整车厂的机制，也就是说，在两厂之间的信息流动不是单向的，而是双向的。
问题3，轮胎厂已接获的采购需求，进行到何种程度，整车厂如何得到反馈？
反馈的方式有两种，区别在于返回操作从哪里发起，如果从轮胎厂应用发起，则是向整车厂外部数据源回写，如果从整车厂发起，则是从轮胎厂外部数据源读取，我们还是用具体例子来说明。假设我们需要达到的目的是，从整车厂传送到轮胎厂的采购需求，形成销售订单后，一旦被审批，整车厂这边就不能再对采购订单进行修改或删除了。“不能再修改或删除”，我们可以利用模板的“锁定”功能，我们之前已经提过，在整车厂的采购订单模板中，要包含一个状态字段，我们可以针对状态字段设置锁定条件。那么剩下的就是，如何在轮胎厂的销售订单被审批之后，能够更新整车厂采购订单的状态，使其能够被锁定。
有两个办法可以实现对整车厂采购订单状态的更新，一种是直接回写，即，在轮胎厂的应用中，销售订单审批之后，用一条回写修改公式，更新作为外部数据表的整车厂采购订单的状态字段；另一个办法，不用更新，则需要在整车厂的应用中，也设置外部数据源，指向轮胎厂的应用，从轮胎厂定时自动获取销售订单的审批情况，然后更新本应用采购订单的状态。这两个办法最终的结果都是更新了整车厂应用中采购订单的状态，但是更新动作的发起位置不一样，一个是从外部（也就是轮胎厂）应用发起，一个是从本应用发起。因为这个发起位置的不同，相应地采购订单锁定条件的设定也会稍有不同。从外部应用发起的更新，若想此更新能触发表单的锁定，相应的锁定条件需要和时间相关。
外部数据源的安全
最后，我们多说一点和外部数据源相关的安全措施。
我们知道，在注册外部数据源的时候，需要输入到外部数据源的链接账户。安全性更好的做法是，通过数据库管理的后台，在外部数据库中，单独建一个数据库账户，此账户仅仅对需要注册的个别几个数据表或视图设置权限，用这个账户去注册外部数据源，这样保证不熟悉外部数据源的应用系统管理员，无法访问到对方未授权的数据。
基于同样的考虑，如果一个需求，既能通过对外部数据表的回写实现，也能通过在对方应用中建外部数据源并读取的方式实现，究竟如何选择，也可以从安全的角度去权衡，一般来说，只能读，比既读又写，会更安全，这里所说的安全，更多是指防止没有经验的设计者由于定义了一条错误的回写公式导致外部数据源中的数据被不当改变。