企业官网建设流程全解析

1. 为什么 HANA 把 ABAP 开发者的老手艺全打乱了

先别急着看语法，我先说个场景。干了八年 ABAP，写报表还在用 REPORT + LOOP + AT END OF，自认为性能调优已经炉火纯青。直到有次在 S/4HANA 项目上，客户直接甩来一张两千多万行的财务明细表，让我做个多维汇总分析，我第一版代码跑了一个半小时。那是一段让我印象非常深刻的经历。

问题出在哪？我还在用 ABAP 应用程序层的逻辑去处理数据：把数据 SELECT 上来，塞进内表，再一层一层 LOOP 嵌套做累加。在传统数据库时代，数据量就几百万行，服务器内存没现在大，这种"数据搬到应用层处理"的模式虽然慢，但勉强能跑。到了 HANA 时代，S/4HANA 要求所有核心表都要走列式存储，内存计算是它的看家本领。你要是不把计算逻辑下沉到 HANA 数据库层面，数据从数据库到应用服务器来回搬运，光数据传输开销就能压垮整个项目。

这就要说到标题里的三个关键词了：ABAP on HANA、CDS View、AMDP。这三样东西不是三个孤立的技术点，而是 HANA 时代 ABAP 开发者必须重新理解的一整套技术栈。ABAP on HANA 解决的是 ABAP 程序运行在 HANA 数据库上的兼容性和性能问题；CDS View 解决的是数据建模和访问层的问题；AMDP 解决的是复杂业务逻辑下沉的问题。三者叠加在一起，才是 S/4HANA 开发的新范式。

如果你现在还在用老一套 ABAP 方式写 S/4HANA 项目，接下来的内容建议认真看一下。这篇内容不打算写成官方文档那种面面俱到的说明书，而是按照我自己实际迁移和开发的经验，把三者的关系、分工、踩过的坑和真实可用的代码全部摊开来讲。

2. CDS View：把 SELECT 查询变成数据建模语言

2.1 从 SQL 思维到 CDS 思维的转变

刚开始接触 CDS View 的时候，我的第一反应是：这不就是多了个注解的 SQL 视图吗？这种认知在简单场景下够用，但一旦碰上复杂的业务逻辑，老思维会严重拖后腿。

CDS 全称 Core Data Services，核心数据服务。它不是简单地把 SQL 语句包一层皮，而是一种领域建模语言。传统 SQL 视图解决的是"怎么查"，CDS View 解决的是"这个数据模型长什么样、业务含义是什么、怎么被复用"。

最常见的定义方式是这样的：

@AbapCatalog.sqlViewName: 'ZVW_CUSTOMER' @AbapCatalog.compiler.compareFilter: true @AccessControl.authorizationCheck: #CHECK @EndUserText.label: '客户主数据+销售范围视图' define view zcds_customer_sales as select from kna1 as a inner join knvv as b on b.kunnr = a.kunnr inner join t001 as c on c.bukrs = b.bukrs { a.kunnr as customer_code, a.name1 as customer_name, b.vkorg as sales_org, b.vtweg as distribution_channel, b.spart as division, c.butxt as company_name }

看起来跟普通 SQL 挺像，但实际用起来，你会发现 CDS 有几个核心特性是普通 SQL 视图完全给不了的。

2.2 关联处理：摒弃多层嵌套视图

老 ABAP 开发容易犯的通病是建视图一层套一层：先建一个基础视图，上面再套一个视图，再往上套，套了四五层。在传统 ECC 时代问题不大，但在 HANA 上这会导致查询计划变得异常复杂，运行性能大概率劣化。

CDS 更推荐用Association（关联）来替代嵌套视图。关联的优势在于：它声明的是模型之间的关系，而不是一下子把所有数据全部 JOIN 出来。真正执行查询的时候，HANA 可以按需展开关联，甚至配合_路径表达式按需取数。

@AbapCatalog.sqlViewName: 'ZVW_ORDER_DETAIL' define view zcds_order_detail as select from vbak as a association [1..1] to kna1 as _customer on _customer.kunnr = a.kunnr association [1..*] to vbap as _item on _item.vbeln = a.vbeln { a.vbeln as order_code, a.erdat as order_date, _customer.name1 as customer_name, _item.posnr as item_number, _item.matnr as material_code }

