财务共享事务启动器：跨系统拉起ERP界面的ITS翻译机制剖析

简介：面向SAP CRM实施顾问与系统集成人员，这份PPTX教程聚焦财务共享（SSF）配置中事务启动器的创建与外部系统连接。内容涵盖SAP GUI事务代码集成到Web UI的核心机制，讲解ITS（Internet Transaction Server）如何完成HTTP与SAP协议转换，并详细列出创建事务启动器的五个前置条件：SM59定义RFC连接、BD54定义逻辑系统、BD97分配RFC到逻辑系统、CRMS_IC_CROSS_SYS配置ITS服务URL，以及通过SWO1创建BOR对象。还展示了SSF中逻辑链接、通用出站插件映射及调用ERP T-code页面的实现路径。资源为单个PPTX文件，大小692KB，已有301人学习。适合需要快速掌握SSF与外部系统连接配置细节的SAP从业者。

1. 事务启动器：财务共享的一个按钮，凭什么跨系统拉起 ERP 界面

在财务共享场景里，最反直觉的一点是：用户在 Web UI 上点一个“查看总账凭证”按钮，实际是远程唤起了另一套 ERP 系统里那个老态龙钟的 GUI 事务界面。界面没有重新开发，只是在财务共享配置里通过事务启动器（Transaction Launcher）把它翻译成 HTML，再塞回浏览器。真正难的不是“点了一下”，而是这条链路里藏着协议转换、RFC 连接、逻辑系统、BOR 对象四层机制，任何一环配置错位，结果都表现成同一个症状：白屏或永远转圈。搞懂事务启动器，就是搞懂跨系统连接里最典型的一层外部系统连接中间翻译机制。

2. ITS：HTTP 和 SAP 协议之间的翻译层到底怎么运转

事务启动器眼里的世界很简单：它负责把 ERP 的 GUI 事务代码“翻译”成能在浏览器里显示的页面。但这句话拆开就没那么简单了——浏览器只懂 HTTP，ERP 应用服务器只懂自己的专有协议，两者之间没有任何共同语言。ITS（Internet Transaction Server）就是站在中间的那个翻译器，但它的工作方式比“翻译”两个字要复杂得多。

2.1 ITS 不是反向代理，而是一对互相配合的翻译进程

常见的误解是把 ITS 当成一个反向代理：浏览器请求进来，它转发给 ERP，再把响应返回。实际上，代理解决的是“地址不同”的问题，而事务启动器面对的是“协议不同、会话模型不同、渲染方式不同”的三重问题。

常见的实现思路是把 ITS 拆成两个角色。靠近 Web 一端的是一个 Web 网关进程，负责接收 HTTP 请求、解析 URL、管理浏览器会话；靠近 ERP 一端的是一个应用网关进程，负责持有 RFC 连接、发送 GUI 对话请求、接收 ERP 返回的屏幕数据。两个进程之间用内部协议通讯。

为什么拆两个而不是一个？因为两边的生命周期完全不一样。HTTP 请求是无状态的，一个请求处理完连接就可以断掉；而 ERP 的 GUI 对话是一条长期状态通道，同一个会话里连续多个屏幕必须落在同一条通道上。如果合成一个进程，连接一断，ERP 侧会话就丢了，用户会不断被踢回登录界面。拆成两个角色以后，Web 网关负责跟浏览器打交道，应用网关负责保活 ERP 通道，各管各的。

2.2 一次点击背后的时钟：从 HTML 到 Dynpro 再回到 HTML

用户点击“查看总账凭证”以后，底层发生的事情不是一次请求，而是一个持续的循环。

第一步，浏览器向 ITS 服务的 Web 网关发一个 HTTP GET 请求，URL 里带着目标逻辑系统、事务代码和启动方式。Web 网关收到后，把这个请求解析成一条内部消息，转发给应用网关。

第二步，应用网关通过已建立好的 RFC 连接，向 ERP 应用服务器发出“启动某个事务代码”的对话请求。这个时候 ERP 里那个事务代码对应的动态程序就被唤醒了，它开始执行，生成一个 GUI 屏幕，并把整个屏幕的字段布局、值、按钮状态、菜单结构全部序列化成内部格式，返回给应用网关。

