共计 1626 个字符,预计需要花费 5 分钟才能阅读完成。
背景痛点
在 SAP 标准系统中,客户主数据(如 KNA1 表)提供了基础字段,但在实际业务中常遇到这些限制:

- 缺少行业特定字段(如医药行业需要的 GSP 资质编号)
- 无法满足本地化校验规则(如中国税号必须 18 位)
- 特殊业务逻辑缺失(如黑名单客户自动拦截)
这些需求迫使我们必须扩展标准功能。直接修改 SAP 标准表是绝对禁止的,因此需要采用安全的增强技术。
技术方案对比
1. APPEND 结构增强
通过在标准表末尾追加自定义字段(Z 开头),适合简单的字段扩展:
APPEND STRUCTURE ZKNA1_ENH TO KNA1. " 事务码 SE11
优点 :
– 开发简单,字段可直接在标准事务码中使用
– 支持搜索帮助和字段级校验
局限 :
– 可能影响标准表的性能(字段越多,SQL 查询效率越低)
– 升级时需重新应用 APPEND
2. BAdI 增强(业务插件)
通过实现 MDG_BS_UI_BADI 等标准接口,可在保存前插入校验逻辑:
METHOD if_ex_mdg_bs_ui_badi~check_before_save.
IF is_data-kna1-stcd1 IS INITIAL.
RAISE EXCEPTION TYPE cx_mdg_bs_exception.
ENDIF.
ENDMETHOD.
优势 :
– 不修改表结构即可实现复杂业务规则
– 支持多出口调用(多个增强互不影响)
3. 隐式增强
在标准屏幕、菜单或程序预留的增强点(Enhancement Spot)插入代码:
- 事务码 SE80 找到程序 SAPMF02D
- 右键选择【增强实施】→【隐式增强点】
- 在保存逻辑的增强点插入校验代码
适用场景 :
– 需要修改标准界面布局时
– 添加自定义子屏幕(Subscreen)
核心实现步骤
通过 CMOD 创建增强项目
- 事务码 CMOD 创建项目 Z_CUSTOMER_ENH
- 分配增强包(如 VOFM0001)
- 激活项目并生成传输请求
BAdI 增强示例代码
CLASS zcl_badi_customer_check DEFINITION.
PUBLIC SECTION.
INTERFACES if_ex_mdg_bs_ui_badi.
ENDCLASS.
CLASS zcl_badi_customer_check IMPLEMENTATION.
METHOD if_ex_mdg_bs_ui_badi~check_before_save.
" 黑名单检查
SELECT SINGLE @abap_true
FROM zcustomer_blacklist
WHERE kunnr = @is_data-kna1-kunnr
INTO @DATA(lv_blocked).
IF lv_blocked = abap_true.
" 记录错误日志
MESSAGE e888 WITH '客户被列入黑名单'.
ENDIF.
ENDMETHOD.
ENDCLASS.
关键点 :
– 使用 SELECT SINGLE 而非全表扫描(性能考量)
– 错误消息编号从 888 开始(避免冲突)
生产环境考量
传输请求管理
- 为所有增强创建独立传输请求(避免与其他开发混杂)
- 在请求描述中注明增强点编号
补丁升级影响
- APPEND 结构需在升级后重新激活
- 使用 RS_AFTER_IMP_CHECK 检查增强兼容性
错误追踪
在 ST22 中过滤:
– 程序名包含 SAPMF02D
– 错误类型为 MDG_BS_*
避坑指南
替代直接修改标准表的方案
- 使用自定义表并通过外键关联(如 ZKNA1_EXT)
- 配置表字段(事务码 OMSR)
- 使用客户出口(Customer Exit)
多客户端处理
IF sy-mandt <> '100' AND is_data-kna1-kunnr LIKE 'Z%'.
" 只在 100 客户端允许测试客户
ENDIF.
性能测试指标
- 使用 ST05 跟踪 VD01 事务的 SQL 耗时
- 确保增强代码执行时间 <100ms
总结思考
三种增强方式各有千秋:APPEND 适合简单扩展字段,BAdI 处理复杂逻辑,隐式增强控制界面元素。当需要跨模块同步增强字段时,你会选择 RFC 还是直接 DB 访问?为什么?
(提示:RFC 更安全但速度慢,直接 DB 访问需考虑锁机制)
正文完