这里要注意association [1..1]和[1..*]前面卡迪纳尔的写法。[1..1]表示一条销售订单必有一个客户主数据，[1..*]表示一条订单可以有多条行项目。声明清楚卡迪纳尔，HANA 优化器才能更好地做预估和优化。

2.3 表函数和 CDS 的配合

CDS View 在 S/4HANA 中不光可以查表，还可以查 AMDP 函数，这就是后面要讲的 AMDP 与 CDS 的结合点。在定义 CDS View 的时候，可以用table function来声明：

define function zcds_get_open_order(im_vkorg varchar(4)) returns table ( vbeln varchar(10), netwr floating point, waerk varchar(5) ) implemented by method zm_cl_amdp_demo=>get_open_order;

这里定义了以订单数量为入参、输出未清订单信息的函数，实现方法放在 AMDP 类里。这也是 S/4HANA 开发里比较经典的配合形态：CDS 建模负责结构定义和消费，AMDP 负责实现数据库层面的运算逻辑。

3. AMDP：把复杂逻辑下沉到 HANA 数据库层

3.1 AMDP 到底是什么

AMDP，全称 ABAP Managed Database Procedures，ABAP 托管的数据库存储过程。在 S/4HANA 的 ABAP 开发环境中，你不再需要像以前那样用 SE38 直接写 Native SQL 调用数据库存储过程（那套操作既繁琐又绕不开各种权限问题）。AMDP 允许你直接在 ABAP 类的方法里写数据库原生的 SQL Script 语句，这些代码会被推送到 HANA 数据库执行，执行完再把结果返回给 ABAP 层。

两个关键特征：

• ABAP 类中的方法：你在 SE24 里建一个类，方法被打上FOR PROCEDURE标记，写 AMDP 方法的实现
• SQL Script 语法：方法内部不是 ABAP 代码，而是 HANA 的 SQL Script，支持变量声明、游标、表类型传递等

3.2 一个完整的 AMDP 例子

这里用一个实际场景：计算每一个客户在指定时间段内的销售额排名，保留前 10 名。

先在类里声明方法：

CLASS zcl_amdp_sales_rank DEFINITION. PUBLIC SECTION. INTERFACES if_amdp_marker_hdb. CLASS-METHODS: get_top_customers IMPORTING VALUE(iv_from) TYPE dats VALUE(iv_to) TYPE dats EXPORTING VALUE(et_result) TYPE ztt_customer_sales. ENDCLASS.

类定义里最核心的一句话就是INTERFACES if_amdp_marker_hdb，这是告诉 ABAP 运行时环境：这个类里的某些方法要作为 AMDP 方法被处理。如果漏了这一句，后面方法实现里的 SQL Script 代码根本不会被编译通过。

方法实现代码：

CLASS zcl_amdp_sales_rank IMPLEMENTATION. METHOD get_top_customers BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY USING zt_sales_data. et_result = SELECT kunnr, netwr FROM zt_sales_data WHERE budat BETWEEN iv_from AND iv_to ORDER BY netwr DESC LIMIT 10; ENDMETHOD. ENDCLASS.

这段代码有几点值得关注：

• BY DATABASE PROCEDURE FOR HDB是 AMDP 方法的标志
• LANGUAGE SQLSCRIPT指定使用 SQL Script 语法
• USING zt_sales_data用于声明方法里会访问哪些数据库表，编译器需要据此做静态检查
• et_result = SELECT ...直接把查询结果赋给导出参数，SQL Script 自带表到表赋值的能力

ABAP 程序调用这个 AMDP 方法的方式和调用普通方法完全一致：

zcl_amdp_sales_rank=>get_top_customers( EXPORTING iv_from = lv_from iv_to = lv_to IMPORTING et_result = lt_result ).

3.3 AMDP 在性能上的优势

同样一个查询，如果这十个客户的统计逻辑在 ABAP 里写，先查所有销售行项目，然后排序，删除非前十名的记录。数据量大之后，应用服务器内存占用会飙升，还有可能撑爆进程。而在 AMDP 中，排名计算全部发生在 HANA 数据库内存中，只用了一张临时表做中间结果，性能差距可以做到几十倍甚至上百倍。

