企业官网建设流程全解析

简介：SAP BW配置及操作手册V1.3以PDF文档形式呈现，面向SAP BW实施顾问、数据仓库开发与运维人员，系统梳理源系统设置、Datasource创建、DSO与Transformation配置、TransferProcess抽取处理等核心流程，并讲解ETL过程、InfoArea/InfoObject等逻辑视图概念，以及BI Content和ECC作为数据源的常用事务码、激活与增量更新、数据源增强步骤，便于快速上手项目配置与日常排错。文件包共1个PDF文档，大小约2.19MB，内容精炼且组织清晰，可直接对照手册在SAP系统中演练关键配置。手册涵盖从基本原理、业务智能概念到数据存储对象、信息提供者和外部系统数据源映射的完整知识链，还给出BI_CONT安装、InfoObject导入及RSA1/RSD1等实操指引，能够帮助读者减少前期摸索，建立从数据抽取到查询展示的整体实施思路。目前已有152人学习，适合SAP BW初学人员或正筹备BW项目落地的实施团队作为案头参考。

1. 入手 SAP-BW 配置前先对齐这套数据流

拿到这份 1.3 版《SAP-BW 配置及操作手册》，多数人不是来学概念的，而是要把 ECC6 到 BW 的取数链路真正跑通。手册里反复出现的顺序——源系统、数据源、InfoPackage、DSO、Transformation、InfoProvider、Query——就是一条标准化数据流。最容易翻车的点集中在两处：一是数据源必须先激活，增量队列（RSA7）里才看得到数据；二是从 EP（Enterprise Portal）跳转 BW 前，必须把 RSRR_WEB 权限和单点登录配好，否则查询在 Portal 里始终打不开。手册中提到的RSA30TCT_DS01数据源，正是用来观察 BW 系统对 ECC 数据读取情况的典型入口。这份资料适合三类人：要搭 BW 模型的顾问、写数据源增强的 ABAP 开发，以及接手报表维护、需要快速定位“数据从哪来、在哪断、怎么续”的数据架构师。

2. 从 RSA3 测试到 InfoPackage：数据抽取链路的前半段

这一章只讲链路的前半段：ECC 侧的数据源如何被定义、测试，数据又是如何通过 InfoPackage 进入 BW 的 PSA（持久分段存储区）。后面章节再讲 PSA 之后的建模与转换。先把这段链路理顺，后续排错才能沿着数据流向逐段定位。

2.1 数据源是什么：先看一张元数据表

数据源（DataSource）本质是 ECC 与 BW 之间的一份元数据接口定义。在 ECC 侧，这份定义存放在ROOSOURCE表里。排查问题时，我习惯先查这张表，确认数据源在源系统侧是否处于激活版本，抽取结构是否就位。

SELECT OLTPSOURCE, -- 源系统侧数据源技术名称 OBJVERS, -- 版本：A=激活版，M=修改版 AUTHTYPE, -- 提取授权的类型，决定取数时采用哪种授权校验 DELTA, -- 是否支持增量抽取 ACTFLAG, -- 激活标志 EXTRSTRUCT -- 抽取用的结构名称 FROM ROOSOURCE WHERE OLTPSOURCE = 'RSA30TCT_DS01' AND OBJVERS = 'A';

这段逻辑在 SE16N 里直接作为查询条件使用。重点是OBJVERS = 'A'，RSA3 和后续的 InfoPackage 调度都依赖激活版数据源；如果只有M（修改版），说明源系统上做过修改但尚未激活，抽取时仍会沿用旧版本结构。AUTHTYPE用于区分提取授权的校验方式，不同取值对应不同的权限检查强度。EXTRSTRUCT则是实际抽取时遵循的字段结构名，数据源增强后，增强字段必须出现在该结构中，否则 RSA3 测试时看不到新增列。

2.2 RSA3 测试数据源：两个参数算出总记录数

RSA3 是测试 ERP 数据源最直接的事务码。进入后先选中数据源，再执行提取测试。界面上的两个参数很多人不注意，但手册里特别点明了它们的关系：

