利用 SAP CRM AET 内置 DSL 约束低代码扩展的安全与稳定

在 SAP CRM 项目实践中，Application Enhancement Tool (AET) 是一把威力巨大的低代码利器，业务顾问只需点击几下就能把新字段写入数据库表、BOL/GENIL 模型以及 Web UI 视图。

然而，过度自由 也暗藏风险：错误的数据元素、过长字符字段或不当的授权设置都会威胁性能与安全。

AET 之所以能在大幅降低开发门槛的同时维持稳健运行，核心原因是它在向导背后嵌入了一套领域专用语言 (DSL) — 通过描述性元数据而非任意 ABAP 代码来约束扩展。

本篇文章以 AET 为切入点，拆解这套 DSL 的设计哲学、探讨其如何限制自由度以换取安全，并通过 BAdI IF_EX_AXT_RUNTIME_EVENTS 示例说明怎样在企业规则层面再加一道保险。

AET 与低代码理念

AET 诞生于 CRM 7.0 时代，目标是在不触碰 ABAP Workbench 的前提下让业务用户为标准业务对象快速添加字段、表或视图元素。

它通过浏览器向导收集业务语义信息，自动生成数据元素、透明表、GENIL 模型代码及 Web UI 布局，堪称 SAP 早期低代码思想的代表 。

对比 SAP 官方对 Low-Code/No-Code 的定义 — 让业务专家以最少编程实现应用需求 — AET 完全契合。

元数据驱动的 DSL 结构

• 语法：AET 向导的每一个输入框都对应一个元数据属性，例如 FIELD_NAME、DATA_ELEMENT、LENGTH、GENIL_MODEL 等。开发者实际上在使用一门极简 DSL 来声明需求，而非手写过程式代码。
• 语义检查：DSL 解析器在保存步骤即执行校验，禁止同名字段、限制长度、验证数据元素与域的兼容性等，由此把潜在错误阻挡在生成之前。
• 代码生成：合法的 DSL 脚本被转换为 ABAP 字典对象、BOL/GENIL 类实现与 UI 元数据，全部纳入 CTS (Transport Organizer) 统一运输，确保变更可追溯。

自由过度带来的隐患

业务顾问若能随意创建超长字符串字段或引用敏感数据元素，可能导致：

• 数据库表溢出或性能下降 (如使用 RAWSTRING 存储大附件)。
• 字段缺乏权限对象保护，被未授权用户在 UI 层窃取。
• 运输遗漏导致开发、质量、生产系统配置不一致。

SAP 官方的安全指南指出，CRM 环境下配置对象同样遵从 最小权限原则 和 稳定运输链原则。

DSL 是如何锁住自由的

下表概括了 AET DSL 约束与对应风险的映射：

AET DSL 通过为每个属性提供固定枚举，使得用户不必、也无法输错自由文本，从根源抑制失控。

融合企业安全策略：BAdI 二次校验

在监管严格的行业，组织往往还会要求对 AET 结果再次加锁。例如数据库字段只能来自公司级白名单数据元素或必须附带 ACL 注解。此时可利用运行时 BAdI AXT_RUNTIME_EVENTS 的 CHECK_FIELD_METADATA 方法，在 DSL 解析完毕但代码生成前做最终校验。

下面是一个例子：

************************************************************************
*  ZCL_CRM_AET_VALIDATION
*  限制 AET 新字段仅能使用公司白名单数据元素
************************************************************************
CLASS zcl_crm_aet_validation DEFINITION
  PUBLIC
  CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_ex_axt_runtime_events.
ENDCLASS.

CLASS zcl_crm_aet_validation IMPLEMENTATION.

  METHOD if_ex_axt_runtime_events~check_field_metadata.
    DATA lv_ok TYPE abap_bool VALUE abap_true.

    " 仅允许使用白名单数据元素
    CASE is_metadata-data_element.
      WHEN 'CRMT_EXT_TXT40'
        OR 'CRMT_EXT_NUM5'
        OR 'CRMT_EXT_CURR13'.
        lv_ok = abap_true.
      WHEN OTHERS.
        lv_ok = abap_false.
    ENDCASE.

    IF lv_ok = abap_false.
      RAISE EXCEPTION TYPE cx_axt_validation
        EXPORTING
          textid     = cx_axt_validation=>invalid_metadata
          field_name = is_metadata-fieldname.
    ENDIF.
  ENDMETHOD.

ENDCLASS.

这段代码实现了业务 DSL 与企业安全策略的无缝衔接；若顾问选取了非白名单数据元素，生成流程会立即终止并抛出自定义异常，从而避免不合规字段进入系统。

独立运行方法

1. 在 SE18 激活增强点 AXT_RUNTIME_EVENTS，选择 ZCL_CRM_AET_VALIDATION 作为实现类。
2. 更新表 ZWHITE_LIST 维护白名单数据元素。
3. 在 Web UI 运行 AET 向导尝试创建字段，若未在白名单将收到错误提示。

BOL/GENIL 与 UI 层面的约束传播

AET 生成的字段不止落地在表，还同步扩充 BOL/GENIL 模型 。

GENIL 提供统一服务接口，其属性类型完全由 DSL 决定，因而 UI 组件只能按照声明好的元数据渲染，没有机会插入危险脚本或绕过校验。即便在 Web UI 配置器里拖放字段，系统仍会引用同一份 DSL 元数据，前后端口径保持一致。

真实案例：制造业集团的合规扩展

某全球制造集团在 CRM 里存储关键客户合同条款。早期做法是直接在自建 Z 表存储 VARCHAR2(1024) 字段，导致查询缓慢且难以授权。迁移至 AET 后：

• 顾问通过 DSL 定义 CHAR40 与 NUMC5 字段，严格限定字符数。
• 安全部门借助上文 BAdI 在字段生成前再次验证数据元素是否加密存储。
• 运输层采用 CTS+ 与 TLS 加固，提高跨系统传输安全性。

上线半年内未出现权限泄露或性能回退，且开发脚本量减少 80%。

省流版

通过剖析 AET DSL 的设计与二次校验机制，可以看到：低代码并不等于无约束。恰恰相反，越强大的业务向导越需要在幕后嵌入严密的 DSL规则，把可配置 边界清晰写死，让创新空间与安全底线并存。对于 ABAP 开发者而言，灵活运用 BAdI 接口与白名单思维，就能在 SAP CRM 低代码平台上建立一套可扩、可控、可审计的治理模型。