请求的传送

作者：
作者：高林旭

1. 概述..............................................................................................................................................1
1.1 某公司服务器的架构 ........................................................................................................ 1

1.2 关于请求............................................................................................................................ 3

1.2.1 请求的种类和结构 ................................................................................................. 3

1.2.2 请求的查看 ............................................................................................................. 3

2. 同一服务器内的请求传送 .......................................................................................................... 4

2.1 操作步骤............................................................................................................................ 4

2.2 注意事项............................................................................................................................ 5

2.2.1 请求的反复传送 ..................................................................................................... 5

2.2.2 关于特定配置的传送 ............................................................................................. 5

2.2.3 多模块共有配置的协调 ......................................................................................... 6

3. 跨服务器的请求传送.................................................................................................................. 7

3.1 操作步骤............................................................................................................................ 7

3.2 注意事项.......................................................................................................................... 11

1. 概述
1.1 某公司服务器的架构
某公司服务器的架构
某公司的服务器架构如下：
服务器 机器编号 系统标识 Client 作用 要求
开发机 test02 DEV 100 配置环境，仅用作配置 配置都要记录在请求中
200 测试环境 不可更改跨 client 的配置
310

600 培训环境 用户和角色在此环境测试

汉得公司内部文档
生产机 sapapp PRD 800 生产环境 不可直接更改配置
关于 client 的约束，由相关的配置（t-code：SCC4）来决定。如下图所示：

例如，生产机 800 环境就是 No changes (Client-specific objects) allowed, No changes to

Repository and cross-client Customizing objects。

涉及到配置修改的时候，一般都应该在 DEV100 中修改，系统会自动记录请求（上图中的

选项 Automatic recording of changes 决定），然后再将此请求传送到相应的 client 中。
传送的操作有两种情况：
汉得公司内部文档
——同一服务器内的请求传送（如 DEV100 传送到 DEV200）；
——跨服务器的传送（如 DEV100 传送到 PRD800）。
1.2
1.2 关于请求
1.2.1 请求的种类和结构
请求是用来记录特定的配置修改的载体。在 DEV100 中，修改配置，系统会提示要求记录
到某一请求中，或者新建一个请求将其记入。
请求有配置请求和工作台请求两种。前者是 client-specific 的请求，后者是 cross-client 的请
求。系统会自动根据配置的内容决定它是配置请求还是工作台请求。

每一个请求下，都有任务和活动。在活动中，明细记录了配置的内容（表和数据）。
注意，开发的内容属于 cross-client 性质，因此如果记录请求，会放在工作台请求中。
1.2.2
1.2.2 请求的查看
利用事务代码 SE09 或 SE10 查看到某一用户名创建的请求：
汉得公司内部文档
点击 Display 按钮，即可看到 1.2 中的结果。
2. 同一服务器内的请求传送
2.1 操作步骤
同一服务器内的请求传送，按照如下操作：
步骤 1：登录 target client（注意是 target client）；
步骤 2：T-code SCC1，选择 Source Client 和 Transport Request，勾选 Including Request Subtasks，
点击 Start Immediately 按钮，执行请求的传送。

汉得公司内部文档
可以先测试运行一下，测试无误后再正式执行。
2.2 注意事项
2.2.1 请求的反复传送
同一请求可以反复被传送。也就是说，在请求已经传送到 target client 中后，如果配置又有
修改，仍可以记录到原先的请求中，并可以再次被传送。后续的传送将覆盖前一次的配置。
2.2.2 关于特定配置的传送
对于某些特定的配置，不能反复传送，例如会计凭证的编号范围（FBN1）。因为 client100
配置环境中的编号 current number 始终为 0，在目的环境已经有会计凭证业务发生后，其
current nunmber 会不断增大。如果在一段时间后，再将包含编号范围的请求传送到目的环境，
会将原先的 current number 覆盖掉。

