取数能力为什么该上收成一层可配置的桥

应用层不直连第三方，取数与办事统一走一层可配置的数据桥。本文讲这座桥的分工与理由。

取数能力为什么该上收成一层可配置的桥

先说清楚：本文在讲什么

在该低代码 BPM 平台（bpm / 该低代码平台）里，表单、流程、单据、门户不直接握着数据库连接串或对方接口地址。中间有一座可配置的 数据桥——产品里就叫 数据源。

本篇讨论的是这座桥的一个设计点： 为什么要把连接上收成「桥」，而不是散落在表单和脚本里。

读完应能说清：低代码里数据源（数据桥）解决的治理问题是什么。 配置步骤见部署版本的数据源配置界面——本文讲作用、设置思想与设计理念。

主张

低代码若允许每个表单、每个节点、每段脚本自己握着数据库连接串或接口地址，短期能跑，长期一定乱。 该平台的立场很简单：应用层不直连第三方；中间必须有一座可配置、可复用、可观测的桥——数据源。

反面做法

• 请假单里写一段 SQL 取部门；报销单里再写一段几乎相同的 SQL。
• 流程结束后出库，把对方接口 URL 写进事件脚本。
• 换测试库、换网关，要全局搜字符串、怕漏改、怕改错。

结果不是「灵活」，而是：密钥与地址散落、语义重复、无人能说清系统到底依赖了谁。

该平台怎么切

应用与外部系统之间，不再是「每个页面一根线」，而是「多根应用线，接到同一座桥，再通向多方」。

场景

• 请假单选部门：表单字段引用「部门名单」，而不是内嵌连接串。
• 流程结束后出库：事件调用「出库办事」能力，URL 与鉴权留在数据源侧。

换环境时，优先改桥上的连接与参数，而不是改一百张表单。