RSA3 查询到结果后，Display List按钮才可用，双击单条数据可以查看明细。这里有一个关键提示：如果查询出的总记录数和目标表行数不一致，先检查是不是包大小设置太小导致截断，或者是某些数据被源系统的增量状态标记为已抽取，从而被过滤。RSA3 在测试时会把每次调用的数据包写入 PSA 之外的临时存储，不会影响正式请求队列。

2.3 InfoPackage 与 PSA：数据进入 BW 的第一落点

数据源通过测试后，BW 侧需要创建 InfoPackage 才能真正把数据拉进来。InfoPackage 的抽取模式决定数据从 ECC 传到 BW 的方式，分别对应不同业务场景。

调度触发器（trigger）可以是后台作业、进程链或者手工执行，但增量模式对触发器有额外要求：ECC 侧数据源必须激活了增量开关（在 RSA5 中维护），否则 InfoPackage 界面上的 Delta 选项是灰色的。数据抽取到 BW 后，最先落进 PSA。PSA 是 BW 侧的原始数据暂存区，数据不经过转换，也不参与建模。它的核心价值在于断点续传：如果后续 DTP（数据传输过程）在转换时报错，可以从 PSA 重新提取而不必回源系统再抽一遍。所以遇到流程中断，先查 PSA 里的请求状态，不要一上来就重跑 ECC 侧。

3. ECC 作为源：RSA2 到 SBIW 激活与数据源增强的出口实现

ECC 作为源系统时，配置不在 BW 侧独立完成，而是 ECC 与 BW 两侧配合。不少项目在 BW 侧等数据等了半天，最后发现是 ECC 侧数据源没激活、增量开关没维护，或者增强出口代码没写对。这一章把 ECC 侧需要掌握的事务码和增强路径拆开讲。

3.1 先建源系统，再激活复制

进入 RSA1 创建源系统时，选择“SAP 源系统”并填入 ECC 的逻辑系统名。创建完成后，必须做两件事：激活源系统、复制数据源。激活是让 BW 认识这个源系统；复制则是把 ECC 侧已经存在的数据源元数据同步到 BW 侧。二者不能合并成一步，漏掉复制，RSA1 的源系统树里能看到节点，但展开后没有数据源列表，后续创建 InfoPackage 时也就无法选择数据源。

常见错误是 RFC 目标名填成了 ECC 系统的外部连接名，而非逻辑系统名。复制时报错 “RFC connection not found” 时，去 SM59 检查目标配置，确认 Connection Type 是 3（ABAP Connection）且 Target Host 可访问。复制成功后，在 RSA1 里重新进入源系统节点，数据源列表和 ECC 侧一一对应，此时才能继续。

3.2 RSA 系列事务码的分工

手册里列了一串 ECC 侧常用事务码，容易混淆的地方在于：哪些是激活用、哪些是测试用、哪些是管理员才碰的。整理如下：

实际项目里，RSA2 更多用于查看，RSA5 和 RSA6 是数据源增强时的必用事务码。RSA3 测试不通过时，优先回到 RSA5 确认状态是否为“已激活”；测试通过但增量队列没数据，则去 LBWE 检查对应应用组件是否激活了增量。RSA7 队列为空不等于没有增量数据，也可能是增量开关在 LBWE 里被关掉了。

3.3 数据源增强的完整路径

现场经常遇到标准数据源满足不了取数需求，比如需要额外带出供应商分类、客户行业属性，或者在抽取时做一次字段赋值。增强路径在手册里写得很清楚：SE11 加字段 → RSA6 去掉隐藏 → CMOD 实现出口 → BW 侧重新复制数据源。具体步骤：

1. SE11 中打开数据源对应的抽取结构，点击“追加结构”，添加自定义字段，比如ZATTRIB1。追加时注意字段名以 Z 开头，数据元素和域尽量复用已有对象。
2. RSA6 打开数据源字段列表，找到新加的字段，把“隐藏”标志去掉。这一步漏掉的话，BW 侧复制出来的数据源看不到该字段。
3. 事务码 CMOD 创建增强项目，分配增强 BW000001。注意增强项目里要正确关联到客户命名空间。
4. 实现出口函数EXIT_SAPLRSAP_001（业务数据）或EXIT_SAPLRSAP_002（主数据）。
5. 回到 BW 侧重新复制数据源，并在 Transformation 里补充新字段的映射规则。