AMDP 适合放的逻辑：大数据量的汇总和分析、复杂的多表 JOIN、用窗口函数 RANK/DENSE_RANK、递归查询等。

我个人的经验是：什么时候优先选 AMDP？当你发现你的 ABAP 代码里出现了"先 SELECT 到内表，再 LOOP 内表，再嵌套 LOOP 内表"这种三层以上循环的时候，就应该想想能不能把这个逻辑直接用 AMDP 下沉到数据库。因为这种循环式数据处理在 HANA 上是最严重的性能杀手。

3.4 AMDP 的调试体验：ABAP 开发者的福音

以前写数据库存储过程，最怕的就是查数据查了半天发现逻辑写错了，但调试工具又难用。AMDP 在 Eclipse 里可以设断点调试，调试器能直接看到 SQL Script 每个步骤生成的中间结果表。这个体验和 ABAP 的调试方式基本一致。

但要注意一个点：AMDP 是在数据库端执行的，运行时和高权限用户相关。在 DEBUG 的时候，它不会像 ABAP 程序一样受 DEBUG 授权控制。换句话说，生产环境里如果一个 AMDP 方法被触发执行，即使 DEBUG 权限没开放，数据库层的运算一样会跑。这在做权限设计的时候要格外注意。

4. CDS 和 AMDP 到底怎么分工：代码推送原则的应用

4.1 核心判断逻辑：逻辑下沉

S/4HANA 开发最重要的原则之一叫做Code Pushdown（代码下沉）：能把计算放到数据库层做的，就不要放到应用服务层做。这个原则具体落下来，就是 CDS View 和 AMDP 的分工问题。

我的判断标准是以业务逻辑的复杂度和数据加工形态来分边界，而不是简单地按"查数用 CDS、算数用 AMDP"这种一刀切。实际开发中，我按下面这个规律来选：

4.2 CDS View 能做的事不必绕道 AMDP

CDS 自带聚合功能。比如要按销售组织统计订单数量、订单总额：

@AbapCatalog.sqlViewName: 'ZVW_ORD_SUM' define view zcds_order_sum as select from vbak as a inner join vbap as b on b.vbeln = a.vbeln { a.vkorg as sales_org, count(*) as order_count, sum( b.netwr ) as total_netwr } group by a.vkorg

这种逻辑在 CDS 里一行就能写明白。如果非要去 AMDP 里搞个临时表再统计一遍，属于画蛇添足。CDS 在简单建模和消费场景下更直观，AMDP 的强项是复杂过程化逻辑。

4.3 AMDP 不适合的场景

AMDP 也不是万能药，有些场景你不要硬塞给它：

• 极高频的简单查询：单表主键查询、按条件过滤少量数据，ABAP 的 Open SQL 在 S/4HANA 上已经是日式直连了，不需要绕道 AMDP
• 需要和 ABAP 用户权限严格绑定的逻辑：CDS 有@AccessControl.authorizationCheck: #CHECK这种细粒度的权限控制（基于 DCL），AMDP 里你如果自己写 SQL Script，权限检查机制跟 CDS 不在同一个体系内，需要额外处理
• 太简单的 IF-ELSE 分支逻辑：你用 AMDP 也没问题，但维护起来并不比 ABAP 代码更直观

4.4 DCL 权限模型：CDS 的独家优势

这里花点篇幅讲一下 DCL（Data Control Language），很多 ABAP 开发在刚迁移到 CDS 时容易漏掉它。

CDS View 的数据权限控制不是在 ABAP 程序里做 authority check，而是在 CDS 后面定义一个配套的 DCL 对象：

@MappingRole: true define role ZCDS_CUSTOMER_SALES { grant select on zcds_customer_sales where ( sales_org ) = aspect pfcg_auth( 'VKORG', 'VKORG' ); }

这段 DCL 的意思是：查询zcds_customer_sales这个视图的时候，系统用当前用户的 PFCG 权限对象 VKORG 来自动过滤销售组织字段。用户在事务码里看不到其他销售组织的数据。