第三步，应用网关拿到内部格式的屏幕数据，把它渲染成 HTML 页面，交回给 Web 网关。

第四步，浏览器显示页面，用户在上面填写数据、点按钮，表单提交回 Web 网关。Web 网关把这些事件重新包装成“用户按了某个按钮、在某个字段输入了内容”，传回应用网关，再传回 ERP 会话。ERP 继续执行，回到第一步，循环往复。

所以 ITS 做的不是“截屏推送”，而是把动态程序的界面元素翻译成 HTML 控件，再把 HTML 控件上发生的事件翻译回 GUI 事件。这也是为什么一个 ERP 界面在浏览器里看起来有点“老”，但按键、回车、下拉框的行为都能对上。

2.3 会话 ID：HTTP 无状态和 GUI 有状态之间的一本账

整个循环里最关键的是会话状态的维护。ERP 侧每个事务代码运行起来以后，它的内部状态——比如当前在哪一屏、输入了什么、产生了什么消息——都保存在 ERP 会话里。HTTP 协议本身不记状态，浏览器每发一个请求，对 Web 网关来说都像是一个陌生人。

ITS 的做法是给每个浏览器窗口维护一个会话 ID，URL 里、Cookie 里都带着这个 ID。Web 网关拿到请求以后，用这个 ID 去查自己维护的映射表，找到这条浏览器连接对应着哪一条 ERP 会话，再把请求路由过去。

这个机制也复盘解释了后续最常见的故障：只要会话 ID 丢失或者两边进程重启导致映射表清空，用户就会被当成新访客，看到的不再是刚才的操作界面，而是重新要求登录或回到启动器首页。这也是为什么排查启动器问题，第一件事就是看 URL 里的会话 ID 还在不在。

3. 创建前的四件事：SM59、BD54、BD97、CRMS_IC_CROSS_SYS 到底谁决定谁

在真正创建一个事务启动器之前，需要先完成四件事：SM59 定义 RFC 连接，BD54 定义逻辑系统，BD97 把 RFC 连接分配到逻辑系统，CRMS_IC_CROSS_SYS 配置逻辑系统的 ITS 服务 URL。很多人把这四个步骤当成四道独立的配置题按顺序做完就完事，但理解它们之间的关系，才是之后排查问题的基础。

3.1 SM59 只解决“能不能连上”，不解决“你是谁”

SM59 里创建的是 RFC 连接，它描述的是物理层面的东西：目标主机地址、系统编号、客户端、登录用户名、登录密码、连接类型。

很多人以为 SM59 配置好以后，跨系统调用就万事大吉。实际上 SM59 只解决一个问题：从当前系统到目标系统，能不能建立一条可用的连接通道。至于“这个目标系统在业务上叫什么”“CRM 侧应该用哪个名字去引用它”，SM59 一概不管。

常见的实现思路是，事务启动器场景里这条 RFC 连接要能承载对话式调用，连接类型需要选择允许会话保持的类型，而不是一次性的消息调用。因为启动器要拉起的是一个完整的事务界面，不是远程执行一个函数就结束。连接建立后，可以先在 SM59 里做连接测试，确认网络、端口、登录都没问题，再继续往下配。

3.2 BD54 和 BD97：把“名字”和“通道”绑在一起

BD54 用于定义逻辑系统。逻辑系统是一个短名字，代表“一个在业务上自主的系统”，即使一套物理环境里配了多个客户端，每个客户端也可以被定义成不同的逻辑系统。

为什么需要这一层命名？因为跨系统配置不该写死 IP 地址和系统编号。如果底层 ERP 从一个机房迁移到另一个机房，物理地址全变了，只要逻辑系统的名字不变，依赖方就不用改任何配置。改的只是 SM59 里的物理连接参数。这就是典型的“名字与地址分离”设计。

但逻辑系统只是一个名字，它自己不能通信。BD97 完成的是把 RFC 连接“分配”给逻辑系统的工作。做完这一步以后，当前系统里就有一张完整的映射表：逻辑系统名字指向哪条 RFC 连接，连接里边装着真实的地址和账号。