汉得公司内部文档
对于这种编号范围，有两种处理方法：单独作为一个请求记录，只传最初的一次；或者不作
为请求记录，而直接在目的系统中修改。
类似的编号范围在多个模块中都存在，各模块都必须注意。
2.2.3 多模块共有配置的协调
某些配置在多个模块都存在，例如 CO82（Order Number Ranges），它牵涉到生产订单、内
部订单、项目的 network order，因此在 PP、CO 和 PS 模块都存在。这几个模块的配置者在
维护配置时，可能都会将它包含在各自的请求中。这会导致传送的结果相互 override。

汉得公司内部文档
因此，对于这种配置，要么将配置交由一个配置者维护，存放到一个请求中；要么各配置者
只改动自己的配置，不要改动其他人的配置。
3. 跨服务器的请求传送
3.1 操作步骤
跨服务器的请求传送，要分别在源系统和目的系统操作。
步骤 1：登陆源系统，如 DEV100 环境。
步骤 2：执行 SE09，找到自己的请求，展开第一层请求，选中下层请求，点 释放，或从
汉得公司内部文档
菜单释放。

下层请求释放完毕后，再选中上层请求，以同样的方式释放，直到全部请求被释放完毕。
由于很多配置集中在一个或几个请求中，会造成释放过程比较慢，请耐心等候，可以按
按钮看到最新状态。
步骤 3：完成后，登录目的系统，如 PRD800 环境。
汉得公司内部文档
步骤 4：执行 STMS。

点击 ，进入下一界面

双击 PRD 行，可以看到刚才释放的请求，注意通过 Owner 来区分自己和他人的请求。

汉得公司内部文档
如果在开发机又有新的请求被释放，按 进行刷新。
选中要传输的请求，按 ，确定 Target Client 为生产机，并执行传送。在 Options 标签中第
一个选项不要选中（选中意味着该请求还在队列中，以后还可以再次传送）。

步骤 5：执行完毕后，进入目的系统的后台，检查配置是否传送成功。
汉得公司内部文档
3.2 注意事项
跨服务器的配置请求传送后，请求已经在源系统中被释放，因此源系统中如果有后续的配置
修改，不能再记录到原先的请求中。此时必须建立新的请求。
为了避免请求过多，过乱，在上线前必须对请求进行有效的规划。一般来讲，在第一次传送
生产机以前，各模块应建立不多于 5 个的请求，包括：基本配置；编号范围配置；属于工作
台请求的配置；后台可维护的主数据的配置；等。
在第一次传送生产机（一般在上线前 1 个月左右）以后，上线以前，往往还会有新的配置修
改，此时建议遵循如下法则：
1. 每个模块新的配置修改都记录到各自模块的一个请求中（可以称为“基本配置 2”
）；
2. 配置修改后，传送到同一台服务器的测试环境（此环境应由生产机复制而来），测试；
3. 测试无误后，保留配置，不要立即传送到生产机；

4. 上线前最后确认一次开发机中的配置，确认无误后，一次传送到生产机。

进入“最后准备”阶段后，开发机和生产机之间各阶段的请求传送图示如下：

汉得公司内部文档
 DEV PRD

100 200 800

Request #1 1. Request Transport (cross-server) Config. #1

-------- --------
-------- --------
-------- --------
Client
P1: PRD Setup
2. Client Copy Mater Data
- Configuration #1
--------
- Master Data
…
--------
3. Request Tranport -
- Configuration #2
4. test...
(int-server,
many times) - Configuration #3
Config. #2
- Configuration #4 --------
Request #2 --------
-------- - Configuration #5 --------
--------
7. test...
--------
- Config. #3
5. Request Transport (cross-server, one-time)
P2: Go-live - Config. #4

Request #3 - Config. #5
-------- 6. Request Transport
Request #4
-------- #5
Request
--------
8. Request Transport (cross-server)
P3: Post Go-live

其中，request1 是在上线前 1 个月之前形成的；request2 是在上线前 1 个月内形成的，此期

间某一个模块内所有配置的修改都放在一个请求中。上线后由于修改的配置一般都是立即要
释放并传送到生产机中的，因此上线后的请求会比较多，于是有了 request3, reuqest4,
request5, ……。

汉得公司内部文档