这个模型对 ABAP 开发者来说是既陌生又强大的存在。你一旦习惯了用 CDS + DCL 做权限控制，就不会再想回到 ABAP 里手写AUTHORITY-CHECK。当然，它的复杂度也在那，一个大型项目光权限角色就可能有上百个。

4.5 性能优化：EXPLAIN 计划配合实际执行

CDS 和 AMDP 写完以后，性能验证方法在 HANA 环境里也变了。不只是 SE30/ST05 那套，还要学会看 HANA 的执行计划。

主流做法是在 Eclipse 里选中 CDS View，右键选择Open in Data Preview，然后点执行图标旁边的小箭头，找Execution Plan，可以看到 HANA 优化器生成的执行计划。重点看有没有出现全表扫描、Join 乱序、缺索引提示。

AMDP 方法可以直接在调试器里把中间结果表拿出来分析，也可以用 SQL Console 执行对应的 SQL Script 语句并生成执行计划。一套组合下来，排查性能瓶颈的速度会快很多。

5. 大乱炖实操：一个完整场景同时用到 CDS + AMDP

5.1 场景定义

客户要求做一个销售排行榜界面，展示所有销售组织近一年销售额排名前 100 的客户。数据源包括：销售订单抬头表 VBAK、行项目表 VBAP、客户主数据 KNA1、销售范围 KNVV、公司文本 T001。要求大屏展示，性能要求控制在两秒内返回。

5.2 第一层：AMDP 算排名

这个场景的难点在排名逻辑和性能。如果把数据全捞到 ABAP 层，几十万行订单数据，在应用服务器做排序、分组，两秒肯定扛不住。所以第一步，先用 AMDP 在数据库层把排名算出来。

CLASS zcl_amdp_sales_top100 DEFINITION. PUBLIC SECTION. INTERFACES if_amdp_marker_hdb. CLASS-METHODS: get_top_customers IMPORTING VALUE(iv_vkorg) TYPE vkorg VALUE(iv_year) TYPE dats EXPORTING VALUE(et_result) TYPE ztt_sales_top100. ENDCLASS.

实现：

METHOD GET_TOP_CUSTOMERS BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY USING vbak vbap kna1 t001. lt_ordertable = SELECT a.kunnr, b.netwr FROM vbak AS a INNER JOIN vbap AS b ON b.vbeln = a.vbeln WHERE a.vkorg = iv_vkorg AND a.erdat BETWEEN iv_year AND add_years(iv_year, 1); lt_customersum = SELECT kunnr, SUM(netwr) AS total_netwr FROM :lt_ordertable GROUP BY kunnr ORDER BY total_netwr DESC; et_result = SELECT ROW_NUMBER() OVER(ORDER BY total_netwr DESC) AS rank_code, kunnr, total_netwr FROM :lt_customersum LIMIT 100; ENDMETHOD.

注意add_years(iv_year, 1)这个用法，这是 HANA SQL Script 内置的日期函数，专门用来做年度区间计算。ROW_NUMBER() OVER(ORDER BY ...)是窗口函数的标准写法，如果你在 ABAP 里实现排名，需要层层循环来做，但在 SQL Script 里直接一个窗口函数搞定。

5.3 第二层：CDS View 做消费和权限控制

上面 AMDP 出来的et_result已经是一张排名表了。但大屏界面除了排名和金额，还需要客户名称、公司名称这些描述字段。这部分再塞进 AMDP 里也能做，但更合理的做法是建一个 CDS View 把 AMDP 的结果和基础主数据关联起来，顺便做权限控制。

@AbapCatalog.sqlViewName: 'ZVW_TOP100' @AccessControl.authorizationCheck: #CHECK @EndUserText.label: 'Top100客户销售排名' define view zcds_top100_customers as select from zcds_sales_top100 as a inner join kna1 as c on c.kunnr = a.kunnr { a.rank_code, a.kunnr, c.name1 as customer_name, a.total_netwr }

注意这里的zcds_sales_top100不是一张表，而是一个指向 AMDP 函数的 CDS Table Function。在 Eclipse 里你需要先定义好 Table Function（方式就是前面提到的define function），然后在类里写实现方法。这样建好之后，CDS View 可以直接把 AMDP 的执行结果当作数据源来消费。