这四步的依赖关系，可以理解成一层套一层的引用：

SM59 是“路”，BD54 是“地名”，BD97 是把“地名”贴到“路”上。路修好了、地名定好了、路牌挂上了，接下来还缺一个东西——去那边办事走哪扇门、用什么入口。

3.3 CRMS_IC_CROSS_SYS：把逻辑系统翻译成 Web 入口 URL

CRMS_IC_CROSS_SYS 维护的是逻辑系统和 ITS 服务 URL 之间的对应关系。BD97 管的是 RFC 层面的路由，让系统间能用逻辑系统的名字发起远程调用；而 CRMS_IC_CROSS_SYS 管的是 Web 层面的入口，告诉 CRM 侧代码：这个逻辑系统的 ITS 服务地址是什么，启动器要去哪里找那个能翻译界面的翻译器。

到这一步，四个配置的职责边界就清楚了，按依赖顺序排列如下：

在实际项目里，最容易翻车的是四个配置跨系统不一致。开发环境里某一个逻辑系统叫 XCLNT001，预生产环境里被命名成了 XCLNT101，但 CRM 侧引用逻辑系统的地方依然写 XCLNT001。结果就是 RFC 连接测试完全正常，事务启动器却总是在点开的那一瞬间报错，因为它在目标系统里根本找不到叫这个名字的系统。

另一个容易踩的坑是 CRMS_IC_CROSS_SYS 里的 URL 路径和实际部署的 ITS 服务路径不一致。有时候是端口换了，有时候是路径里多了一层前缀，浏览器直接访问那个 URL 还能打开页面，但启动器拼接出来的地址却是错的。所以排查这类问题一定不要只看 RFC 层，要连 Web 层一起看。

4. SWO1 与 BOR 对象：为什么 ERP 事务代码要先被“包装”才能被调用

事务启动器最终要拉起的是一段 GUI 事务流程，比如总账凭证显示、发票过账、供应商主数据维护。这些流程在 ERP 里本来都有对应的事务代码，但 Web UI 不能直接输入一个事务代码就完事。它需要一个能被代码引用、能被映射、能被远程触发的“对象”。这就是 BOR 对象和 SWO1 存在的意义。

4.1 BOR 对象：把“界面流程”变成了“可调用方法”

ERP 里传统的事务代码描述的是一个“程序加屏幕”的组合：启动某个程序，进入某个屏幕，用户在里面输入数据、触发事件。这个组合不是面向调用的，它是面向人操作的。

BOR（Business Object Repository，业务对象仓库）做的抽象是：把一个事务流程包装成一个对象，给它一个对象类型名，再把“打开一张凭证”“显示一个单据”这类操作定义成对象的方法。调用方不需要知道底层事务代码是什么，也不需要关心是哪个程序、哪几张屏幕组成的流程，它只要说“我要调用某个对象的某个方法”，剩下的由启动器去翻译。

SWO1 就是用来创建和维护 BOR 对象的工具。常见的做法是：在 ERP 系统里用 SWO1 创建一个对象类型，比如把它取名 ZFIN_DOCUMENT，然后定义一个方法，这个方法映射到真实的事务代码。保存以后，这个对象类型就有了跨系统可调用的身份。

4.2 启动器创建的三步：BOR 对象、事务启动器、逻辑链接

在 ERP 侧创建完 BOR 对象以后，回到财务共享侧，创建事务启动器的工作分三步走。

第一步，在 SSF（共享服务框架）里创建一个事务启动器。这个启动器负责声明“我要拉起哪个 BOR 对象的哪个方法”。它相当于一张卡片，卡片上写的是业务动作的名字，背后指向一个具体的 ERP 事务流程。

第二步，创建逻辑链接。事务启动器本身还不知道目标系统在哪里，逻辑链接的作用就是把它和远端逻辑系统绑定，告诉它“你要去的那套 ERP 系统叫哪个逻辑系统”。这一步做完，启动器就有了目的地。