3.4 出口函数怎么写才算合格

出口函数里能访问到抽取的字段列表，也可以对字段值做二次加工。下面是 EXIT_SAPLRSAP_001 中比较典型的写法：根据客户号回填名称属性。

METHOD exit_saplrsap_001. DATA: ls_fields LIKE LINE OF c_t_data, lv_kunnr TYPE kna1-kunnr. LOOP AT c_t_data INTO ls_fields. CASE ls_fields-fieldnm. WHEN 'KUNNR'. lv_kunnr = ls_fields-value. WHEN 'ZATTRIB1'. IF lv_kunnr IS NOT INITIAL. SELECT SINGLE name1 FROM kna1 INTO ls_fields-value WHERE kunnr = lv_kunnr. ls_fields-fieldnm = 'ZATTRIB1'. MODIFY c_t_data FROM ls_fields. ENDIF. ENDCASE. ENDLOOP. ENDMETHOD.

逻辑上，c_t_data是数据源字段名-值的内表，每条记录代表一个字段。第一遍循环先取到KUNNR，第二遍循环到ZATTRIB1时再查询 KNA1 表回填名称。注意MODIFY是整表行更新，所以必须先修改ls_fields-value，再把行写回内表。这个出口每个抽取记录都会被触发，适合做轻量级取值加工；如果要做聚合、去重或跨表大量关联，放到 BW 侧 Transformation 里更合适，避免拖慢 ECC 抽取性能。

4. 建模不是建表：InfoObject、DSO、Transformation 与 DTP 的配置顺序

BW 建模与普通数据库建表的差异在于：先有业务对象，再有存储结构，最后才有数据流转规则。手册里给出的配置顺序是 Query → 信息提供者 → ODS → 转换 → 数据源 → 信息包，这是设计视角的逆推顺序；实际创建时正好反过来，先建数据源和信息包，再建 DSO、Transformation、InfoProvider，最后做 Query。这一段按实际创建顺序展开。

4.1 先装 BI_CONT，再传信息对象

BI CONTENT 是一套预配置的信息模型，包含标准 InfoObject、数据源、DSO/InfoCube 和 Query。安装路径是：RSA1 → 双击 BI 内容组件树 → 全选后执行Transfer Selections→ 选择Install→ 最后Transfer all without dialog或Transfer selections。这里有过一次项目返工的经验：如果跳过Transfer all without dialog而只做Transfer Selections，部分依赖对象不会自动带过来，后面激活 InfoObject 时会报 “component does not exist”。

安装完成后，在 RSA1 的 InfoObject 节点下才能看到标准对象。手册里特意提醒：为了使用主数据，需要将 FI-IO 应用组件全部激活。这意味着仅安装 BI_CONT 还不够，LBWE 里对应应用组件未激活时，主数据数据源在 RSA3 测试中找不到数据。

4.2 InfoObject：把业务拆成特征和关键值

信息对象是 BW 建模的最小业务单元，分为特性（Characteristic）、关键值（Key Figures）、单位（Unit）和时间特性（Time Characteristic）。用 RSD1 创建时，业务描述类信息定义为特性，比如客户、物料、成本中心；度量值定义为关键值，比如销售金额、库存数量；单位挂到关键值上作为属性。时间特性是建模骨架，比如0CALMONTH、0FISCPER，每个 InfoProvider 至少要关联一个时间特性，否则查询无法按时间过滤。

InfoObject 存放在 InfoObject Catalog（信息对象组）下，Catalog 可以理解成文件夹，本身不参与查询逻辑，但决定了建模人员在 RSA1 里找对象的效率。建议按模块建 Catalog，比如财务、销售、物料各一组，避免几百个对象挤在一起。

4.3 DSO 类型选择：标准、写优化、直接更新