5.4 第三层：ABAP 报表展示

最后一步就是 ABAP 层，只需要把 CDS View 的结果取出来展示。

SELECT rank_code, kunnr, customer_name, total_netwr FROM zcds_top100_customers INTO TABLE @DATA(lt_result) UP TO 100 ROWS.

注意：这里用的是 Open SQL 访问 CDS View。如果你在SELECT里直接写 CDS View 的名字，ABAP 编译器会自动解析到后台那个 AMDP Table Function 并推送到 HANA 执行。整个数据流是：ABAP 层只负责简单读取和展示，重计算逻辑全部下沉到数据库层。

这个架构跑下来，总耗时通常在几百毫秒到 1 秒之间。之前那种全部 LOOP 的做法要跑一个多小时，现在缩短到秒级，这种对比才是 ABAP on HANA 真正体现价值的地方。

6. 从热搜词看 ABAP 开发者的真实痛点

标题代入了一堆热搜词，说明现在大家在学习和迁移过程中真正卡住的地方不止是 CDS 和 AMDP 本身，还有一些非常具体的小细节。挑几个高频词分享一些处理经验。

6.1 "abap sort"：排序的坑其实不在 SORT 语句本身

不少人在 S/4HANA 上还在大量使用 SORT + LOOP 的方式做表关联。但实际上，在 HANA 上如果用 Open SQL 直接 JOIN 两次 SELECT，性能往往比"查两张表到内表再用 SORT 合并"快得多。原因在于 SORT 之后的合并操作，还是在应用服务器上进行，涉及数据搬运和额外内存申请。而数据库的 JOIN 是一个标准操作，HANA 针对列式存储做了专门优化。

有个经验数据可以分享：同样两张各 50 万行的表，用 Open SQL INNER JOIN 一条语句，和分两次 SELECT 到内表再 SORT+DELETE ADJACENT DUPLICATES，后者耗时通常是前者的 5 到 10 倍。所以看到热搜词“abap sort”我特意提一句：在 HANA 上排查性能问题时，先想想能不能把 SORT 移进 SQL 语句里让数据库做。

6.2 "abap 检查是否为数值类型"：内置函数比正则靠谱

以前我们写数值类型校验，通常是FIND REGEX或者CHECK一个一个字符去判断，到了 HANA 环境，Open SQL 里有现成的内置函数，可以直接用：

DATA(lv_is_number) = is_number( lv_input ).

这个is_number函数在 Open SQL 里就可以用，比自己去拆字符判断快很多，也稳很多。

6.3 "abap sm30带出描述"：视图维护的增强注意点

SM30 维护表，要在新增行的同时带出描述字段（比如工厂描述、客户名称），有两种常用方式：

• 在数据元素层面设置CONVERSION_EXIT或SEARCH HELP
• 在表维护生成器的事件里定义EVENT GET_DESCRIPTION，用代码自动填充

在 S/4HANA 上，如果表已经建好且数据量不大，我更推荐后者，因为不需要改数据元素，对已有系统的侵入性更小。

6.4 "abap dequeue_all"：锁对象使用前后的讲究

别在服务端随便调用DEQUEUE_ALL。这个函数据说是把当前工作进程的所有锁一次性释放，如果在程序里用，会把其他用户挂在同一个事物的锁也释放掉。正确的做法是用完锁对象之后，在程序里调用对应的DEQUEUE_*函数单个释放，或者直接把CALL FUNCTION ... IN UPDATE TASK之后再让系统在 COMMIT WORK 的时候自动释放。

6.5 "abap 一年前"：日期加减处理

S/4HANA 的 Open SQL 里可以直接用ADD_MONTHS：

SELECT ... WHERE erdat >= add_months( sy-datum, -12 ).

这个写法在 Open SQL 里合法，而且效率比先把日期算成字符串再用常量去拼好得多。千万别再 ABAP 层先算好一个lv_date = sy-datum - 365之后再去 SQL 里比较。一年的天数不一定是 365，闰年、季度末那几天都会有坑。

6.6 "abap 中查看用户登录日期"：别去翻 USR40

查用户最后一次登录日期不要太费劲，直接查USR41表（或者用新版的USR04+UINFO），或者上BAPI_USER_GET_DETAIL：

