在这篇文章中，我想到了新的SAP云平台ABAP环境，它是什么，它不是什么，以及为什么我认为这是一个伟大的举动。

一两天前，这条微博出现在我的时间轴上，它让我微笑：

上周，Harald Kuck宣布了SAP云平台ABAP环境的可用性，并进行了一天的跟踪后来，Karl Kessler又发了一篇帖子："SAP云平台ABAP环境是实时的"。虽然这是一个相当大的事件，但这并不是一个惊喜——这是我们许多人期待已久的事情。尽管如此，它确实给我提供了很多值得怀疑的东西，这是一件好事。

我鼓励你阅读Harald和Karl的帖子，因为他们提供了很多关于环境的信息，如果你在Twitter上，Jens Weiler发布了一系列带有标签#ABAPPaaS的tweet，这绝对是值得的密切关注。

什么是ABAP

ABAP已经和我们在一起很久了。当我思考这到底意味着什么时，我发现很难准确地说出来。一方面，ABAP是一种语言，一种自20世纪80年代末问世以来经过多年发展的语言（我记得当时我在SAP R/2安装的大型机上用作业控制语言在SYSIN DD语句中编写了早期的ABAP报告结构）。

但ABAP的意义不止于此——至少可能是微妙的或隐含的。可以说，作为一名ABAP程序员，意味着要在设计时和运行时的环境中，从后端和前端的角度构建事务和报表。它意味着使用编辑器工具和软件后勤设施，这些工具本身是用ABAP编写的，也在同一个环境中运行。或许更重要的是，在考虑新的SAP云平台ABAP环境时，它也在很大程度上暗示了SAP特定的用户访问机制—当然是SAPGUI，但最近还包括浏览器，有了WebdynproABAP结构（尽管在这里，UI执行的主要"质量"仍然停留在ABAP堆栈本身中）。

后端和前端的阴阳关系

SAP Fiori的出现和由外而内的编程方法，我们现在构建的用户界面不仅具有开放标准，而且还能够在传统的应用程序之外运行ABAP环境——在浏览器中直接使用UI5之类的工具包——预示着一个新的时代。

不仅如此，它还必要地向我们介绍了新的工作方式、分布式源代码控制系统、新的编辑器、部署管道的概念等等。与此同时，我们看到一种新的用于编写ABAP本身的编辑器环境的流行程度在上升——Eclipse编辑器框架内的ABAP开发工具（ADT）*.

*我的一部分仍然对通过R/2事务TM38提供的Roscoe风格的ABAP编辑器情有独钟；但这也许是另一个时代的故事。

构建Fiori应用程序的实用方法是使用UI5工具包来构建前端组件，返利淘客，而前端组件又使用写在ABAP堆栈（或本机在HANA中）上并通过有线协议公开的后端组件，其中线是HTTP形状的，协议通常是（尽管不是）总是）OData风格。

所以在过去的几年里，后端和前端之间有一个可爱的阴阳平衡，两者同等重要，相互补充。

云，和扩展SaaS解决方案

进入，离开舞台，软件解决方案，如SuccessFactors，s/4HANA云，等等。什么阶段？当然是SAP云平台。在这个云解决方案的新时代，企业需要什么？扩展、弯曲和塑造这些云解决方案以满足其自身需求的能力——同时，至关重要的是，不要让自己陷入无法进行软件升级的境地。因此，我们讨论了应用内扩展，这些扩展完全在SaaS解决方案本身的范围内，行业云，但更重要的是，还涉及到需要新前端甚至新后端的并行扩展，北京大数据公司有哪些，将标准功能与定制功能相结合，以提供特定于业务的解决方案。

对于这些并行扩展，我们需要一个后端运行时和持久性层。在某个地方编写我们的应用程序逻辑或定制的OData服务，在某个地方运行代码，这些代码使用定义良好的api通过SAP云平台的连接结构连接到SaaS解决方案。换言之，这是一个呼叫总部的地方。

当然，在SAP云平台环境中，我们已经有了呼叫总部的地方——例如，看看SAP云平台的优秀应用程序编程模型，它为我们提供了语言和持久层不可知的支持，用于构建所需的核心数据和服务。这是针对云铸造环境的。

云中的ABAP

但是我了解到的关于云，特别是SAP云平台的一点是，它是关于选择的。是的，有一些固执己见的方法来构建东西，但选择起着很大的作用，这是有充分理由的。问题域、现有的软件解决方案上下文、团队可用性、技术轨迹、技能集可用性和许多其他因素的结合意味着永远不会有一个一刀切的解决方案。

这让我想到了一个事实，即SAP云平台上有不同的环境，所有这些都有着坚实的目的。当然，我们想到的两个主要环境是Neo和cloudfoundry。但上周的宣布意味着，现在我们有另一个环境可以添加到选择中—ABAP.