企业官网建设流程全解析

简介：这份PPT资料聚焦SAP CRM SSF财务共享配置与外部系统连接，面向从事SAP CRM实施、财务共享集成及Web UI开发的顾问与技术人员，帮助解决事务启动器创建、ITS服务配置及跨系统调用ERP T-code等实际问题。压缩包内仅1个pptx文件，约692KB，以图文幻灯片形式梳理关键配置节点，便于快速浏览与培训分享。内容围绕事务启动器展开，涵盖SM59定义RFC连接、BD54定义逻辑系统、BD97分配RFC连接至逻辑系统、CRMS_IC_CROSS_SYS配置ITS服务URL等前提步骤，并延伸至进入ERP系统创建BOR对象（SWO1）、SSF创建事务启动器与逻辑链接、定义通用出站插件映射，以及通过代码调用ERP T-code页面的完整链路。目前已有296人学习，适合需要理解SAP GUI事务集成到Web UI原理、掌握ITS协议转换机制并落地财务共享外部连接配置的读者参考。

1. SAP CRM SSF 财务共享配置与外部系统连接：从“连不上”到“跑得稳”

做过 SAP CRM 与财务共享对接的同行大概都有过这种体验：接口文档写得明明白白，SM59 里连接测试也是绿的，可一到业务单据过账就报“通信错误”或者“RFC 目标不可达”。问题往往不在代码，而在 SSF（Smart Forms / 共享服务框架）配置与外部系统连接这一层的参数没对齐。这个标题讲的就是：在 SAP CRM 侧，如何把财务共享服务框架配好，并让它与外部系统（通常是财务共享平台或第三方核算引擎）稳定通信。适合两类人：一是正在做 CRM 与财务共享集成的 ABAP 顾问，二是负责接口运维、被“偶发超时”折磨过的 BASIS。核心不是背事务码，而是理解 SSF 的调用链——从 CRM 单据触发，到 RFC/HTTP 出站，再到外部系统回执，每一段都有可调参数和可查日志。下面按“先立住原理、再动手复现、最后避坑”的顺序拆开讲。

2. SSF 财务共享配置的底层逻辑与连接选型

2.1 SSF 在 CRM 与财务共享之间到底扮演什么角色

SSF 在 SAP 体系里常被误解成“打印框架”，但在财务共享场景下，它更像一个出站适配层。CRM 里的报价单、服务确认、费用单需要生成财务凭证或共享任务时，SSF 负责把业务数据组装成外部系统能识别的结构，再通过 RFC 或 HTTP 投递出去。它不直接写财务库，而是把“业务动作”翻译成“共享请求”。常见做法是：CRM 端用 SSF 的 Smart Form 或自定义输出类型生成 XML/JSON 载荷，再挂到 SM59 维护的 RFC 目标或 HTTP 连接上。这里的关键是解耦——业务逻辑不关心外部系统是 SAP 还是非 SAP，只关心 SSF 输出结构是否稳定。如果跳过 SSF 直接写 ABAP 调 RFC，短期能跑，但一旦外部系统换版本或字段增减，维护成本会成倍上升。所以选型上，只要涉及财务共享，优先走 SSF 标准框架，哪怕前期配置麻烦一点。

2.2 连接外部系统的三种通道与选型依据

实际落地时，CRM 到财务共享的通道无非三种：同步 RFC、异步 qRFC、HTTP/SOAP。同步 RFC 适合实时性要求高、数据量小的场景，比如单笔费用报销过账；qRFC 适合批量、允许延迟的共享任务，比如月末批量推送凭证；HTTP/SOAP 则多用于外部系统是非 SAP 技术栈的情况。选型时看三个指标：延迟容忍度、数据量级、外部系统协议支持。我一般会先问外部系统能不能开 RFC，能开就优先 RFC，因为 SM59 的跟踪和日志最成熟；不能开再考虑 HTTP。注意，SSF 本身不绑定通道，它只负责生成输出，通道由输出类型或自定义程序决定。所以配置前先定通道，再回头配 SSF 的输出结构，顺序反了会反复返工。

