去年SAP正式宣布启动 S/4HANA Cloud, public edition三系统架构。三系统提供了开发可扩展性，允许开发者在SAP S/4HANA Cloud上创建开发项目，利用自定义 ABAP 代码的优势实现开发扩展。从分析的角度来看，三系统架构下报表开发会比两系统开发有哪些优势，可以解决哪些二系统开发报表时的限制点？本篇博文将会通过一个客户用例，探索两种系统架构下报表开发的差异。
客户用例介绍：
该客户是一家集研发、制造和销售一体的高科技企业。在日常生产过程中，业务人员希望能在系统内查看到生产物料的在库时间，即“库龄”。与其他传统库龄报表不同，该客户更注重批次管理，需要溯源到该批次物料的最早入库时间，不考虑移库，从而计算批次的在库时间。
客户的所需大致表样如下：
二系统架构：
二系统架构内提供了关键用户开发可扩展性。使用可扩展性应用，关键用户可以创建细分的数据库表并设计查询。
根据分析，报表所需要的数据源均已发布且可以用于关键用户扩展：I_MaterialDocumentItem_2，I_MaterialStock_2。I_MaterialDocumentItem_2主要用来获取物料入库时间，从而计算库龄。I_MaterialStock_2可以获取到指定时间的物料库存数量。通过关联两个数据源即可获得用户所需的报表，但使用关键用户应用开发时发现以下几点限制：
由于上述关键用户APP的限制，使用CDS I_MaterialDocumentItem_2，I_MaterialStock_2无法按需求做Group by和join，故在二系统内无法实现该客户用例。
三系统架构：
由于三系统架构提供了开发扩展性，所以可以通过编写代码实现报表开发。
根据该用例的需求，通过group by和聚合，基于CDS I_MaterialDocumentItem_2快速获取到物料+批次+仓库寻找最早的入库时间，解决了关键用户APP内的限制问题。
最后完成查询如下：
另外， 三系统架构可以提供更好的报表质量保证。在两系统架构中，由于开发和测试都在同一个系统中进行，可能会导致测试过程中的干扰和冲突。而在三系统架构中，测试系统的引入可以隔离开发和测试环境，确保测试的独立性和准确性，从而提高报表的质量。
但三系统内也存在一定限制，例如：
综上，三系统内使用开发扩展性开发报表相比二系统内的关键用户扩展性灵活性更高，支持更多的功能；而现阶段关键用户扩展性开发会有相对较多可用于分析的CDS以及操作简单的优势。客户可以从报表内容以及开发成本的角度，选择自己适合的开发方式。
最后，感谢 @ qi.liu4在业务上提供的帮助和支持！
客户用例介绍：
该客户是一家集研发、制造和销售一体的高科技企业。在日常生产过程中，业务人员希望能在系统内查看到生产物料的在库时间，即“库龄”。与其他传统库龄报表不同，该客户更注重批次管理，需要溯源到该批次物料的最早入库时间，不考虑移库，从而计算批次的在库时间。
客户的所需大致表样如下：
| Plant | Material | Batch | Earliest Posting Date | Inventory age | Stock Quantity |
| 工厂 | 物料 | 批次 | 最早过账日期 | 库龄 | 库存量 |
二系统架构：
二系统架构内提供了关键用户开发可扩展性。使用可扩展性应用，关键用户可以创建细分的数据库表并设计查询。
根据分析，报表所需要的数据源均已发布且可以用于关键用户扩展：I_MaterialDocumentItem_2，I_MaterialStock_2。I_MaterialDocumentItem_2主要用来获取物料入库时间，从而计算库龄。I_MaterialStock_2可以获取到指定时间的物料库存数量。通过关联两个数据源即可获得用户所需的报表，但使用关键用户应用开发时发现以下几点限制：
- Custom CDS View APP: Date 类型的字段无法进行聚合。
在本用例中，需要获取物料最早的入库时间，所以需要对物料凭证中的日期做聚合，即Min()。但Date属于Dimension，APP内无法直接对Dimension的字段做聚合。
Workaround供参考：建立新的计算（度量），例如计算天数，对新的计算进行聚合。
- Custom CDS View APP: CDS维度无法进行调整。
根据客户的分析需求，客户需要根据物料+批次+仓库寻找最早的入库时间，即库位的调拨不影响库龄的计算。
但是在APP中，无法对CDS的维度进行调整，即无法对物料凭证对维度库位进行Group By操作。
- Manage KPI and Reports APP: 同一个table不支持显示两个数据源的度量
来自不同数据源的度量无法添加到同一个表内做展示。
- Custom CDS View APP: Union操作不支持。
APP内仅支持左连接。
由于上述关键用户APP的限制，使用CDS I_MaterialDocumentItem_2，I_MaterialStock_2无法按需求做Group by和join，故在二系统内无法实现该客户用例。
三系统架构：
由于三系统架构提供了开发扩展性，所以可以通过编写代码实现报表开发。
根据该用例的需求，通过group by和聚合，基于CDS I_MaterialDocumentItem_2快速获取到物料+批次+仓库寻找最早的入库时间，解决了关键用户APP内的限制问题。
define view ZXXXXXXX
as select from I_MaterialDocumentItem_2
{
key Plant,
key Material,
key Batch,
min(PostingDate) as EPostigDate
}
where
ReversedMaterialDocument = ''
group by
Plant,
Material,
Batch
最后完成查询如下：
另外， 三系统架构可以提供更好的报表质量保证。在两系统架构中，由于开发和测试都在同一个系统中进行，可能会导致测试过程中的干扰和冲突。而在三系统架构中，测试系统的引入可以隔离开发和测试环境，确保测试的独立性和准确性，从而提高报表的质量。
但三系统内也存在一定限制，例如：
- 发布用于开发扩展性的CDS有限。
需要注意的是，不是所有在关键用户扩展性中已发布的CDS在开发扩展性中同样可用。详细有关CDS的发布状态需要根据SAP Help Portal以及应用View Browser里面的信息为准。目前可用于关键用户扩展性的CDS较多，尤其是一些cube类型的CDS在开发扩展性中不可用。
- Annotation VDM.VIEWTYPE不可用
详细有关于已经发布的分析的注释，可以参考链接：https://help.sap.com/docs/ABAP_Cloud/f055b8bf582d4f34b91da667bc1fcce6/72c72e31b9f643d5a66a2bf0c9ce4b...
综上，三系统内使用开发扩展性开发报表相比二系统内的关键用户扩展性灵活性更高，支持更多的功能；而现阶段关键用户扩展性开发会有相对较多可用于分析的CDS以及操作简单的优势。客户可以从报表内容以及开发成本的角度，选择自己适合的开发方式。
最后，感谢 @ qi.liu4在业务上提供的帮助和支持！
- SAP Managed Tags:
