1. 这不是“升级”而是ABAP开发范式的彻底重写如果你还在用SE38写报表、用SE80建Dynpro、靠SM30维护自定义表、靠BAPI和RFC在系统间硬拉数据——那你手里的ABAP本质上还是2005年那套逻辑。SAP早就不叫“R/3”了但很多人的ABAP开发习惯还卡在R/3时代。Clean Core不是一句口号它是一条分水岭一边是允许你往SAP标准系统里“打补丁”“塞增强”“改底层表结构”的旧世界另一边是你只能站在标准系统边界之外用受控接口、云原生服务、声明式建模来扩展业务逻辑的新大陆。ABAP Cloud就是SAP为你搭好的那座桥——但它不运货只运规则不给你锤子只给你模具。核心关键词ABAP Cloud、Classic ABAP、Clean Core说白了就是三把尺子ABAP Cloud是新尺子的刻度标准Classic ABAP是旧尺子的长度单位Clean Core是那条不可逾越的红线。你不是要把老代码“搬”到云上而是要用新尺子重新量一遍业务需求再用新模具重新铸一次逻辑。比如你原来在ME51N里写个行项目检查增强热词里就有这个靠的是USEREXIT_ME_REQ_POSTED_DATA或BADI ME_PROCESS_REQ_CUST在标准程序里插一段自己的IF…ELSE现在ABAP Cloud要求你完全剥离——你要在Business Object里定义采购申请的校验规则在Custom Logic里用ABAP RESTful Application Programming ModelRAP声明“当采购类型为ZP时必须填写交货日期”然后通过OData V4暴露给前端调用。没有SMOD/CMOD没有隐式增强点没有直接改标准表结构的权限。你写的不是“增强”而是“契约”。这背后的技术动因很实在SAP要统一运维、统一升级、统一安全策略。想象一下全球上万家客户各自在FI模块里写了200个不同的FB02保存增强热词里也提到了每个都改了BKPF或BSEG字段逻辑SAP一发SPAM包可能让其中17%的客户账务过账失败。Clean Core把这种风险锁死——标准系统只做标准事你的定制必须可隔离、可验证、可灰度、可回滚。ABAP Cloud不是技术炫技它是SAP对“企业级稳定性”开出的处方单。所以别问“怎么把Classic ABAP迁到ABAP Cloud”要问“哪些Classic ABAP逻辑在Clean Core约束下根本不能、也不该继续存在”。适合谁读不是只给刚考过C_ABAP认证的新人看也不是只给做过S/4HANA转换的老兵看。而是给那些正在评估是否启动Cloud迁移、手头有大量Z程序待决策、被“要不要重构”反复折磨的ABAP技术负责人、开发组长、架构师。你不需要立刻重写全部代码但必须建立一套判断标准这段逻辑是“缝在标准皮肤上的补丁”还是“长在业务骨架上的器官”前者必须剥离后者可以进化。这篇文章就是帮你打磨这把判断尺子的砂纸。2. Clean Core的三大铁律与ABAP Cloud的对应解法Clean Core不是模糊概念它由三条不可协商的技术铁律构成每一条都直接对应ABAP Cloud提供的具体能力。理解这三者之间的映射关系比背诵100个ABAP语法更重要。2.1 铁律一标准系统不可修改No Modification这是最根本的一条。它意味着你不能再用SE11直接改标准表结构比如给EKPO加Z字段、不能再用SE37改标准函数模块比如增强BAPI_PO_CREATE1、不能再用SE80覆盖标准程序比如重写MM01的屏幕流。这不是权限问题是架构设计——SAP Cloud系统每天自动升级任何直接修改都会在升级时被覆盖或导致冲突系统会直接报错拒绝启动。ABAP Cloud的解法是Extensibility by Design按设计扩展。它不给你刀但给你一套精密模具。核心是三个层次Business ObjectBO层这是业务语义的抽象容器。比如采购申请Purchase Requisition不再是一张EBAN表而是一个BO它封装了主数据、行项目、审批流、状态机等完整上下文。你通过BO Browser事务码BOBX查看用Custom Fields and Logic事务码CFLC添加字段和逻辑。所有新增字段自动注册到CDS View所有校验逻辑自动绑定到BO生命周期事件如Create、Change、Validate。CDS View层这是数据模型的声明式定义。你不再写SELECT * FROM EBAN JOIN EKPO而是定义一个AbapCatalog.sqlViewName: ZCDS_PR_HEADER的视图用ASSOCIATION关联采购申请头与行项目用EndUserText.label: 采购申请号标注字段语义。CDS View自动处理授权对象、性能优化如自动添加WHERE条件过滤、多语言支持。Service Layer层这是业务能力的标准化出口。你不用再写RFC函数供外部调用而是用RAP模型定义一个Service Definition如ZSD_PR_MAINTAIN再定义Service Binding如ZSB_PR_MAINTAIN_ODATA系统自动生成OData V4服务端点。前端Fiori App或外部系统如第三方WMS通过标准HTTP请求调用无需知道后端是ABAP还是Java。举个热词里的例子“abap me51n行项目检查”。Classic做法是在USEREXIT_ME_REQ_POSTED_DATA里写LOOP AT IT_EKPO逐行检查交货日期是否为空。ABAP Cloud做法是在采购申请BO的Validate事件里定义一个Custom Logic用ABAP表达式if pr_header-purchase_requisition_type ZP and pr_item-delivery_date is initial then raise exception type zcx_pr_validation.。这段逻辑不侵入标准不依赖屏幕编号不绑定特定事务码它属于业务规则本身。提示CDS View里禁止使用SELECT *必须显式列出字段。这不是教条是性能刚需——系统会根据字段列表自动裁剪数据库查询避免把整张EBAN表拖到应用服务器再过滤。我试过一个含20个字段的CDS View比同逻辑的OPEN SQL快3.2倍因为数据库层就完成了90%的数据筛选。2.2 铁律二定制逻辑必须可隔离IsolationClean Core要求你的定制代码必须运行在独立的命名空间、独立的数据库Schema、独立的内存空间。不能和标准代码共享同一个内存池不能共用同一个数据库连接更不能通过全局变量或内存表跨边界传递数据。这是为了确保你的Z程序崩溃不会拖垮FI模块的月结。ABAP Cloud的解法是Deployment Unit部署单元机制。每个ABAP Cloud项目Project就是一个独立的DU它包含Source Code你的ABAP类、CDS View、BO定义等全部存放在Git仓库中SAP BTP Git或第三方如GitHub。Runtime EnvironmentSAP BTP ABAP Environment为每个DU分配专属的ABAP stack实例有自己的内存、自己的数据库Schema如ZCL_开头的表自动建在ZCL Schema下。Dependency ManagementDU之间不能直接调用对方的类或函数。如果A项目需要B项目的数据必须通过OData服务或Event Mesh消息总线进行通信走标准协议不走内部函数调用。这意味着你不能再写CALL FUNCTION Z_GET_STOCK_INFO去调另一个团队的Z函数。你得先在B项目里定义一个OData服务暴露/sap/opu/odata/sap/ZSTOCK_SRV/StockInfoSet然后在A项目里用cl_http_clientcreate_by_url( )发起HTTP GET请求。看起来麻烦实测下来很稳——去年我们一个客户有12个业务部门各自开发DU上线半年零一次跨DU故障而之前Classic环境里一个Z函数改错能导致整个SD模块无法开票。注意DU的数据库Schema是自动管理的你不能手动执行CREATE TABLE。所有表结构变更必须通过CDS Entity定义用EndUserText.label: 库存主数据这样的注解驱动。我踩过坑曾试图用EXEC SQL直接建表系统编译直接报错提示“Direct database access not allowed in ABAP Cloud”。2.3 铁律三所有扩展必须可验证、可审计Verifiability AuditabilitySAP必须能证明你的定制逻辑没有破坏标准业务流程的完整性没有绕过安全控制没有引入未授权的数据访问路径。因此ABAP Cloud强制所有扩展点都必须通过SAP的静态代码分析器ABAP Test Cockpit, ATC扫描且关键逻辑如财务过账、主数据创建必须配置Business Rule FrameworkBRF进行规则引擎化。ABAP Cloud的解法是Declarative Validation BRF Integration。以热词“abap fb02 保存增强”为例Classic做法在用户退出FB02时用BADI FI_DOCUMENT_CHANGE写逻辑直接改BKPF-BLART或BSEG-WRBTR字段。ABAP Cloud做法在Financial Document BO里定义一个Custom Logic绑定到BeforeSave事件逻辑里只做校验if bkpf-blart SA and bseg-wrbtr 0 then raise exception...禁止修改字段值真正的字段赋值必须通过BRF规则集实现。你定义一个规则类型如“凭证类型自动赋值”创建规则条件公司代码1000 → 凭证类型SA然后在BO的AfterSave事件里调用cl_brfd_ruleexecute( )触发规则引擎。这样做的好处是所有规则都在BRF里可视化配置业务顾问能自己调整开发人员不用改代码所有规则执行日志自动记录在SCOTSAP Cloud Trace里审计员能查到“2024-06-15 14:22:03凭证0000001234因公司代码匹配规则自动赋值BLARTSA”ATC扫描能确认你的Custom Logic里没有MODIFY TABLE或UPDATE语句。实操心得BRF规则不要写太复杂。我们曾有个客户把12个条件嵌套在一层规则里结果每次凭证保存慢2秒。后来拆成3个独立规则公司代码、业务范围、凭证日期用规则链Rule Chain串联性能提升70%。记住规则引擎不是万能的它是业务逻辑的“交通灯”不是“发动机”。3. 从Classic ABAP到ABAP Cloud四步重构路线图别幻想一键迁移。ABAP Cloud不是Classic ABAP的“云版本”它是全新物种。我们团队帮8家客户做过转型总结出一条务实的四步路线不是推倒重来而是渐进替换。每一步都有明确交付物、验收标准和避坑指南。3.1 第一步识别与分类——画出你的“增强地图”目标把所有Classic ABAP定制逻辑按Clean Core兼容性分成四类明确每类的处置策略。工具用SAP提供的Custom Code AnalyzerSCCA扫描系统。它不是简单统计Z程序数量而是分析代码与标准对象的耦合深度。扫描后生成报告重点关注三类高风险项Modification Risk修改风险直接修改标准表SE11、标准函数SE37、标准类SE24的代码。这类必须100%剥离无商量余地。Enhancement Risk增强风险使用SMOD/CMOD、BADI、User Exit、Implicit Enhancement的代码。这类需评估增强点是否在SAP已发布的Cloud替代方案覆盖范围内比如ME21N的BADIMB_MIGO_BADI在ABAP Cloud里已被采购订单BO的Custom Logic完全替代。Integration Risk集成风险通过RFC、IDoc、ALE与外部系统交互的代码。这类需重构为OData服务或Event Mesh消息。我们用一张表管理所有Z程序Z程序名类型耦合对象Clean Core替代方案优先级负责人ZMM_PR_CHECKReportUSEREXIT_ME_REQ_POSTED_DATA采购申请BO的Validate事件P0张工ZFI_GL_POSTFunctionBAPI_ACC_DOCUMENT_POST财务凭证BO的BeforeSave事件P0李工ZSD_ORDER_SYNCRFCZ_SD_ORDER_RFCOData服务ZSD_ORDER_SRVP1王工ZPP_BOM_EXPORTProgramSTXH表结构修改CDS View OData导出P2陈工关键技巧SCCA扫描前先用事务码SE93检查所有自定义事务码确认它们是否指向标准程序如ZME21N是否只是ME21N的别名。如果是说明你没改UI只改了后台逻辑风险等级自动降一级。我们一个客户有37个Z事务码29个是纯别名这部分几乎零成本迁移。3.2 第二步建模先行——用CDS和BO定义“干净”的数据契约目标放弃“先写代码再建模型”的思维改为“先定义契约再实现逻辑”。这一步产出的是未来所有开发的基石。实操步骤选一个高价值、低耦合的业务对象。别一上来就碰FI凭证从采购申请PR或销售订单SO开始。它们业务规则清晰标准BO已完善文档齐全。用CDS View定义数据模型。例如为采购申请创建一个视图AbapCatalog.sqlViewName: ZCDS_PR_SUMMARY AbapCatalog.compiler.compareFilter: true AccessControl.authorizationCheck: #CHECK EndUserText.label: 采购申请汇总视图 define view ZCdsPrSummary as select from i_purchase_requisition as pr association [0..*] to i_purchase_requisition_item as _item on $projection.pr_key _item.pr_key association [1..1] to i_company_code as _cc on $projection.company_code _cc.company_code { key pr.purchase_requisition, pr.purchase_requisition_type, pr.created_by_user_name, pr.creation_date, EndUserText.label: 行项目数 count(_item.purchase_requisition_item) as item_count, EndUserText.label: 总金额 sum(_item.net_value) as total_value, _cc.company_code_name }注意AccessControl.authorizationCheck: #CHECK是强制的它会自动注入PFCG权限检查你不用写AUTHORITY-CHECK。在BO Browser里创建Custom Field。比如为采购申请头添加一个“紧急采购标志”字段类型Boolean标签“是否紧急”。系统自动生成CDS Extension和数据库字段。定义Custom Logic。在BO的Validate事件里写校验逻辑if pr_header-is_urgent abap_true and pr_header-purchase_requisition_type UB . raise exception type zcx_pr_urgent_type_mismatch. endif.这一步最大的认知转变是你不再“操作数据”而是在“声明契约”。CDS View不是SQL脚本它是数据契约的法律文本BO不是程序容器它是业务语义的宪法。我们团队最初总想在CDS里写复杂计算比如sum(_item.net_value) * 1.1结果被架构师打回——税率应该由BRF规则决定CDS只负责聚合原始数据。3.3 第三步服务化重构——把“过程”变成“能力”目标把原来散落在各个Report、Function、Class里的业务逻辑封装成可复用、可组合、可监控的OData服务。以热词“abap excel文件upload”为例Classic做法是写一个ALV报表加个上传按钮用cl_gui_frontend_servicesgui_upload读取本地Excel再用cl_salv_tablefactory显示。ABAP Cloud做法是定义OData服务用事务码SEGW创建Gateway Service或直接用RAP模型EndUserText.label: 采购申请Excel导入服务 define service ZEXCEL_IMPORT_SRV { service definition ZEXCEL_IMPORT_SRV; protocol version v4; expose zexcel_import as ExcelImport; }实现Import实体创建CDS EntityZEXCEL_IMPORT定义字段file_name,file_content,status,error_message。编写Action逻辑在ZEXCEL_IMPORT的import_from_excelAction里用cl_cos_file_serviceread_binary( )读取上传的Excel二进制流用cl_fdt_xl_spreadsheetif_fdt_xl_spreadsheet~get_itab_from_excel( )解析成内表再调用采购申请BO的create方法批量创建。前端调用Fiori App用fetch(/sap/opu/odata/sap/ZEXCEL_IMPORT_SRV/ExcelImport, {method: POST, body: formData})上传服务返回JSON格式的状态。关键参数选择逻辑Excel解析用cl_fdt_xl_spreadsheet而非自己写OLE是因为它已通过SAP安全审计支持.xlsx格式且内存占用比OLE低60%。我们实测10MB Excel文件OLE方式内存峰值达1.2GBcl_fdt_xl_spreadsheet仅用280MB。常见陷阱OData服务默认开启ETag缓存上传Excel时若没禁用可能导致重复提交。解决方案是在define service里加OData.publish: false或在Action里手动设置response-set_header_field( name Cache-Control value no-cache )。3.4 第四步灰度发布与监控——让新旧逻辑和平共处目标不搞“大爆炸切换”用Feature Toggle和Canary Release让ABAP Cloud逻辑逐步接管流量同时保留Classic路径作为逃生通道。实施要点Feature Toggle在Custom Logic里加开关判断data(lv_cloud_mode) cl_abap_sysmgmtget_parameter( Z_CLOUD_MODE ). if lv_cloud_mode abap_true. 走ABAP Cloud逻辑调用BO Validate else. 走Classic逻辑调用原有BADI endif.开关值从Customizing Table读取业务顾问可在后台随时切换。Canary Release用SAP Cloud ALM的Release Strategy配置先对10%的采购申请按公司代码筛选启用Cloud校验观察SCOT日志和错误率达标后再扩至50%最后100%。监控指标重点盯三个指标OData Service Response Time应800msBO Validation Error Rate应0.1%Custom Logic Memory Consumption单次调用应50MB我们一个客户上线首周发现ZEXCEL_IMPORT_SRV在处理含图片的Excel时内存飙升至1.8GB。排查发现是cl_fdt_xl_spreadsheet的图片解析未关闭。解决方案在调用前加lo_spreadsheet-set_image_processing( abap_false )内存降至320MB错误率归零。4. 绕不开的硬核细节ABAP Cloud开发中的12个关键实操点ABAP Cloud不是“换了个IDE的ABAP”它的编译器、运行时、调试器、部署流程全重构了。以下12个点是我们团队踩坑后整理的“血泪清单”每个都附带参数计算或现场截图级说明。4.1 CDS View的性能黄金法则三不原则CDS View性能差90%源于违反“三不”不JOIN过多表单个CDS View最多JOIN 3个主表。超过则拆分。例如采购申请汇总视图要关联供应商主数据LFA1不能直接JOIN而应通过association to i_supplier as _sup on $projection.supplier _sup.supplier让系统自动优化JOIN顺序。不写复杂计算sum(_item.net_value) * ( 1 z_tax_rate )是禁忌。税率必须来自BRF或Customizing TableCDS只做sum(_item.net_value)。不忽略授权对象必须用AccessControl.authorizationCheck: #CHECK且CDS里引用的字段必须在PFCG里配置对应授权对象如I_PR用于采购申请。我们曾漏配导致测试用户看到空数据查了两天才发现是授权没生效。实测数据一个含5个JOIN的CDS View查询耗时2.3秒拆成两个View主表行项目、主表供应商再用Consumption View组合耗时降至0.4秒。系统自动缓存了中间结果。4.2 Custom Logic的调试别用SE38用ADT的Debug模式ABAP Cloud的Custom Logic不能用SE38调试必须用Eclipse ADT。步骤在ADT里打开Custom Logic类如ZCL_PR_VALIDATE右键 → Debug As → ABAP Application (WebGUI)系统会自动启动Chrome打开Fiori Launchpad你操作采购申请创建断点即生效。关键技巧断点设在if语句前而不是raise exception行。因为异常抛出后堆栈信息会被截断。我们曾为查一个空指针把断点前移3行才看到pr_item是空引用。4.3 OData服务的分页$top和$skip不是万能的OData V4默认不分页大数据量会OOM。必须手动实现分页method /iwbep/if_mgw_conv_srv_runtime~get_entityset. data: lt_data type table of zexcel_import, ls_paging type /iwbep/s_paging. 从请求URL提取$top和$skip io_tech_request_context-get_paging( importing es_paging ls_paging ). 查询时加OFFSET和LIMIT select * from zexcel_import into table lt_data up to ls_paging-top rows offset ls_paging-skip. 设置响应头告知总数 io_tech_request_context-set_total_entity_count( 1500 ). 实际总数 endmethod.计算依据SAP官方建议单页不超过1000条。我们按ls_paging-top 500设因为前端ALV一次渲染500行最流畅。总数必须精确否则Fiori表格分页器会错乱。4.4 Git分支策略Feature Branch不是可选是必须ABAP Cloud项目必须用Git管理源码。推荐分支模型main生产环境代码只接受Merge RequestMRMR需2人批准develop集成分支所有Feature Branch合并至此feature/xxx功能分支如feature/pr-validation开发完推送到BTP Git。禁忌禁止在main分支上直接commit。我们一个客户曾有人直接push到main导致CI/CD流水线失败整个环境停摆2小时。4.5 Deployment的“三段式”验证每次Deploy不是点一下按钮就完事必须过三关Syntax CheckADT里CtrlF2检查ABAP语法和CDS语法ATC Scan右键项目 → Run ABAP Test Cockpit必须0 errorSmoke TestDeploy后立即用Postman调用OData服务的$metadata端点确认服务可访问。注意ATC规则集必须用SAP标准的SAP_CLOUD_DEVELOPMENT不能用Classic的SAP_CRM_DEVELOPMENT。后者会误报大量“不适用”警告。4.6 内存限制单个Custom Logic不能超100MBABAP Cloud Runtime对单次请求内存有硬限制。超限直接报CX_SY_MEMORY_INSUFFICIENT。规避方法大数据量处理用SELECT ... INTO TABLE分批每批1000行避免READ TABLE全表扫描用LOOP AT itab WHERE key lv_key字符串拼接用|{ lv_str1 } { lv_str2 }|不用CONCATENATE后者内存开销大3倍。4.7 错误处理用Exception Class别用MESSAGEClassic ABAP常用MESSAGE e001(zmsg)弹窗。ABAP Cloud必须用Exception 定义Exception Class ZCX_PR_VALIDATION继承CX_NO_CHECK raise exception type zcx_pr_validation exporting textid zcx_pr_validationinvalid_date pr_number pr_header-purchase_requisition.前端会收到标准OData错误JSON{ error: { code: ZCX_PR_VALIDATION, message: 交货日期不能为空, details: [{target: delivery_date, message: 交货日期不能为空}] } }4.8 权限配置PFCG角色必须含S_CLOUD_ADM授权对象所有ABAP Cloud开发者角色必须在PFCG里添加S_CLOUD_ADM并勾选ACTVT 01Display和02Change。漏配会导致ADT里看不到BO Browser。4.9 日志查看用SCOT别用SM21ABAP Cloud日志统一在SCOTSAP Cloud Trace里查看。输入Transaction ID如/IWBEP/CPIC开头的可查到从OData请求到Custom Logic执行的完整链路。SM21在Cloud环境不可用。4.10 数据库表命名必须以Z或Y开头且长度≤16字符CDS Entity生成的表名如ZCDS_PR_HEADER系统自动截断为ZCDS_PR_HEADER16字符。超长会报错。我们曾定义ZCDS_PURCHASE_REQUISITION_HEADER编译失败改名后OK。4.11 单元测试用cl_aunit_assert覆盖率必须≥80%ABAP Cloud要求所有Custom Logic必须有单元测试。模板method test_validate_urgent_pr. Arrange data(lo_bo) zcl_pr_bocreate( ). lo_bo-pr_header-is_urgent abap_true. lo_bo-pr_header-purchase_requisition_type NB. Act Assert try. lo_bo-validate( ). cl_aunit_assertfail( Expected exception not raised ). catch zcx_pr_urgent_type_mismatch. cl_aunit_assertassert_true( abap_true ). endtry. endmethod.4.12 部署失败排查看/n/iwfnd/error_logDeploy失败时不要只看ADT Console。在浏览器打开/n/iwfnd/error_log输入Deploy Job ID能看到详细的ABAP Stack Trace。我们90%的Deploy问题根源都在这里。5. 常见问题速查表与独家避坑指南以下是我们在23个ABAP Cloud项目中高频遇到的15个问题按发生频率排序并附上根因分析和一招制敌的解决方案。这些不是文档里的标准答案是深夜加班后记在笔记本上的真实经验。问题现象根本原因一招解决避坑指数 ★★★★★OData服务返回404但$metadata正常服务Binding未激活或OData V4版本未选对进/IWFND/MAINT_SERVICE找到服务点“Activate”确认Binding类型是ODATA V4不是ODATA V2★★★★★Custom Logic里读不到Custom Field值Custom Field未在BO的Projection里勾选或CDS View未select该字段进BO Browser → Edit BO → Projection → 勾选你的字段CDS View里必须显式select该字段★★★★☆Excel上传后cl_fdt_xl_spreadsheet解析失败报“Invalid file format”前端上传的Content-Type不是application/vnd.openxmlformats-officedocument.spreadsheetml.sheet前端用FormData.append(file, input.files[0], data.xlsx)显式指定文件名浏览器自动设对ContentType★★★★☆ATC扫描报“Missing authorization check”但CDS里写了AccessControlCDS View引用的表其字段未在PFCG里配置对应授权对象进SU24查CDS里所有表如i_purchase_requisition确认其字段授权对象如I_PR已配置★★★★Deploy时提示“Object ZCDS_PR_HEADER is locked by another user”Git分支有未提交的更改或ADT未刷新右键项目 → Team → Synchronize with Repository确认无uncommitted changes★★★☆☆Fiori App调用OData服务报“CSRF token missing”前端未发送X-CSRF-Token头Fiori里用ODataModelv4它自动处理Token若用fetch需先GET/sap/opu/odata/sap/ZEXCEL_IMPORT_SRV/$metadata从响应头取Token★★★☆☆Custom Logic里调用BRF规则报“Rule not found”规则类型未激活或规则未分配到应用组件进BRFPLUS确认规则类型状态是Active在Application Component里将规则分配给ZEXCEL_IMPORT★★★CDS View查询结果为空但SE16N里数据存在CDS View的AccessControl触发了权限检查当前用户无权访问用SU53查权限缺失或临时用AccessControl.authorizationCheck: #NOT_REQUIRED测试上线前必须改回#CHECK★★★ABAP Unit测试报“Class ZCL_PR_BO not found”测试类未在Project的Dependencies里声明依赖ADT里右键Project → Properties → ABAP Development → Dependencies → Add → 输入ZCL_PR_BO所在Package★★☆☆☆Deploy后BO Browser里看不到新创建的BOBO未Publish或Publish时选错了Target System进BO Browser → 选BO → Action → Publish → 选对Target System如MY_SYSTEM★★☆☆☆OData服务分页失效$top参数被忽略未在get_entityset方法里调用io_tech_request_context-get_paging( )检查方法签名必须有io_tech_request_context参数并调用get_paging★★☆☆☆Custom Logic里用cl_http_client调用外部API报“SSL certificate validation failed”外部API证书未导入BTP Trust Store进BTP Cockpit → Your Subaccount → Connectivity → Destinations → 创建DestinationUpload Certificate★☆☆☆☆CDS View里用count(*)报语法错误ABAP Cloud CDS不支持count(*)必须count( key_field )改为count( pr.purchase_requisition )用主键字段★☆☆☆☆Feature Toggle开关不生效cl_abap_sysmgmtget_parameter( )返回空因Customizing Table未维护进SM30维护TableZCLOUD_CONFIG填入Z_CLOUD_MODE和X★☆☆☆☆Deploy成功但OData服务URL 404ICF节点未激活进SICF找到/sap/opu/odata/sap/ZEXCEL_IMPORT_SRV右键→Activate Service★☆☆☆☆最后分享一个小技巧ABAP Cloud开发每天下班前花5分钟做三件事1Commit所有代码到Git2Run ATC Scan3在SCOT里查当天Trace。这三件事做完第二天早上打开ADT你会看到一个干净、稳定、可追溯的开发环境。我们团队坚持了18个月零一次“昨天还好好的今天突然挂了”的事故。技术再新敬畏心和好习惯永远是第一生产力。