2.3 SM59 目标配置与 SSF 输出类型的绑定关系

SM59 里建目标时，财务共享场景下最容易忽略的是**“远程主机”和“网关”的填写规则**。如果是同网段，直接填 IP 或主机名；跨网段则必须走网关，且网关主机要能解析目标系统。配置完别只点“连接测试”，那个测试只验证网络层，不验证 SSF 输出是否合法。真正的绑定在 SSF 的输出类型里：事务码 SPAD 或自定义输出类型中，指定“接收者”为 SM59 目标。常见做法是复制一个标准输出类型，改接收者参数和输出格式，再挂到 CRM 单据的 action profile 上。这里有个细节：输出类型的“处理类型”要选对，同步选“立即处理”，异步选“后台处理”，选错会导致单据保存时卡死或请求丢失。

3. 从零配通一条 SSF 到财务共享的最小链路

3.1 用 SM59 建 RFC 目标并验证连通性

先建目标，再谈 SSF。以下是在 SM59 中创建类型 3（ABAP 连接）的最小步骤，命令和参数按实际环境替换。

" 事务码 SM59 -> 创建 -> 连接类型选 3 (ABAP 连接) " 目标名称：ZFS_SHARE_DEV " 描述：财务共享开发环境 " 技术设置： " 目标主机：10.0.0.21 " 外部系统应用服务器 IP " 系统编号：00 " 客户端：100 " 登录语言：ZH " 用户：RFC_USER " 密码：****** " 注意：不要勾选“不用于负载均衡”，除非明确是单点

建完后点“连接测试”，看到“连接成功”只说明网络和账号通。接着点“远程登录”确认能进外部系统。如果连接测试报“超时”，先查SM59 -> 目标 -> 显示 -> 网关里的网关主机是否可达，再用ping和telnet <主机> 3300验证端口。参数说明：系统编号 00 对应端口 3300，01 对应 3301，以此类推。很多“连不上”其实是端口被防火墙拦了，不是 SAP 配置问题。

3.2 SSF 输出类型的创建与字段映射

SSF 输出类型决定“发什么”。用事务码 SPAD 进入“输出类型”维护，复制标准类型（如 ZFS_OUT）后修改以下参数：

字段映射在 SSF 的 Form 或自定义程序中完成。常见做法是写一个 ABAP 例程，把 CRM 单据字段赋给输出结构。例如：

" 在 SSF 输出例程中填充共享请求结构 DATA: ls_request TYPE zfs_share_request. ls_request-doc_type = 'EXPENSE'. ls_request-doc_id = is_document-doc_id. ls_request-amount = is_document-amount. ls_request-currency = is_document-currency. ls_request-cost_center = is_document-cost_center. " 调用 SSF 函数输出 CALL FUNCTION 'SSF_FUNCTION_MODULE_NAME' EXPORTING formname = 'ZFS_SHARE_FORM' IMPORTING fm_name = lv_fm_name. CALL FUNCTION lv_fm_name EXPORTING is_request = ls_request.

逻辑说明：先组装业务结构，再动态获取 SSF 函数名并调用。参数说明：formname是 Smart Form 名称，is_request是自定义结构，必须与 Form 接口一致。如果调用后没输出，先查SSF_FUNCTION_MODULE_NAME是否返回空，再查 Form 是否激活。

3.3 用 WE19 和 SOST 做端到端验证

配完后别急着上生产，用 WE19 模拟入站或 SOST 查出站。SOST 里能看到 SSF 生成的请求状态：绿灯表示已发送，黄灯表示排队，红灯表示失败。红灯点进去看“错误文本”，常见的是“RFC 目标不可达”或“输出格式错误”。如果是 RFC 问题，回 SM59 查跟踪；如果是格式问题，回 SSF 查 Form 逻辑。另一个技巧：在 SM59 里开“跟踪”功能，能抓到完整的 RFC 调用参数，比看 SOST 更细。验证顺序建议：SM59 连通 -> SSF 输出结构正确 -> SOST 状态绿 -> 外部系统确认收到。四步都过才算链路通。

