我一直在慢慢地、逐渐地向云计算发展。随着ABAP开发人员的逐渐发展，我也指的是对新的ABAP语法的着迷，生态环境大数据，然后是对开发工具的改变。一个人不能照顾一层或堆栈，而完全的端到端方案可以通过直接编码实现。不用拐弯抹角，我说的是带有Fiori模板的注释的CDS视图。我们经常谈论ABAP在当前的开发场景中有多大的挑战，但SAP UI5开发不也是如此吗？你没质疑过吗？在我看来，注释是一个强大的开发人员技巧，不能再被忽视了。然而，这个博客的目的不是关于改变工具的影响，而是关于使用它们的经验。例如，在ABAP工作台上工作时，我从来没有遇到过这样的问题：首先想到的是提出一个OSS消息。最近，就在上周五，SCP的表现非常不一致，Basis和systems团队没有做出任何需要负责的更改。任何使用sapcp的人都会知道，淘客软件，在这个工具中频繁的更改并不总是对开发人员友好的。例如，几个月前，当我尝试演示物联网场景时，人们共享的大多数博客/文档都变得无关紧要，因为工具本身发生了变化。SAP帮助和文档当然有帮助，但有时不同的情况需要不同的解决方案。此外，我们并不总是在演示场景上工作，而是在富有成效的场景中，首先需要的是一致性和稳定性。最近，SAP将"适应性编辑器"的名称改为可视化编辑器。对我来说，适应编辑器是有意义的，因为我在Fiori启动板中看到了应用内扩展"适应UI"的相同名称。我没有检查在更高版本的S/4中是否也发生了变化。我找不到任何功能上的变化，因此不理解名称变化的基本原理。一个更好的改变是，在删除对应用程序内部所做的更改时，屏幕的改变会更快，甚至在做出更改后使预览速度更快。我发现点击刷新比预览按钮快。

基于模板的开发应该使我们的设计更加统一和快速。我们大多数人甚至在使用SAP为我们的开发场景提供的Fiori模板时也这么认为。在决定将这些模板用于生产性场景时，我们确实需要小心。直截了当地说，结果并不总是可预测的，而且看起来很容易实现的情况变成了广泛的努力。举个例子来说明我在说什么，一个人可以使用fiori元素用参数浏览，可以一个接一个地阅读无休止的线程，而没有明确的有用答案，个人用云服务器，这主要是误导性的。

我在那里花费了相当多的精力，但研究结果并没有让我对fiori模板的行为方式有任何具体的了解。从2016年开始，当参数化的CDS视图被@OData曝光时，人们提出了一些问题。发布：true，参数不显示在屏幕上。我花了很多精力去寻找我可能错的地方。我确信当一个博客上给出了一个真实的回复，比如"Fiori元素不支持带参数的CDS视图"时，这是做不到的。我不确定这句话的来龙去脉是否恰当。然而，疯狂开发人员的追求永远不会结束。我从一个带有参数的标准Fiori应用程序开始，企业软件服务，并尝试反向跟踪。准确地说，应用程序是"监控采购订单项目"（S/4 1709 FP02）。这个应用程序是用参数化的CDS视图开发的。区别在于它使用了分析页面类型的Fiori元素，而CDS不是用OData注释发布的，而是通过引用CDS视图来创建一个网关项目。

我使用了相同的CDS视图（使用OData注释），并尝试用类型为analytic page的Fiori元素模板来公开它，宾果！所以我马上得出的结论是，人工智能大数据，参数只能通过分析页面类型公开。然后，我尝试了使用网关项目的标准方法，在分析列表页上一切正常。出于好奇，我尝试将这个gateway项目公开给List Page类型的fiori元素，结果意外地显示了参数，但是在执行时，参数值并没有自动绑定到预期的结果。有人对这些结果有什么逻辑推理吗？为什么带有参数的CDS视图不能公开给带有OData注释的列表页，而可以通过中间的项目来完成？在我看来非常神秘。

为了补充这个列表，最近我注意到另一个变化，很可能是暂时的，也可能是神秘列表中的另一个变化。使用注释定义参数的值帮助时@消费.valuehelpdefinition{entity:…}这在分析页面类型应用程序中非常有效。它上周停止工作了。然而，这在列表页面J上开始运行良好，我明天可能会再次检查并注意到另一个谜团。

SAP不应该仅仅推动用于进行POC和演示的工具的想法只会随着这样的体验而变得更加强烈。该工具应该足够健壮和逻辑性，以支持生产场景。毕竟，如果每个场景都需要阅读大量的kba、SAP笔记和OSS，那么最后的体验并不好。