DSO（Data Store Object）是 7.0 之后的官方叫法，早期版本叫 ODS。它在数据源和 InfoCube/MultiProvider 之间承担存储与清洗的角色。DSO 分三种类型，选型错误直接影响激活性能和查询体验：

选择逻辑并不复杂：有覆盖更新需求、要求保留变更历史的，选标准 DSO；只需按请求追加、不关心历史变化的明细数据，选写优化 DSO；数据在进入 DSO 前已经完成清洗，后续直接由查询读取的，选直接更新 DSO。手册里提到“每个 DataStore Object 属于一个 InfoArea，一个 InfoArea 下可以根据规则更新出不同 DSO”，就是说 DSO 的划分要跟着业务规则走，而不是按源表一张对一表。

4.4 Transformation 与 DTP：规则和搬运工分开配

Transformation 是数据源与 DSO 之间的映射规则，DTP 才是真正把数据搬进 DSO 的执行器。在 RSA1 中，创建 DSO 后需要建立 Transformation，维护源字段到目标字段的映射。映射可以是直接赋值、常量，或者写一段 ABAP 例程（Routine）。例程里经常做单位换算、字符串清洗和金额格式修正。下面是一个把金额从分转成元的例程片段：

DATA: ls_source_fields TYPE /BI0/OIOBJCHANGE, lv_raw_amount TYPE /BI0/ORAWTOT. READ TABLE source_fields WITH KEY fieldnm = 'RAWAMT' INTO ls_source_fields. IF sy-subrc = 0. lv_raw_amount = ls_source_fields-value. ENDIF. IF lv_raw_amount IS NOT INITIAL. RESULT = lv_raw_amount / 100. ELSE. RESULT = 0. ENDIF.

逻辑上，source_fields是数据源侧传入的字段名值对表，fieldnm做字段定位，RESULT输出到目标字段。注意 READ TABLE 的字段名必须与 Transformation 中源字段的技术名称一致，否则例程会静默失败。这种例程适合做逐行处理；要做跨行聚合，则应该在 DSO 激活步骤里配置，或者用 DTP 的聚合功能，而不是写在这种行级例程中。

Transformation 建立后，创建 DTP，设置抽取模式：全量（Full）用于首次加载或重刷，增量（Delta）用于日常增量同步。DTP 执行时可以前台跑也可以后台跑，数据量大时建议后台执行，并通过 RSA1 的 DTP Monitor 检查执行状态。DTP 报错时，先看 PSA 节点是否为红色，如果 PSA 正常而 DTP 失败，问题出在转换规则上；如果 PSA 本身就是红色，则要回到 InfoPackage 重新抽取。

5. 用 RSA3 总记录数校验抽取，用 RSA7 排查增量队列

到这里，配置链路已经完整，但真正考验人的是验证和排错。最后分享三个高频场景的处理方式，都来自实际维护经验。

5.1 三个验证点

RSA3 测试时的总记录数校验，是最快的完整性验证手段。取显示记录/调用和显示提取.调用的乘积，比对预期行数。若不一致，优先排查包大小是否过大导致内存溢出，或者抽取条件中无意带入了过滤值。

RSA7 增量队列为空时，按三个路径依次排查：第一，RSA5 中确认数据源激活状态，且增量选项被勾选；第二，LBWE 中检查对应应用组件是否激活了增量；第三，确认是否做过初始化加载，增量模式未经初始化，第一次增量就会静默跳过。前面章节提过，增量抽取的 trigger 必须依赖源系统增量队列，队列空，后面全白搭。

5.2 常见处置速查

5.3 权限与 EP 集成收尾

BW 查询要在 EP 中正常展示，还需要把权限和认证链路收口。ECC 侧用户必须拥有RSRR_WEB权限对象，RSECADMIN 中配置分析授权，同时单点登录配置确保 Portal 用户能穿透到 SAP 系统。三者缺一不可，否则 Portal 中点击查询链接时，要么提示无权限，要么反复要求输入密码。把这三项在测试环境按顺序配置完成后，再用 RSA30TCT_DS01 这类数据源验证一次抽取链路，即可确认从 ECC 到 BW、再到 Portal 的整条路径已经畅通。

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