Files
sap-cli-skill/docs/adt/05.提交与传输-原理.md
吴让宇 c5905a5b1e refactor: 本仓升为唯一源(原 sap-cli 源码仓归档)
方向反转:此前 SKILL.md 是「模板渲染产物」、sap-cli 是源;现 sap-cli 归档,
sap-cli-skill 承接开发与分发,SKILL.md 回归手工维护的正本。

迁移(来自 sap-cli,共 104 文件):
- tests/           692 例测试(15 个文件的内联 sys.path 改指 assets/)
- openspec/        SDD 规格与归档变更(42 文件)
- docs/            开发文档与 ADT 原理(含 dev/CLAUDE.md、AGENTS.md)
- .claude/         rules 副本 + settings.json(供 Claude Code)
- .github/ .hermes/ .pre-commit-config.yaml .editorconfig CLAUDE.md
- scripts/ 保持仅 setup.py(pack_skill.py 已随旧仓归档,不迁)

修复(迁移暴露的真实缺陷):
- assets/pyproject.toml 的 build-backend 写作 `setuptools.backends._legacy:_Backend`,
  该模块在 setuptools 中不存在 → `pip install -e` 从来装不上。改为 build_meta。
  实测:临时 venv 安装成功,sap-cli --help 正常列出 31 个命令
- pyproject readme 指向不存在的 assets/README.md(editable 安装会失败)→ 改内联文本
- pyproject urls 改指 sap-cli-skill

机制调整:
- .github/workflows/ci.yml 适配 assets/ 布局;顶部注明该工作流仅 GitHub 执行,
  本仓在 Gitee 不会自动跑
- pre-commit 增本地测试门禁(Gitee 上真正生效的那道)
- .gitignore 合并旧仓完整规则(保留 log/ 下 md 知识库入库,只忽略运行日志)
- 大文件上限 100KB→1MB(架构图 512KB)

守卫测试 tests/unit/test_repo_guards.py(10 → 18 例):
- SKILL.md 须记录 parser 全部 CLI 命令 / 铁律 1-5 须为真实小节标题 / 示例不得违反铁律 5
- references/ 规则齐备;.claude/rules 与 references 必须一致(实测抓到一次真实漂移)
- VERSION == sapcli.__version__ == README 版本
- 仓内不得再出现 pack_skill.py / skill-src(防废弃流程回潮)

698 tests OK;editable 安装与 CLI 入口经临时 venv 实测通过。
docs/RELEASING.md 重写为单源开发流程。
2026-09-11 00:40:15 +08:00

11 KiB
Raw Permalink Blame History

title, created, tags, parent, prev
title created tags parent prev
提交与传输 - 原理 2026-05-18
SAP
ADT
transport
CTS
version-management
REST
sap-cli/README sap-cli/04.检查代码-原理

提交与传输 — 原理

[!abstract] 核心概念 SAP 中的 "提交代码" 与 Git 等版本控制系统不同。ABAP 使用 CTS (Change and Transport System) 来管理代码变更。代码修改被记录在 传输请求 (Transport Request) 中,通过传输请求将变更从开发系统 → 测试系统 → 生产系统进行迁移。

1. 传输管理概念模型

传输系统架构

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   开发系统    │     │   测试系统    │     │   生产系统    │
│   (DEV)      │     │   (QAS)      │     │   (PRD)      │
│              │     │              │     │              │
│  创建/修改    │────▶│  测试/验证    │────▶│  部署上线     │
│  代码        │     │  代码        │     │  代码        │
└──────┬───────┘     └──────────────┘     └──────────────┘
       │
       │ 导出
       ▼
┌──────────────┐
│ 传输目录      │
│ (Transport   │
│  Directory)  │
│              │
│ .TR 文件     │
│ 数据文件     │
└──────────────┘
       │
       │ 导入
       ▼
   目标系统 (QAS/PRD)

传输请求结构

传输请求 (Transport Request - TR)
├── 请求头 (Request Header)
│   ├── 编号: K9XXXXXX
│   ├── 类型: K (Workbench) / W (Customizing) / T (Transport of Copies)
│   ├── 描述: "Implement sales order validation"
│   ├── 所有者: DEVELOPER01
│   ├── 状态: D (Modifiable) → R (Released)
│   └── 目标系统: QAS
│
├── 任务 (Task) — 可以有多个
│   ├── 编号: K9XXXXYY
│   ├── 所有者: DEVELOPER01
│   └── 状态: D → R
│
└── 对象列表 (Object List)
    ├── ZCL_SALES_ORDER (CLAS)
    ├── Z_SALES_REPORT (PROG)
    └── Z_SALES_TABLE (TABL)

2. ADT 中的传输工作流

完整流程

1. 创建传输请求
   ↓
2. 将对象分配到传输请求
   ↓
3. 开发/修改代码
   ↓
4. 激活代码
   ↓
5. (可选) 运行 ATC 检查
   ↓
6. 发布传输请求
   ↓
7. 导入到目标系统

3. REST API 详解

3.1 列出传输请求

GET /sap/bc/adt/cts/transportrequests
    ?user={username}
    &status={D|R}
参数 说明
user 按所有者过滤
status D = 可修改, R = 已发布

响应

<cts:transportRequests xmlns:cts="http://www.sap.com/adt/cts">
  <cts:request number="K900001"
               description="Implement sales validation"
               owner="DEVELOPER01"
               status="D"/>
</cts:transportRequests>

3.2 创建传输请求

POST /sap/bc/adt/cts/transportrequests
Content-Type: application/xml