4. 避坑：SSF 与外部系统连接的高频翻车点

4.1 连接测试绿但业务报错“RFC 目标不可达”

现象：SM59 连接测试成功，但单据保存时提示 RFC 目标不可达。原因：连接测试用的是当前登录用户，而业务运行时用的是后台用户或系统用户，权限或目标解析不同。解决：在 SM59 里用“当前用户”和“指定用户”分别测试，确认业务用的用户有S_RFC权限，且目标主机在后台作业的 hosts 文件里能解析。

4.2 SSF 输出乱码或字段截断

现象：外部系统收到的 XML 里中文变问号，或金额字段少几位。原因：SSF Form 的字符集与外部系统不一致，或输出结构长度定义过短。解决：在 SM59 目标里设置“字符集”为 UTF-8，Form 里用CONVERT_TO显式转码；字段长度按外部系统 WSDL 或接口文档定义，宁长勿短。

4.3 异步 qRFC 队列卡死导致单据积压

现象：单据保存后长时间不推送，SOST 里队列一直排队。原因：qRFC 队列被前一个失败请求阻塞，后续请求全部等待。解决：用 SMQ1/SMQ2 查队列状态，先释放或删除失败条目，再重推。预防措施是给队列设最大重试次数，别无限重试。

4.4 外部系统换 IP 后 SSF 仍发旧地址

现象：外部系统迁移后，SSF 请求发到旧 IP 超时。原因：SM59 目标里写的是硬编码 IP，没走域名或负载均衡。解决：改用主机名，并在 DNS 或 hosts 里维护；如果必须用 IP，建立变更清单，迁移时同步改 SM59。

4.5 权限不足导致 SSF 无法生成输出

现象：单据保存无报错，但 SOST 里没有任何输出记录。原因：执行 SSF 的用户缺少S_DEVELOP或输出类型相关权限。解决：用 SU53 查权限缺失项，补S_DEVELOP（调试用）和S_SPO_ACT（输出控制），生产环境按最小权限原则只补必要对象。

5. 进阶：用 SM59 跟踪和 SSF 日志把问题钉死

5.1 打开 SM59 跟踪抓完整 RFC 调用

SM59 的跟踪功能是排查连接问题的“后悔药”。进入目标 -> 跟踪 -> 激活，然后复现业务操作，再回来看跟踪记录。跟踪里能看到 RFC 调用的函数名、参数、返回码和时间戳。如果返回码是RFC_SYS_EXCEPTION，多半是外部系统内部错误；如果是RFC_COMMUNICATION_FAILURE，则是网络或目标配置问题。注意跟踪会消耗性能，生产环境用完即关。

5.2 用 SOST 和 SLG1 交叉定位 SSF 输出失败

SOST 看发送状态，SLG1 看应用日志。两者交叉能快速定位是 SSF 生成阶段失败还是发送阶段失败。如果 SOST 无记录但 SLG1 有“输出类型未找到”，说明 SSF 配置没挂到单据 action 上；如果 SOST 有红灯且 SLG1 无记录，说明失败在 RFC 层。我一般先查 SLG1 的对象ZFS_SHARE，再查 SOST 的请求号，两边时间戳对得上就能锁定环节。

5.3 一个可复用的排查顺序表

按这个顺序走，90% 的“连不上”都能在 15 分钟内定位。剩下 10% 多半是外部系统内部逻辑问题，把 SM59 跟踪和 SSF 输出原文发给对方，比口头描述高效得多。

5.4 我踩过的一个坑：SSF Form 激活状态被忽略

有一次调了一下午，SM59 绿、SOST 绿，但外部系统说没收到数据。最后发现 SSF Form 改了之后没激活，运行时用的还是旧版本。血泪经验：改完 Form 必须点“激活”，且要在 SOST 里确认请求用的是新版本。后来我养成了一个习惯：每次改 SSF 配置，先跑一笔测试单据，去 SOST 看请求详情里的 Form 版本号，确认无误再继续。这个习惯帮我省了至少三次通宵排查。希望帮到你。

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