★ FEATURED ARTICLE 简介这份Word文档面向SAP ABAP/HANA开发初学者以及需要在Eclipse中搭建CDS视图环境的开发人员围绕CDS视图的建模价值与完整创建流程展开帮助读者理解声明式数据模型如何改善多表关联查询性能并完成从环境准备到视图落地的实践。文档为单个doc文件压缩包约1.21MB篇幅集中、查阅方便适合作为日常开发中的操作参考。目前已有331人学习。读者可从中了解Eclipse与SAP客户端版本匹配、SAP ABAP Development Tools插件获取与安装、安装卡顿处理、SAP项目关联以及在指定包下新建CDS视图等关键环节文档还整理了安装后常见报错的排查方向包括Microsoft Visual C 2013运行库缺失、sapjco3.dll版本过低等问题的处理思路。创建部分覆盖界面配置与编辑SQL两种方式并给出请求号、视图名称、DDL名称等示例便于读者结合CDS语法理解数据模型结构提升开发与排错效率。1. 一份标题带 .doc 的安装文档卡住人的从来不是语法交接过来的环境文档经常长这样标题写着 SAP-CDSView-Eclipse 安装及创建步骤正文四屏截图装插件、连系统、建对象、激活。照着点前三步大概率能过第四步激活报错。这套东西的门槛不在 CDS 语法而在环境组合Eclipse 的大版本、ADT 插件的版本、后端 ABAP 的 Release、以及你面对的是传统 ECC 还是 S/4四者共同决定了你能用define view还是define view entity、能写哪些注解、能不能上 DCL。这篇把这条链从上到下拆一遍装什么、按什么顺序装、创建时每个字段为什么这么填、注解与 association 怎么用、以及那些只在报错视图里出现的坑。适合已会写 ABAP、但第一次在 Eclipse 里做数据模型的开发者也适合从 SE11 维护视图迁过来的人。2. 装 ADT 之前先对齐三件事Eclipse 版本、插件来源、后端 Release很多人一上来就打开 Marketplace 搜插件装完发现连不上系统或者连上了却建不出 Data Definition。安装动作本身只有几分钟真正的判断发生在动手之前。这一章讲的是选型你手上的后端是什么年代的东西配哪个 Eclipse插件从哪来连接参数怎么填才不返工。2.1 用后端 Release 反推 Eclipse 与语法范围ADTABAP Development Tools是 Eclipse 的插件但它对 Eclipse 宿主版本有硬性要求对后端 ABAP Release 也有硬性要求。顺序应该是先确认后端 Release再选 Eclipse最后选 ADT 版本。反过来做最常见的结果是插件装上了、项目连上了新建向导里却没有 Data Definition 这一项——因为后端 Release 太老或者 ADT 版本高于后端能接受的上限。判断后端能力我一般不会去翻兼容矩阵文档而是直接在系统里看两个东西一是系统 → 状态里的组件版本确认 ABAP 平台的 Release二是用 SE11 随便打开一个以Z开头的数据库视图看它是不是由某个 CDS 视图生成的。如果系统里已经有AbapCatalog.sqlViewName生成的视图对象说明这套环境至少支持基础 CDS。后端形态能用的 CDS 能力对 ADT 的要求常见误判传统 ECC 较老 Release基础define view注解支持有限DCL 能力弱用与 Release 匹配的旧版 ADT不要追新装了新版 ADT向导里没有 CDS 分类S/4HANA 早期define view、常用AbapCatalog/VDM注解、DCL中等版本 ADT 即可误以为能直接用 view entityS/4HANA 较新define view entity、层级、RAP 相关注解、完整 DCL需要较新的 ADT用老 ADT 打开新对象语法报红这里没有具体版本号可抄因为每个环境打过的补丁不一样。可靠的判断方式是在 Eclipse 里装完插件后新建向导里出现的模板列表就是后端插件组合的真实能力边界。模板里只有Define View没有Define View Entity就别硬写define view entity会一路报语法错。2.2 在线装与离线装两条路径的取舍插件来源只有两种在线装和离线装。在线装的路径是 Eclipse 菜单里的Help → Eclipse Marketplace搜 ABAP 关键字找到 ADT 条目安装装完重启并切换透视图到 ABAP。这条路适合本机能访问外部更新站点、且 Eclipse 版本较新的情况。内网环境往往没有外部出口这时走离线先从能下载的机器上取到 ADT 的归档包然后在Help → Install New Software → Add → Archive里指向本地归档文件。离线包的优点是版本可控缺点是你必须自己保证它和 Eclipse 大版本匹配装错会直接提示依赖不满足。几个实操上的注意点不要装在已经装了一堆无关插件的 Eclipse 上。ADT 对 Eclipse 的依赖树比较挑插件冲突导致启动报错的情况我见过不止一次。干净的解压版 Eclipse 是最省事的起点。安装过程中 Eclipse 会提示重启重启后第一次打开 ABAP 透视图可能白屏几秒属于正常初始化别急着强杀。装完先别建对象先确认Window → Perspective → Open Perspective → Other里有 ABAP 选项。没有这个透视图说明插件没真正装成功后面所有步骤都白搭。企业内网如果提供了内部镜像站点优先用镜像版本和 Eclipse 的匹配关系通常由维护方统一过省去自己试错。2.3 建 ABAP 项目连接参数里最容易填错的四个字段插件装好后File → New → ABAP Project开始建连接。如果本机已经装了图形客户端并配置过系统条目可以直接从列表里选没有的话就手填。手填的参数表如下这几个字段是返工率最高的字段含义填错的后果System ID三位系统标识与实际系统不符时连接被拒报未知系统Instance Number两位实例号少写前导零如把 01 写成 1会导致端口推导错误Client三位集团号同样有前导零问题且决定你看到的是哪个集团的数据Message Server / Application Server消息服务器或应用服务器主机集群环境填应用服务器可能导致登录被路由到非预期节点认证方式上用户名密码最直接如果环境启用了单点登录需要额外的加密库配置这一步在离线环境里经常缺文件缺了会报握手失败而不是密码错误报错信息很有迷惑性。连接建好后有一个动作容易被跳过在项目上右键确认Properties → ABAP Development → Backend里显示的 Release 与你在系统里看到的一致。不一致说明你连错了系统后面建的对象全落到了测试机上。这类事故属于典型的一失足成千古恨建对象前扫一眼成本极低。3. 创建 CDS View 的完整链路从建包到激活预览向导点下去只要十几秒但每个输入框背后的含义决定了这个对象以后好不好维护。这一章按真实操作顺序走一遍先解决包和传输请求再用向导生成骨架最后激活并看到数据。三步里任何一步偷懒后面都要返工。3.1 包、传输请求与开发权限的前置检查建对象之前先确认三件事你有没有目标包的开发权限、这个包是不是本地对象包$TMP、以及传输请求由谁负责。$TMP包的优点是改完即生效、不进传输、适合做验证缺点是对象出了这个系统就没了也没法交给别人。团队协作的正式模型必须挂在可传输的包上。我一般的做法是第一个练手视图放$TMP把语法、注解、预览全跑通确认逻辑没问题后再在正式包里重建一份带走。传输请求的坑在于“建的时候没挂想挂的时候挂不上”。对象一旦以本地对象形式激活后续要转成可传输对象需要走“把对象重新分配到传输包”的流程中间可能因为依赖对象比如 DCL、关联的目标视图没一起走而失败。所以更省事的路径是建对象时就在向导里指定传输请求一次性把请求建好。权限方面除了包本身的开发权限还要有S_DEVELOP里对应对象类型的授权。权限不足的表现往往不是明确的“无权限”而是向导走到一半按钮变灰或者激活时提示对象被锁定。遇到这种先找 BASIS 确认授权不要在 Eclipse 里反复重试。3.2 用向导生成第一个 CDS View每个字段填什么路径是在项目里展开到目标包右键New → Other → ABAP Repository → Core Data Services → Data Definition。向导里的字段不多但有一项选错就得重来向导字段填什么说明Package目标开发包决定传输请求与权限别随手选$TMP做正式对象NameZ或Y开头的对象名长度受限制命名建议带业务域前缀如ZCDS_SO_ITEMDescription业务语义描述会随对象进传输不要写“测试1”这类无意义内容TemplateDefine View或Define View Entity选错等于语法体系选错老后端只有前者Transport Request已有请求或新建与 Package 联动选$TMP时该项不可用选Define View后编辑器会生成一个骨架。下面是一个可以直接改字段名跑起来的最小例子基于销售订单抬头与行项目的关联查询AbapCatalog.sqlViewName: ZCDS_SOITEM01 // 生成的数据库视图名老语法必填全局唯一 AbapCatalog.compiler.compareFilter: true // 编译期比较过滤条件通常保持 true AbapCatalog.preserveKey: true // 保留 key 定义影响后续关联的语义 AccessControl.authorizationCheck: #NOT_REQUIRED // 暂不做权限检查正式对象应改为 #CHECK EndUserText.label: 销售订单行项目明细 // 业务描述会出现在查询工具里 Metadata.ignorePropagatedAnnotations: true define view ZCDS_SO_ITEM as select from vbak as h inner join vbap as i on i.vbeln h.vbeln { key h.vbeln as SalesOrder, // 抬头订单号 h.audat as DocumentDate, // 抬头单据日期 h.kunnr as SoldToParty, // 抬头售达方 key i.posnr as ItemNumber, // 行项目行号与订单号组成联合主键 i.matnr as Material, // 行项目物料 i.kwmeng as Quantity, // 行项目数量 i.netwr as NetValue, // 行项目净值 i.waerk as Currency // 行项目币种 } where h.vbtyp C // 只取销售订单类单据这段代码里有几个点值得单独说明。AbapCatalog.sqlViewName在老语法里是必填项长度受限且全库唯一激活后会在数据库层生成一个同名视图对象所以命名要避开已有对象。两个key分别来自两张表合起来构成这个视图的主键——preserveKey: true的意义就在这里它保证后续被别的视图关联时主键语义不会丢。inner join的写法决定了结果集边界如果某些订单只有抬头没有行项目这些订单不会出现在结果里。需要保留抬头时改成left outer join但要注意此时行项目字段可能为空下游做聚合时要处理空值。如果后端支持define view entity同样的逻辑可以写成不带sqlViewName的形式主键用key显式声明在字段列表里语义更清晰也不占用数据库视图命名空间AccessControl.authorizationCheck: #CHECK EndUserText.label: 销售订单行项目明细 define view entity ZCDS_SO_ITEM_E as select from vbak as h inner join vbap as i on i.vbeln h.vbeln { key h.vbeln as SalesOrder, key i.posnr as ItemNumber, h.audat as DocumentDate, h.kunnr as SoldToParty, i.matnr as Material, i.kwmeng as Quantity, i.netwr as NetValue } where h.vbtyp C两者最实际的差别是define view多一层数据库视图某些分析场景下过滤条件下推的行为不同define view entity只在 ABAP 层存在配合权限控制和 RAP 使用时更灵活。团队里混用两种写法会增加维护成本最好在项目初期统一。3.3 激活、查错与 Data Preview 的正确打开方式写完源码后激活快捷键是CtrlF3。激活不是简单地“保存”它会触发一整套检查语法、注解合法性、依赖对象是否存在、数据库视图能否创建。失败时不要只看弹窗里那行摘要切到Problems视图看完整条目错误定位通常精确到行。常见的激活结果分三类一类是语法错误比如注解拼错、字段名不存在这类问题报错信息最明确一类是依赖错误比如关联的目标视图还没激活这类需要先把被依赖的对象激活还有一类是对象冲突比如sqlViewName已被占用报错信息里会直接给你冲突对象的名字按名字去 SE11 查即可。激活成功后右键编辑器里的对象名走Open With → Data Preview或者直接在项目树里右键对象选数据预览。预览页面上方可以加过滤条件下方显示结果行数。这一步是验证逻辑最快的方式——比写一个报表程序去查快得多。预览时注意两点一是行数限制默认只取前若干行验证数据量大的场景要手动改上限否则你会误以为数据缺失二是客户端字段如果视图没有显式处理客户端预览结果会受当前登录集团影响跨集团对比数据时容易看花眼。4. 注解和 association 才是 CDS 的核心从 AbapCatalog 到关联路径能把视图建出来只是及格线。CDS 真正区别于普通数据库视图的地方是它能携带语义这个视图是什么类型、给谁用、权限怎么控、和别的实体怎么关联。这些信息全部由注解和 association 承载。这一章把最常打交道的几组讲清楚。4.1 绕不开的六个注解与参数取值注解写错不会报“注解错误”而是表现为视图行为不符合预期排查起来比较绕。下面这几个是建视图时几乎一定会用到的注解常用取值作用与影响AbapCatalog.sqlViewName不超过长度上限的大写名仅define view需要决定数据库视图名全局唯一AbapCatalog.preserveKeytrue/false保留 key 语义被关联时不丢失主键信息AbapCatalog.compiler.compareFilter通常true编译期比较过滤条件影响条件下推行为AccessControl.authorizationCheck#NOT_REQUIRED/#CHECK/#MANDATORY决定是否强制执行 DCL正式对象不要留#NOT_REQUIREDEndUserText.label业务描述文本显示在查询工具与分析前端缺失时显示技术名VDM.viewType#BASIC/#COMPOSITE/#CONSUMPTION标识视图在分层架构中的位置影响复用规范选型上的建议是AccessControl.authorizationCheck从一开始就写#CHECK哪怕 DCL 还没建。原因很实际——写成#NOT_REQUIRED时视图能正常激活、能预览、看起来一切正常等上线前补权限才发现一批下游对象都要跟着改。早期就设成#CHECK激活会因为缺 DCL 而失败这个失败是好事它逼你当场把权限模型想清楚。VDM.viewType决定了这个视图该被谁引用。基础层视图直接读物理表只做字段重命名和简单过滤组合层引用基础层做关联和聚合消费层给具体应用用可能带参数。三层混着写最后会得到一堆互相引用、改一处崩一片的对象。项目里我一般要求基础层视图不允许出现join需要关联就在组合层做。4.2 association 与 path expression把关联写进模型里用join是把两张表在当前视图里拼死用association是把关系声明出来、按需展开。前者简单直接后者在复用和性能上更有余地。声明方式如下define view ZCDS_SO_HEADER as select from vbak as h association [1..*] to ZCDS_SO_ITEM as _Item on _Item.SalesOrder h.vbeln { key h.vbeln as SalesOrder, h.audat as DocumentDate, h.kunnr as SoldToParty, _Item // 暴露关联下游可继续展开 }[1..*]是基数声明表示一条抬头对应多条行项目。基数不是装饰它会影响编译器的优化判断写错基数在数据量大时性能差异明显。on后面的条件只写关联键不要塞业务过滤条件——业务条件放where混在on里会让关联结果集超出预期这是新手最常翻的车之一。消费方要用关联里的字段走 path expression_Item.Material、_Item[1].NetValue。方括号里是索引用来在“一对多”里取特定一条配合order by才可控。没有排序就取第一条结果是不确定的业务上别这么写。什么时候用 association、什么时候用 join我的判断标准是需要把这张表作为可复用实体暴露出去用 association只是一次性算个结果用 join 更直接。两者的结果集在inner场景下等价但在left outer场景下association 的默认行为可能与预期不符这时要显式指定关联类型。4.3 权限、Client 与 DCL 的衔接视图写了#CHECK之后必须有对应的 DCL 才能激活。DCL 是一个独立的仓库对象写法如下EndUserText.label: 销售订单行项目权限控制 MappingRole: true define role ZCDS_SO_ITEM_DCL { grant select on ZCDS_SO_ITEM where ( SoldToParty ) aspect pfcg_auth( V_VBAK_VKO, KUNNR, ACTVT 03 ); }这段的意思是谁能看到哪个售达方的数据由权限对象V_VBAK_VKO里的KUNNR值决定ACTVT 03表示查询动作。MappingRole: true让这个角色自动匹配到同名视图上不用额外配置映射。几个容易出错的地方where里引用的字段必须是在视图字段列表里显式暴露出来的用别名而非原始字段名pfcg_auth里的权限对象和字段必须是后端真实存在的写错不会报错只会静默地让所有人看不到数据——这种黑匣子式的故障最难排查排查时先确认权限对象在 SU21 里存在。Client 处理是另一个维度。CDS 视图默认继承物理表的客户端依赖属性跨客户端场景要在注解里显式声明客户端处理算法。多数业务视图不需要动这个但做跨集团对比或系统级统计时客户端字段会直接影响结果集这一点在预览时表现为“数据比预期少”而不是报错。5. 避坑与排查激活失败、预览空白、传输丢对象的五条实战记录这一章全是踩过的坑。写进来的都是出现过不止一次、且第一次遇到时很难靠报错信息直接定位的问题。每条按“现象、原因、解决”走一遍。5.1 激活报“对象不存在”但对象明明在项目树里现象新建的视图引用了一个已有的 CDS 视图激活时提示被引用对象不存在或未激活项目树里那个对象看起来是正常的。原因项目树显示的是本地缓存状态被引用对象在服务器上确实存在但当前会话的缓存没同步另一种情况是被引用对象存在较新的未激活版本服务器上处于“有草稿”的状态。解决先对被引用对象执行一次激活强制刷新如果仍然报错右键项目选刷新或者断开重连系统连接。团队协作里更常见的是别人正在改同一个对象这时激活会互相覆盖开工前先在对象上确认有没有其他人的未激活版本。5.2 Data Preview 一直转圈或者返回空结果现象视图激活成功预览却超时或显示零行加过滤条件也没用。原因有三类一是视图逻辑本身过滤掉了全部数据比如where条件里的单据类型在当前集团没有数据二是客户端依赖导致当前集团无数据三是底层表数据量太大预览默认取数超时。解决先把where条件临时注释掉再预览确认是逻辑问题还是数据问题再检查底层表本身有没有数据用 SE16 直接看如果是数据量大加上主键范围过滤别用无条件的全表预览。预览超时这件事很玄学同一张视图在上午能开、下午打不开多半是后端负载问题换个时间点再试比反复改代码有用。5.3 传输请求里看不到刚建的 CDS 视图现象对象建好、激活成功去传输请求里找却找不到。原因建对象时包选了$TMP本地对象不进传输或者建的时候没指定请求系统默认放进了本地对象。解决确认对象所属的包。如果确实是$TMP需要走重新分配的流程把对象连同它的依赖DCL、被引用的下层视图一起挪到可传输的包。这类返工最麻烦的地方在于依赖关系只挪主视图不挪 DCL到目标系统激活会失败。5.4 改了字段别名预览结果还是旧结构现象字段名改了、激活也成功了数据预览的表头还是老的。原因预览页面缓存了上一次的元数据没有随对象激活刷新。解决关闭预览页重新打开如果还是旧的把编辑器标签也关掉重开。数据库视图层面还有一层define view生成的数据库视图在激活时重建如果重建失败但主对象激活成功就会出现“ABAP 层是新结构、数据库层是旧结构”的错位这时去 SE11 看那个sqlViewName对应的视图是否存在且字段正确。5.5 加了 association结果集反而变大现象原本用 join 得到的行数是正常的改成 association 展开后行数翻倍。原因基数声明与实际数据关系不一致或者on条件里漏了关联键的一部分导致多对多匹配。解决先核对on条件是否覆盖了完整的关联键。以订单抬头和行项目为例只写vbeln是对的但如果关联的是两张都有vbeln posnr的表只写vbeln就会笛卡尔式膨胀。基数和on条件要一起检查光改基数不解决问题。提示遇到激活类问题先看Problems视图的完整报错再看被依赖对象的状态。多数“莫名其妙”的失败都能归到这两处。6. 把 CDS View 用成接口层三个能省掉重复开发的技巧视图能跑通之后真正的价值在于“被别人用”。这里说三个实操中收益最明显的做法。第一个是参数化。把常用的过滤维度做成视图参数消费方传参即可不用每个下游都抄一遍wheredefine view ZCDS_SO_ITEM_P with parameters p_bukrs : bukrs, // 公司代码 p_date : audat // 起始单据日期 as select from ZCDS_SO_ITEM { key SalesOrder, key ItemNumber, DocumentDate, SoldToParty, Material, NetValue } where DocumentDate :p_date参数要选那种“几乎每个消费方都会过滤”的维度公司代码、日期区间、单据类型这三类最典型。参数太多会走向另一个极端消费方记不住参数名最后还是自己写 where。第二个是用VDM.viewType强制分层。基础层只做字段重命名和类型转换组合层做关联和聚合消费层面向具体场景。这个约束听起来是规范问题实际是性能问题基础层视图会被大量对象引用它里面每多一个 join所有下游都要承担这个成本。我在一个项目里见过基础层视图里套了七层 join改一个字段要重新评估十几处影响。层级VDM.viewType允许的操作禁止的操作基础层#BASIC字段重命名、类型转换、简单过滤join、聚合、参数组合层#COMPOSITEassociation、聚合、参数直接读物理表消费层#CONSUMPTION面向具体应用的字段裁剪被其他视图复用第三个是验证方式。视图写完之后别只看预览的前几行就交付。有条件的话用 SQL 跟踪工具看一下实际下推到数据库的语句确认过滤条件真的下去了而不是把全表拉到 ABAP 层再过滤。视图写法和最终执行的 SQL 之间隔着一层编译优化这层优化是黑匣子唯一能确认的手段就是看实际执行的东西。另外改动已有视图前先确认下游引用清单右键对象查引用位置比事后靠报错回溯省事得多。说个自己的教训早期我习惯把所有逻辑塞进一个视图觉得省事结果一个字段类型改动导致下游四个对象全部激活失败排查花了大半天。后来强制自己按层拆虽然对象数量多了但每次改动的影响面都是可见的。这件事没有捷径只能靠一开始就把结构定对。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