<?xml version="1.0" encoding="utf-8"?>
<cts:request xmlns:cts="http://www.sap.com/adt/cts"
             cts:type="K"
             cts:description="Implement sales validation"
             cts:target="QAS"/>
字段 说明
type="K" Workbench 请求(程序、类等)
type="W" Customizing 请求(配置数据)
type="T" Transport of Copies(复制传输)

3.3 发布传输请求

POST /sap/bc/adt/cts/transportrequests/{request_number}/newreleasejobs

后端处理流程

1. ADT CTS 端点接收发布请求
   ↓
2. 传输系统执行预检查:
   ├── 检查所有任务是否已发布
   ├── 检查所有对象是否已激活
   ├── (可选) 运行 ATC 检查
   └── 检查是否有未释放的对象
   ↓
3. 将传输请求导出到传输目录
   ├── 生成数据文件(包含对象内容)
   └── 生成控制文件(包含元数据)
   ↓
4. 请求状态变为 R (Released)
   ↓
5. 传输管理系统 (tp / STMS) 将请求导入目标系统

3.4 Transport of Copies

[!tip] Transport of Copies Transport of Copies (ToC) 是一种特殊类型的传输,用于在不改变原始传输请求的情况下将代码复制到目标系统。常用于紧急修复或临时部署。

POST /sap/bc/adt/cts/transportrequests/{source_request}/tocopies

4. 对象分配到传输请求

原理

当开发者修改一个对象时,系统会提示选择或创建传输请求。对象随后被记录到传输请求的任务中。

分配方式

┌────────────────────────────────────────────────────┐
│ 方式 1: 自动提示                                    │
│   修改对象时 → Eclipse 弹出对话框 → 选择/创建 TR     │
├────────────────────────────────────────────────────┤
│ 方式 2: 拖拽分配                                    │
│   在 Project Explorer 中拖拽对象到 TR                 │
├────────────────────────────────────────────────────┤
│ 方式 3: 批量分配                                    │
│   选择多个对象 → Assign to Transport Request         │
└────────────────────────────────────────────────────┘

5. 版本管理

ABAP 版本管理机制

ABAP 内置了 版本数据库 (Version Database),每次激活对象时自动创建一个版本。

ADT 中的版本比较

┌────────────────────────────────────────────┐
│ 版本类型                                     │
├────────────────────────────────────────────┤
│ 活跃版本 (Active Version)                     │
│   → 当前系统中正在运行的代码版本               │
│ 非活跃版本 (Inactive Version)                 │
│   → 已保存但未激活的修改版本                   │
│ 传输版本 (Transport Version)                  │
│   → 传输请求中记录的版本                       │
│ 历史版本 (Historical Version)                 │
│   → 版本数据库中保存的所有历史版本             │
└────────────────────────────────────────────┘

比较操作

操作 说明
Compare with Active Version 当前编辑 vs 活跃版本
Compare with Local History 当前 vs 本地历史(客户端缓存)
Compare with Transport Version 当前 vs 传输中的版本
Version History 查看所有历史版本

6. ADT 传输管理 vs SAP GUI 传输管理

功能 SAP GUI ADT Eclipse
创建 TR SE01 / SE09 右键 → New → Transport Request
查看 TR SE01 / SE09 Transport Requests 视图
发布 TR SE01 → Release 右键 → Release
查看 TR 内容 SE01 → Display 双击 TR → 展开对象列表
TR 详情 SE03 Properties 视图
版本比较 SE80 → Version Management 右键 → Compare With
批量操作 SE01 多选 + 上下文菜单

7. 传输发布与 ATC 集成

[!important] 传输发布质量门禁 传输发布时可以配置 ATC 质量门禁,确保代码质量达标后才能发布到目标系统。

配置流程

1. 在 SAP 系统中配置 ATC 传输检查
   (事务码: SATC -> 配置传输发布检查)
   ↓
2. 设置检查规则:
   ├── 设置 Baseline
   ├── 配置检查范围
   └── 设置严重级别阈值
   ↓
3. 传输发布时自动触发 ATC
   ↓
4. 只有通过检查的传输才能继续发布
   (或配置为仅警告不阻止)

8. 通过 REST API 实现自动化传输管理

Python 自动化示例

def automated_transport_workflow(client, object_uri, description):
    """自动化传输工作流"""

    # 1. 创建传输请求
    tr_number = create_transport_request(
        client,
        description=description,
        target_system="QAS"
    )

    # 2. 修改代码(参见 03.修改代码-原理)
    lock_handle = lock_object(client, object_uri)
    # ... 修改源代码 ...
    write_source(client, object_uri, modified_source, lock_handle)
    unlock_object(client, object_uri, lock_handle)

    # 3. 激活代码
    activate_object(client, object_uri)

    # 4. 运行 ATC 检查
    atc_result = run_atc_check(client, object_uri)
    critical = [f for f in atc_result["findings"]
                if f["priority"] == "1"]
    if critical:
        raise Exception("ATC check failed")

    # 5. 发布传输请求
    release_transport(client, tr_number)

    return tr_number

9. 常见问题与解决方案

问题 原因 解决方案
无法创建 TR 缺少 S_CTS_ADMI 权限 联系 BASIS 分配权限
发布失败 对象未激活 先激活所有对象
ATC 阻止发布 存在严重问题 修复 ATC 发现或更新 Baseline
传输导入失败 目标系统缺少依赖 确保依赖对象已在目标系统激活
锁定冲突 其他用户正在编辑 等待或请求解锁

🔗 相关笔记

📚 参考来源