第三步，定义出站插件映射。这一步是把前端界面的通用操作出口，映射到具体的逻辑系统和事务代码上。这样做的目的在于：一个 Web UI 功能可能对应多套 ERP 环境，也可能一个 ERP 功能会有多个入口，全部靠映射统一管理，而不是在每个页面的代码里硬写事务代码。

4.3 代码视角：通用出站插件映射里最终拼出什么

“通过代码去调用 ERP T-code”这句看起来玄学，拆到代码层面其实就是拼 URL。下面这段是概念示意，不是某一个产品里的真实源码，但它表达了这个环节最终要做的事：

// 出站插件映射：根据逻辑系统名称，拼出事务启动器 URL function buildLauncherUrl(systemName, transactionCode) { // config 通常来自 CRMS_IC_CROSS_SYS 维护的 ITS 服务地址表 const itsBaseUrl = config.ITS_MAPPING[systemName]; // 事务启动器的通用 URL 结构：ITS 入口 + 启动参数 + 会话模式 const params = new URLSearchParams({ tx: transactionCode, // ERP 侧真实事务代码，来自 BOR 对象方法映射 session: 'keep', // 保持当前登录会话，避免二次登录 window: 'new' // 建议新窗口打开，保留 Web UI 原页面 }); return `${itsBaseUrl}/sap/bc/gui/sap/its/webgui?${params.toString()}`; } // 实际调用时不再硬编码事务代码，而是查映射表 const targetTx = mapping.get('displayVoucher', currentSystem); window.open(buildLauncherUrl(currentSystem, targetTx));

这段代码要理解三个点。

它的参数 it 入口不是随便写的路径，而是 CRMS_IC_CROSS_SYS 里配置好的逻辑系统 ITS 服务地址。前端代码在这里不关心物理地址，只按逻辑系统名字去查表，地址变了只需要改配置。

tx 参数来自 BOR 对象方法映射。ERP 侧设计者如果要改底层操作流程，只需要调整 BOR 对象的方法对应的程序，前端调用端完全无感。这就是“包装”带来的解耦。

session 参数控制会话保持方式。如果目标 ERP 系统接受单点登录票据，事务启动器可以沿用当前用户身份直接进入；如果不能，用户就会被带到 ERP 登录页。这个参数也决定了前面说过的会话链路要不要额外做票据透传。

到这里，事务启动器的完整调用链就形成了：Web UI 按钮触发 JavaScript，JavaScript 查出目标逻辑系统和事务代码，拼出启动器 URL，浏览器打开新窗口，ITS 收到请求后通过 RFC 连接唤起 ERP 会话，ERP 界面被渲染回浏览器。每一步都有自己的职责，任何一步配置错位，故障就会以五花八门的表象出现，这正是下一章的主题。

5. 常见问题与排查：连不上、白屏、掉会话，先查哪一层

事务启动器链路太长，导致一个症状可能对应多个故障点。所以排查的核心不是看到一个现象就猜原因，而是先判断故障出在 Web 层、ITS 层还是 ERP 层。这一章列几个典型的踩坑记录，每一条都是同一套链路、不同类型的问题。

5.1 现象：页面能打开，但跳出的是 ERP 登录框

原因：ITS 连接本身通了，HTML 页面已经渲染出来，但 ERP 会话里得到的是一个未认证的用户。常见的情况有两种：要么 SM59 里配置的登录账号密码不对，要么当前登录用户在 ERP 侧没有对应授权。

解决：先在 SM59 里做连接测试，确认账号能登录；再用这个账号手工登录 ERP，执行一遍目标事务代码，看有没有授权不足的报错。如果系统启用了单点登录，还要检查当前访问是否携带了有效的登录票据，缺少这一步，任何启动器都会把你丢到登录页。

5.2 现象：RFC 连接测试通过，但 Web UI 一直转圈或报“无法建立连接”

原因：RFC 链路是好的，问题出在 Web 层。最大嫌疑是 CRMS_IC_CROSS_SYS 里没有给对应的逻辑系统配置 ITS 服务 URL，或者配置的地址端口不可达。

