SAP Cloud Platform ABAP环境
在这篇博客中，我将其称为ABAP PaaS，因为它就是这样：ABAP平台即服务。SAP历史上第一次，全球开发人员可以在云中构建和运行ABAP代码。在SAP Cloud Platform上，ABAP现在是块上的新孩子，在Java或Node.js旁边。
你认为我们去年发了很多噪音，从那以后一直很安静吗？（如果不这样，请跳过这些行）。这正是我不喜欢前期噪音的原因。我记得1998年我们在Linux上实现R / 3的好时光。在端口完成之前，我们没有告诉SAP内部或外部的任何人。只有这样才能说服Hasso开源和Linux真的很酷。然后在CeBIT 1999上传播这个信息。顺便说一下，我生命中最美好的时光。至今。
今天的事情有点不同，我可以告诉你。此外，与操作系统端口相比，从云计算主要在天空中的代码中获取ABAP PaaS是一项相当大的任务。到目前为止尚未完成。我们刚刚开始使用最低限度的可行产品（我希望比最低产品更可行）。“早期发布，经常发布 - 并倾听您的客户”是我们在Linux上使用R / 3实施的开源咒语之一。现在我们用ABAP PaaS做同样的事情（哦，是的，它确实也包括了听力部分）。
好处是，在云端，我们没有所有这些不同版本的版本，而且完全支离破碎的本地ABAP社区：你们中的一些人仍在使用ABAP 4.6C（我作为开发人员贡献了一个内核，欢乐时光），你们中的一些人已经在最新的S / 4HANA版本上发布了。使用ABAP PaaS，只有这一个生物，总是最新的。对我们所有人来说，同时。这样可以更轻松地收集反馈并让您受到影响。不是您或您的公司可能会在几年内安装的版本，而是您现在正在使用的ABAP PaaS。
对我来说，这是我在SAP工作近30年的非常特殊的时刻。我们现在正在为未来10年奠定基础。我真的很自豪能够成为实现这一目标的出色团队的一员。而且我非常高兴被像Boris Gebhardt（首席产品所有者ABAP平台），Frank Jentsch（项目负责人ABAP PaaS）和Karl Kessler（产品管理）这样的朋友包围，仅举几个贡献的人中的一小部分。 。非常感谢大家。没有你们，我会迷失方向，而且没有ABAP PaaS。
经常问的问题
此常见问题解答的主要目标是诚实的期望管理。在本节中，我们将回答您可能遇到的基本问题，如果您只是好奇ABAP PaaS的全部内容。向下滚动到开发部分，了解有关您当前所知的ABAP与ABAP PaaS之间差异的更多详细信息。
[Q1]简而言之：对我来说有什么用？
您是ABAP开发人员？
那么，您现在可以在云中为云编写代码。是的，与您的本地ABAP体验相比，这可能会有所不同。从现在开始，您始终可以使用最新，最好的ABAP和SAP HANA功能，或者调用SAP Cloud Platform提供的任何微服务。此外，升级后繁琐的任务也不会有更多的痛苦，因为SAP正在运行整个ABAP平台和HANA层，而不需要任何后续操作。
您是使用现有业务解决方案前往SAP S / 4HANA Cloud的客户吗？
然后，ABAP PaaS是一个很好的机会，您可以将您的本地ABAP扩展转换为云，实现现代化和稳定您的自定义代码，并提高您的ABAP团队的技能。
您打算在未来几年内与SAP ERP或SAP S / 4HANA系统保持在一起？
暂时继续经典的ABAP定制开发没有任何问题。对您而言，ABAP PaaS是创建创新和分离扩展的真正选择。考虑在云中运行的场景，利用SAP HANA并使用其他SAP Cloud Platform服务，而不管实现语言如何。所有这些都不会干扰或加载您的本地ERP系统，即稳定的数字核心。通过使用干净API的分离方法，使您的下一次ERP升级变得复杂的扩展或修改的时间结束了。
您可以使用Cloud Cockpit创建和维护ABAP环境，使用ABAP开发工具（ADT）编写ABAP代码，并使用Git进行代码交换和版本控制。ABAP PaaS本身是SAP Cloud Platform的一个集成部分，利用其服务（包括HANA）。有关ABAP编程环境的更多详细信息，请参见下面的开发人员部分。
[Q2]如果我可以在SAP Cloud Platform上使用Java或Node.js，为什么要考虑ABAP？
好点子。在谈论云时，ABAP可能不是第一个想到的东西。所以首先：这是关于自由选择，没有人会迫使你。
绝大多数SAP数字核心都基于ABAP。这意味着有很多ABAP知道世界上有多少，以及用ABAP编写的大量扩展。这正是ABAP PaaS的最佳选择。在ABAP PaaS的非功能属性非常充足的情况下，因为目标SaaS解决方案不是Twitter，重用现有的ABAP技能甚至云中的部分代码可能是一个巨大的好处（参见下面的开发人员部分） 。
除此之外：从技术角度来看，由于数据类型和结构的接近程度，我们希望用ABAP扩展增强ABAP应用程序可能不是最糟糕的选择（考虑数据复制或数据代理方案） 。
我们坚信从客户开始到现在的位置并帮助他们迁移到云，而ABAP PaaS在这里可以提供帮助。
[Q3] ABAP社区有一个很长的愿望清单，只考虑版本管理。为什么要浪费时间使用ABAP PaaS？
如上所述，激励ABAP PaaS的两个主要用例是：
- 使用解耦的ABAP代码扩展S / 4HANA Cloud
- 使用解耦的ABAP代码将您的本地ABAP扩展转换为云
第三个方面是独特的机会
- 使ABAP宇宙现代化
这意味着我们现在可以将ABAP PaaS用作创新领跑者（参见Q12），如上所述：邀请您提供反馈并影响ABAP PaaS的未来。
关于潜在的浪费：在云中，ABAP平台有两种风格，或者扮演两种不同的角色。一方面，作为SAP自身更大的SaaS解决方案（如S / 4HANA Cloud）的内部基础。在此背景下，ABAP平台仅在内部使用SAP作为SaaS解决方案的推动者。现在的另一个角色是ABAP PaaS，提供给世界上任何想要在ABAP之上构建和运行SaaS解决方案的人。
两种风格都基于ABAP内核和ABAP层的一个公共代码行。大多数与ABAP和Cloud相关的SAP投资（甚至是S / 4HANA on-prem）都流入这个公共代码行，因此无论如何都没有浪费。
关于版本管理：不用担心，我们听到你响亮而清晰（见下面的Git问题）。
[Q4]第一个版本到底能做些什么？只是玩它或做真正的东西？
从一开始，ABAP就是为了有效地编写和运行业务应用程序，而ABAP PaaS并没有改变这一点。您可以开发独立的业务应用程序或数字核心的扩展，无论是云还是本地，S / 4HANA还是传统的ERP。
第一个版本的重点是S / 4HANA Cloud的扩展。不用担心，计划在2018年的本地系统（出站远程函数调用（RFC））连接。此外，您可以在ABAP中开发服务并通过HTTP（S）或OData公开它们。
作为您今天可以使用ABAP PaaS构建的示例，可以想象我们在内部演示中使用的以下场景或用户故事：销售代表希望使用OpenStreetMap在附近找到潜在的新客户。在收集了一些候选人之后，她想要创建和编辑客户数据，最后将它们同步到她的S / 4HANA Cloud帐户。
这是ABAP PaaS的第一个版本，范围有限。它会随着时间的推移而增长，希望能得到您的反馈和贡献，但今天您已经可以编写真正的应用程序和服务。
[Q5]路线图和愿景是什么？
ABAP PaaS的第一个版本侧重于从头开始编写的代码，以扩展S / 4HANA Cloud。积压中的下一个项目涉及对自定义代码迁移的支持，以及本地解决方案的扩展。
对于2019年，我们计划为在ABAP PaaS之上为客户开发和运行应用程序的合作伙伴提供更好的支持（考虑与SAP App Center集成，或通过多租户优化边际成本）。
开发者视图
在本节中，我们尝试为经验丰富的ABAP开发人员提供的问题提供答案：ABAP PaaS与我的本地ABAP之间有什么区别？功能x是否受支持？我可以重用现有代码吗？
[Q6]为什么这么严格？我听说没有SAP GUI或Web Dynpro，只有有限的ABAP语言功能和API。为什么我不能像在我的本地系统上那样开发？
云带来了新的责任分配。在这种情况下，提供商（SAP）负责管理ABAP平台和SAP HANA层，操作整个环境并不断提供新功能和修复。顶部的所有代码都由您（租户）管理。这只有在提供者和租户之间以及租户之间严格分开时才有效。作为提供商，我们必须能够在不影响您的代码的情况下交换平台。
这正是我们需要您和我们之间明确且明确定义的界面的原因：受支持的ABAP伪像的白名单，从ABAP语言到CDS视图。这个白名单会随着时间的推移而增长，并邀请您帮助塑造它。但白名单只能支持不会破坏上述任何隔离类型的伪像，并且不得引入不兼容的更改。最后但并非最不重要的一点是，白名单只能提供那些可以在产品标准方面得到合理支持的文物，无论是安全还是性能。
这就是为什么我们从小开始，为什么我们只展示RESTful服务而不是支持SAP Gui，或者为什么直接访问文件系统不起作用的原因。
[Q7]好的，明白了。那对ABAP PaaS意味着什么呢？
我们定义了以下关于ABAP PaaS的性质和范围的基本原则：
- 它仍然是ABAP - 我们不是在创建一种新语言，而是一种适当的子集。
- 它是云 - 无论是中断还是危及云操作都是不允许的。
- 一个原则 - 保持简单，降低操作风险。对于UI或输出管理等组件，我们支持一种战略云变体，而不是所有历史悠久的前辈。
- 从小做起 - 因为我们必须保持白名单稳定，我们从一个小白名单开始并逐步增强它。
- 倾听您的客户 - 我们与早期采用者和ABAP社区合作，对我们的积压进行排名。
- 务实的方法 - 我们试图在现代ABAP平台的美感和重用现有的ABAP代码之间找到平衡点。在为您的愿望清单打开时，我们真的希望您不要坚持MOVE source TO目的地PERCENTAGE perc
为了实施这些原则，ABAP PaaS在设计时检查应用程序代码。违反这些规则的开发对象会导致语法错误。不支持静态无法检查的代码。我们目前正在评估其他运行时检查以支持动态ABAP编程功能。
[Q8]这些原则对用户界面，语言或SAP HANA访问有何影响？
干得好：
UI
ABAP PaaS仅通过OData或纯HTTP公开其服务。SAP GUI，Web GUI，Web Dynpro或BSP等经典ABAP UI技术不可用。然后，Fiori UI或任何其他基于Web的UI框架可以使用公开的服务。
SAP HANA
要强制执行安全的ABAP操作，仅支持对ABAP管理的HANA对象的ABAP管理访问。这包括ABAP SQL，核心数据服务（CDS）和ABAP管理的数据库程序（AMDP）。我们无法支持原生HANA人工制品或原生HANA访问权限。
ABAP语言
ABAP PaaS使用ABAP语言的特殊云版本。不包括可能损害云操作或无法控制的语句（如本地文件访问，内核调用，EXEC SQL，生成报告等）。此外，已删除标记为已过时的语句，并且不支持CALL SCREEN等语句，因为dynpro技术不再是ABAP PaaS产品的一部分。
ABAP重用服务和重用元素
ABAP PaaS在重用层BASIS和ABA中提供了众所周知对象的白名单子集（例如CDS视图或ABAP类）。
此外，ABAP PaaS取代或改编了一些有关目的地，UI存储库，打印或身份管理的技术ABAP服务。在ABAP PaaS中，这些服务是通过调用SAP Cloud Platform服务来实现的。
ABAP编程模型
对于Fiori和OData服务，强制执行新的RESTful ABAP编程模型（RAP）。不支持使用网关服务（SAP网关服务构建器SEGW）或BOPF的较旧版本的Fiori编程模型。
为了构建标准的REST / HTTP服务，ABAP PaaS提供了新的白名单ABAP接口。
[Q9]白名单在第一个版本中包含哪些ABAP对象和API？
第一个ABAP PaaS版本的白名单包含400多个ABAP开发对象（类，接口，CDS视图，数据元素等），侧重于核心ABAP服务，如日期和时间转换，XML处理或应用程序日志。毫无疑问，白名单将在下一版本中显着增长。
在提供更多技术服务之后，我们计划将业务重用服务列入白名单，例如号码范围，工厂日历或更改文档。
[Q10]我真的可以重用我的ABAP专有技术吗？
您是否熟悉SAP HANA，Fiori应用程序，Eclipse中的ABAP或单元测试中的ABAP代码？
然后，您距离在ABAP PaaS上开发和运行您的第一个应用程序或服务只有一小步。您只需要一点点开始学习RESTful ABAP编程模型（RAP）。
你问自己为什么SE80和SAP GUI不会这样做？
也许是时候给所有新功能提供过去几年为ABAP社区发明的机会了。请不要惊慌。我们提供丰富的培训课程和教程，以帮助您。如果你喜欢ABAP到目前为止，你不会失望。这是一个承诺。
[Q11]我可以将我的z-Code复制并粘贴到ABAP PaaS吗？
首先，好消息：支持复制和粘贴
缺点：如果您只是将本地代码复制到ABAP PaaS，您将看到很多语法错误。更严重的是，问题是您的现有ABAP代码中有多少可以真正在ABAP PaaS中重用。这很难预测，因为它很大程度上依赖于您的代码，但我们会尝试进行预测。
以下ABAP PaaS特性可减少现有ABAP代码的重用，并按其对重用的影响进行排序：
- ABAP PaaS与核心业务系统并行运行
- 白名单技术（例如，没有SAP GUI）
- 列入白名单的SAP对象（例如，无法直接访问SAP表）
- 白名单ABAP声明（例如没有OPEN DATASET）
现有自定义代码最具挑战性的是并行方法和缺少对GUI / dynpro技术的支持。让我们从并排开始吧。
已经在本地NetWeaver中，我们已经看到了许多集线器场景或分离的并排扩展。就像这些场景中的解决方案一样，ABAP PaaS应用程序通过远程API与核心业务系统进行通信。因此，与核心业务系统的业务逻辑松散耦合的自定义代码是转向ABAP PaaS的良好候选者。
另一方面，与业务流程深度集成的本地自定义代码应该更好地保留在核心系统中。这与S / 4HANA Cloud中所谓的应用内扩展相当：对于紧密耦合的场景，这是正确的使用机制。即使对于解耦方案，应用程序内扩展/自定义代码和ABAP PaaS应用程序的组合通常也是最佳选择。
总结一下，如果你有自定义的NetWeaver附加组件或松散耦合的自定义扩展已经使用了Fiori UI，那么你在ABAP PaaS上的代码重用将会非常高。在所有其他场景中，重用主要减少到业务逻辑。您可以在ABAP PaaS中重用多少业务逻辑取决于您的自定义代码的体系结构。最有利于重用的是UI代码，自定义业务代码和SAP代码之间的明确区分。
[问题12] ABAP PaaS作为创新领跑者？那是什么意思？
SAP在定义的日期每季度自动更新ABAP PaaS。创新将首先到达ABAP PaaS，之后可能会在其他基于ABAP的解决方案中实施。
在这里，我们开始翻新整个ABAP开发过程（见下文）。在这里，您是第一个了解基于RAP的全新且非常有效的Fiori编程模型的人。在这里，您可以看到我们如何在ABAP中直接提供SAP HANA功能，如图形，层次结构或地理空间。或者使用SAP Cloud Platform服务（如身份验证，门户，移动，物联网或机器学习）丰富您的ABAP PaaS应用程序。
[Q13] Git怎么样？
我们保存了最好的一点直到最后。ABAP PaaS使用Git进行代码交换和代码部署。
代码交换用例包括在社区项目中共享ABAP代码或其他ABAP假象或通过Git在ABAP系统之间交换ABAP代码的可能性（例如，在将自定义代码从内部部署系统传输到ABAP PaaS时）。对于代码交换，ABAP PaaS使用着名的开源解决方案abapGit。
代码部署用例是关于在ABAP PaaS系统之间（例如，从开发系统到测试系统）传输ABAP代码和其他ABAP假象。ABAP PaaS的第一个版本使用Git在标准ABAP传输管理系统的引擎下进行代码部署。
我们知道到目前为止，ABAP中的版本控制相当有限，并且几乎不支持分支，合并或CI / CD（持续集成/交付）工具链。目标是使用像Git这样的版本控制系统逐步翻新ABAP，而不会牺牲ABAP变更和传输系统的优势。