CALL FUNCTION 'BAPI_USER_GET_DETAIL' EXPORTING username = lv_username IMPORTING last_logon_date = lv_last_logon.

你没看错，BAPI_USER_GET_DETAIL的导出参数里直接就有上一次登录日期，比你翻底层表轻松得多。

6.7 "abap 桌面路径"：CL_ABAP_FILE_SYSTEM

需要拿到用户本地桌面路径的，别硬编码C:\Users\xxx\Desktop。用下面这种方式：

DATA(lv_desktop_path) = cl_abap_file_system=>get_desktop_path( ).

这个方法在不同 Windows 版本、域环境、OneDrive 重定向的情况下都能正确返回用户真正的桌面位置。

7. 迁移到 ABAP on HANA 最容易翻车的三个细节

7.1 表类型和代码的兼容性

S/4HANA 里很多附加表字段改成了大字段（LANG改为LANG+LENGTH变更），原有的CHAR字段被替换成NCHAR的情况也很常见。这会导致问题：

• CONCATENATE拼接字符串时，如果某一项是 NCHAR，长度计算会出偏差
• MOVE-CORRESPONDING的时候，若两边字段类型不匹配，会丢内容

推荐做法是写代码之前检查目标表的技术字段设置，能上 CDS 就用 CDS 直接把字段转换为标准类型，不要到 ABAP 层再 MOVE 来 MOVE 去。

7.2 内表操作的性能衰减

在 HANA 上，把数据放到内表操作的成本反而更高了（因为数据库运算速度太快，应用层成了瓶颈）。所以越是数据量大、计算重的逻辑，越要果断下沉到 CDS 或 AMDP。

有一种例外：交互式 UI 逻辑，用户需要逐行编辑表格，没法下沉，那就老老实实在应用层处理。但后台批处理和报表逻辑，能下沉就下沉。

7.3 ABAP 字典和 HANA 视图的命名冲突

CDS 视图的逻辑名（Define View 后面的名字）不能超过 16 个字符，物理 SQL 视图名（@AbapCatalog.sqlViewName指定的名字）必须在数据库层保持唯一。项目大了以后，名字冲突问题会频繁出现，尤其是多个模块组共用一套 HANA 平台的时候。

我的建议是建立命名规范：

• CDS 逻辑名统一前缀ZCDS_+ 模块 + 对象名
• 物理视图名统一前缀ZVW_+ 模块 + 对象名
• 禁止直接用表名给视图命名

这套规范能帮你省下大量的排查时间。

8. 迁移学习路线

如果你正在从传统 ABAP 往 ABAP on HANA 迁移，我给的建议很明确，分三步走。

第一步：先把 Open SQL 吃透。尤其是 HANA 环境下的新特性，比如JOIN支持更多类型、CASE表达式、CAST、STRING_AGG、LIKE正则等。这些基础打牢了，再去碰 CDS 和 AMDP，会轻松很多。

第二步：用 CDS View 重建传统报表。找几个你手头最常用的报表，把对应的 SELECT 逻辑改成 CDS View，然后用SELECT FROM view替换原来的表读取。感受一下视图复用和数据建模带来的好处。这一步不要一上来就追求多复杂的建模，先跑通一个常规的 JOIN 和聚合场景。

第三步：找一个数据量大的痛点报表改写成 AMDP。我建议先挑一个你写的时候要做三层以上 LOOP 的报表，原样改成 AMDP，测一下性能提升的幅度，同时对比代码可维护性。这一步能帮你真正建立对 Code Pushdown 的直觉。

三层技术的关系总结下来其实就一句话：CDS 管模型，AMDP 管算法，HANA 管运算。三者在实战中不是替代关系，而是分工协作关系。这也正是"大乱炖"这个名字想表达的：不是三样东西堆在一起乱炖，而是把三者的位置和关系炖清楚，才能真正玩转 S/4HANA 开发。

最后再分享一个我自己的习惯：每次写完 CDS 或 AMDP，都会在 Eclipse 里把执行计划打开扫一眼。看到全表扫描或者 Join 顺序异常，第一时间改，而不是等集成测试去发现。这个习惯帮我少加了无数个夜班。