解决：按“先直连后带参”的顺序验证。先把 CRMS_IC_CROSS_SYS 里配置的 URL 直接粘到浏览器地址栏，看 ITS 服务能不能正常响应。如果直连都打不开，检查端口和路径；如果直连能打开，再带事务代码参数访问。这一步能把 Web 层和 ERP 层分开，避免在错误的层里反复横跳。

5.3 现象：开发环境完全正常，预生产环境一点就崩

原因：这种“环境性故障”九成是配置漂移。比如预生产环境的逻辑系统名字和开发环境不一致，导致出站插件映射查不到目标；或者 BD97 的绑定关系没有跟随传输请求导入到预生产系统。

解决：把四个配置项逐项对比清单逐个核对。SM59 连接是否导入、BD54 逻辑系统名字是否一致、BD97 绑定是否生效、CRMS_IC_CROSS_SYS 里的 URL 是否匹配目标环境。不要凭经验只查其中一项，因为这个故障往往不是一项错，而是多项配置在环境之间交错错位。

5.4 现象：第一次打开正常，第二次操作就回到登录页或报会话丢失

原因：这是 ITS 会话生命周期的问题。最常见的诱因是 ITS 进程因空闲超时释放了会话，但浏览器侧还保存着旧会话 ID；也有可能是应用网关发生了重启，会话映射表被清空。

解决：先确认 ITS 服务的会话超时参数，和业务场景的典型操作间隔是否匹配。如果你的用户要花五分钟填一张表单，那超时时间至少要大于这个间隔。同时检查负载均衡配置，同一浏览器会话是否被分发到了不同的 ITS 进程——这会让会话 ID 在进程间无法共享，表现就是“换一次请求换一个会话”。

提示：排查这类问题有一个通用顺序——先看浏览器地址栏里的 URL 还能不能访问，再看 ITS 服务日志里有没有对应会话记录，最后看 ERP 侧会话是否存在。这个顺序就是 Web 层到 ERP 层的排查路径。

要特别提醒的是，事务启动器排查里的“可以打开”和“可以用”是两回事。能打开页面说明 HTTP 到 ITS 的通路是通的；真正在页面上执行一次完整操作，才说明 RFC 会话、授权、事务代码映射这一整条链路都正常。所以验证时不要只看登录页，要实际做一遍完整流程。

6. 设计取舍：为什么用 ITS 中间层，而不是把 RFC 直接暴露给前端

事务启动器这套机制，说白了是在 HTTP 和 ERP 专有协议之间硬生生加了一道翻译层。有人会问：既然已经有 RFC 连接，为什么不让 Web UI 直接通过 RFC 调 ERP？省掉 ITS，岂不是更简单？

答案藏在“会话”和“界面”这两个词里。RFC 适合调用一个明确的函数或 BAPI，它做的是请求-响应式的通信，不擅长维护一个持续交互的界面状态。而财务共享里的凭证审核、发票过账这类操作，是一套多屏幕、多步骤的交互流程，用户需要在不同屏幕之间来回跳转、修改、再看上一张单据。这种场景天然需要一条有状态的会话通道，而 ITS 在中间把 HTTP 那边变成无状态、把 ERP 那边做成有状态，正好补上了这个沟。

选择 ITS 还有一个安全收益：ERP 系统的对话端口不需要直接暴露给浏览器所在的网络，浏览器只碰得到 ITS 服务的 Web 端口。这样外部网络和 ERP 内部协议之间多了一道隔离带，安全策略容易落地。

但代价也很明显。多一层代理就多一层状态，多点配置就多点故障。这个设计带来的排查复杂度是真实存在的——常常一个白屏背后，可能同时牵涉 Web 网关、应用网关、RFC 连接、逻辑系统映射、会话超时配置五个环节。它不像现在流行的 API 网关那样干净，却依然是很多存量系统里最务实的选择。

我自己的教训是：接手这类配置时，不要急着动手改参数。先把从浏览器到 ERP 的链路图画出来，标清每一层用的连接方式、名字和地址，再决定改哪一项。从那以后，我在财务共享项目里每次接到事务启动器需求，都会强制先画一遍链路图再动配置，极少再被白屏牵着鼻子走。希望帮到你。

本文还有配套的精品资源，点击获取