今天决定跟着SAP官方资源系统学习一遍BTP Itegration Suite。找到两个Learning Journey: SAP Integration Suite Foundation 和 Solution Integration on SAP BTP。还有一个更大的roadmap,Integration Suite的官方内容在这里都可以链接到。 认证暂时只找到了一个比较基础的：SAP Certified Development Associate - SAP Integration Suite，单看这个认证相对简单，链接到一个learning Journey：Developing with SAP Integration Suite，十几个小时的学习就可以完成，那就从这个开始吧。

一图理解什么是分布式体系架构： 分布式的架构中包括很多子系统，这些子系统在特定体系结构的框架内耦合在一起，并协同处理任务。 由于存在异质性，那么在部署一套分布式架构的时候就会面临如下挑战：

API就是解决办法中最重要的一种。云原生架构就是基于API。

练习场景 一家公司向终端客户销售商品。由于全球发货问题，部分产品无法按时发货。应该通知订购这些产品的客户延迟交货的情况。 （1）（2）（3）分别是产品清单，员工，和流程开始 （4） 产品id列表与订单数据库进行匹配以验证订单是否有效。 （5） 验证后的产品进行进一步处理。 （6） 通过订单数据库确定相关联的订单和和联系人。 （7） 通知Delay信息，可以是邮件或短信。

整个过程将通过SAP Integration Suite的工具和概念来实现。遵循SAP集成架构咨询方法论ISA-M，ISA-M中文版解读。

练习 跟着教程一步步做就好，申请BTP Trail账号很简单，然后开通Integration的capabilities，其中有一步setting-APIs，试用账号是不需要配置的

API First就是API优先，是SAP推荐的一种Approach，或者说是一个理念，它建立了一个模块化、可重用和可扩展的应用程序生态系统，程序就像乐高积木，这样会有一些优势出来，比如高解耦就可以并行开发，大幅提高软件开发的进度等等，把API被视为头等公民，一切都围绕着移动设备和客户端应用程序使用的最终产品，API优先方法涉及开发一致且可重用的API。这是通过使用API描述语言实现的。当然也有一些不同声音。

再回头看什么是API，API Application Programming Interface。API指定软件组件的操作operations以及输入Inputs和输出Outputs。它定义了独立于各自实现的功能，因此这些实现可以在不影响API用户的情况下进行变化。

在API这个超集下分了四个不同的API。

SAP中主要使用的接口类型 从技术上讲，已经达成了一些协议。下面的概述展示了API及其相互之间的关系。

实现API Provider 和API Consumer之间的契约

分两种方式：

练习 ES5是一套基于SAP NetWeaver AS ABAP 7.51的Demo系统，它可以用来尝试OData服务。SAP在上面实现了各种样例服务。这些服务可以通过互联网直接访问。在本练习中，使用了GWSAMPLE_BASIC服务。此示例服务基于企业采购模型(EPM)。这里有关于这个ES5 DEMO系统详细的信息。

什么是请求驱动架构？ 请求驱动的体系结构基于服务提供者和服务使用者之间的同步直接通信。就是传统的SOA。

示例： Request: Response:

什么是事件？ 从技术角度，事件可以是关于业务发生的一条消息，比如说，它可以是订单的创建，该事件可以通过(异步)的方式推送到代理Broker来触发。 示例： Event Producer at SAP 在SAP ECC 和 SAP S/4HANA (Cloud and On-Premise)中SAP提供了 Event Enablement 这个add on。

什么是事件驱动架构？ EDA是一种以事件为媒介，实现组件或服务之间最大松耦合的方式。传统面向接口编程是以接口为媒介，实现调用接口者和接口实现者之间的解耦，但是这种解耦程度不是很高，如果接口发生变化，双方代码都需要变动，而事件驱动则是调用者和被调用者互相不知道对方，两者只和中间消息队列耦合。

event-driven architecture (EDA)是一种软件设计模式，在这种模式中，解耦的应用程序可以通过事件代理异步发布和订阅事件。事件代理是一种现代的面向消息的中间件，例如SAP的Service Mesh。更多信息

它有两种模式，一种是拉，一种是推。

webhook 可以理解成一个HTTP回调函数，当状态发生变化时发生的HTTP POST，即通过HTTP POST发送事件通知。Webhooks用于实时通知，因此系统可以在事件发生时直接更新。基本上webhook是一个简单的URL，也可以在浏览器中定期调用它。在SAP Service Mesh的上下文中，webhook URL在订阅时使用。这允许服务知道将订阅主题的消息发送到哪里。

结合两种操作操作模式可以设计出混合模式。 No.1到No.6的工作原理与前一节中描述的一样，但新的是事件消费者(No.7)向事件生产者(No.1)提交请求，例如，读取刚刚更改的产品数据。然后事件使用者可以处理数据集。

一般来说，REST描述的是机器到机器的接口。在Web开发中，REST允许在请求时呈现内容，通常称为动态内容。RESTful动态内容使用服务器端呈现来生成Web站点，并将内容发送到请求的Web浏览器，该浏览器解释服务器的代码并在用户的Web浏览器中呈现页面。更多信息

（官网这一章节的解释太虚了，下面是之前整理的内容）

Uniform Resource Identifier统一资源标识符 Uniform Resource Locator统一资源定位符 Universal Resource Name 统一资源名称 理解了这三个词，才更容易理解RESTful API URI是个纯粹的句法结构，用于指定标识Web资源的字符串的各个不同部分。也就是说，URI分为三种，URL or URN or （URL and URI）,URL代表资源的路径地址，而URN代表资源的名称。通过URL和URN找到资源是对网络位置进行标识，就是URI，如上图中的例子，URL就是告诉我们哪里有我们要找的资源， URN是我们找要的资源在地址内的位置，有了整个URI，再说明是要取资源（GET）还是发资源（POST），整个动作就可以完整的完成了。

RESTful是一种架构。如果一个架构符合REST原则，就称它为RESTful架构。上面我们讨论的URI就是为了REST的主语“资源”，所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实体。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。 那这个“资源”的状态是如果转化（State Transfer）的呢？访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。这就和我们上面的内容联系起来了。 理解了上面的内容，我们就知道了RESTful的设计架构中因为"资源"表示一种实体，所以URI操作的资源应该是名词，URI不应该有动词，动词应该放在HTTP协议中。 举例： 举例来说，某个URI是*…/posts/show/1*，其中show是动词，这个URI就设计错了，正确的写法应该是*/posts/1*，然后用GET方法表示show。 如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是： 　　POST /accounts/1/transfer/500/to/2 正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务： 　　POST /transaction HTTP/1.1 　　Host: 127.0.0.1 　　 　　from=1&to=2&amount=500.00 RESTful 是目前最流行的 API 设计规范，用于 Web 数据接口的设计。RESTful API是一种互联网应用程序的API设计理念：URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。理解了上面这个例子也就理解了RESTful的设计架构，也就很容易能理解如何设计RESTful架构的API。

什么是OData? 在计算领域，开放数据协议(OData)是一种开放协议，它允许以简单和标准的方式创建和使用可查询和可互操作的RESTful api。OData构建在HTTP、AtomPub和JSON之上，使用uri来寻址和访问数据源资源。它允许从各种来源访问信息，包括(但不限于)关系数据库和文件系统。 OData 全称是Open Data Protocol, 即开放数据协议 ,它的主要用途便是通过Web来对资源进行查询、创建和更新 。OData就是一个设计和使用上面提到的RESTful API的标准协议（就是大家都要准守的规则，只要你按这个标准创建RESTful API，其它组织都可以按照OData标准中定义的方式去使用这个API获取/修改资源，就像是SQL标准和数据库之间的关系）。OData就是一个接口，基于HTTP（S）协议，各种程序和系统都可以互联互通，执行读、写、改等操作，这样SAP外部的程序就可以操作SAP的数据，甚至调用BAPI等等。相当于SAP对外又开放了一个接口，这个接口基于ODATA协议，这个接口就是SAP Netweaver Gateway。换句话说OData开放和分享了SAP的数据，这样就可以开发基于Web和Mobile的程序而不用考虑Web程序和Mobile应用是用什么技术开发的了，实现了跨平台特性。OData协议支持一系列流行的数据格式, 包括JSON，ATOM ，XML。

SAP Annotations

接下来，要讲一下SAP Annotations，许多组织现在已经开始使用基于REST的服务公开数据，但是却很难编写使用多个数据源的应用程序，因为每个数据源提供者会以稍微不同的方式公开数据。OData服务生成器可以公开其服务以及包含消费语义的元数据。OData利用XML、Atom和JSON等常见格式进行通信，这些格式是人们普遍理解的。客户端现在可以使用通用工具理解这些OData服务，并可以组合来自多个数据源的信息。 SAP利用了Atom发布协议提供的可扩展性特性来添加SAP特定的注释。AtomPub允许在服务文档中添加自己的标记。SAP从ABAP数据字典中添加注释，例如，将标签添加到文档中，然后前端应用程序可以使用这些文档。

体系结构约束Architectural constraints 必须满足以下限制条件:

下面依次说明：

可以看到对比上一个查询，这个查的是单条，也就是过滤后的数据。 Resource representation 就是数据以什么样的形式展示出来。 OData使用不同的格式来表示数据和数据模型。在OData协议4.0版本中，JSON格式是表示数据的标准，Atom格式仍处于委员会规范阶段。为了表示数据模型，使用了公共模式定义语言(CSDL)，它定义了OData服务公开的实体数据模型的XML表示。

JSON格式：https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/ProductSet(‘HT-1000’)?$format=json

XML格式：https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/ProductSet(‘HT-1000’)?$format=xml

完成三个目标：

分别对应三组URL: 1. https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/ProductSet(‘HT-1000’) 2. https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/ProductSet(‘HT-1000’)/ToSalesOrderLineItems/$count 3. https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/SalesOrderLineItemSet(SalesOrderID=‘0500000001’,ItemPosition=‘0000000070’)/ToHeader https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/SalesOrderSet(‘0500000001’)/ToBusinessPartner

什么是SAP Graph？ SAP Graph是SAP的统一API，使用了像OData v4这样的现代开放标准。SAP Graph是与业务数据的一个连接。SAP Graph引入了一个新的、统一的API，将所有业务数据作为一个单一的、语义连接的业务数据图来访问。更多信息更多信息

用大白话来说的话，SAP Graph是一个可以连接多个数据源的SAP图形化数据管理API入口，表现形式就是OData V4。SAP收购了一堆产品，客户是有需求把数据整合在一起的，SAP的Intelligent Suite虽然可以跨功能的把这些关键业务流程整合在一起，但是这种扩展的角色和解决方案的多样把这个事情搞的没那么简单。并且SAP套件的许多产品都有自己的堆栈，还有重叠的数据模型、不同的api和异构的基础设施，导致客户容易懵逼。

从软件开发人员的角度来看，这意味着访问sap管理的数据变得更加复杂。数据可以跨内部部署和云系统的混合网络进行联合，这些网络具有不同的安全协议、复制过程和多个主数据副本。开发SAP扩展应用程序就需要掌握更广泛的技能，即使是最简单的数据查询，开发的应用程序对最小的产品和landscape配置变化都很敏感。

这就是SAP Graph要解决的问题。于是SAP就想搞这么一个集中的、统一的API来管理这些异构数据源的数据。

SAP Graph通过为开发人员提供所有业务数据的单一连接和统一视图，将数据源(如SAP S/4HANA、SAP Sales Cloud和SAP SuccessFactors)的数据模型整合到一个统一连接的数据模型中，解决了这种失控的API复杂性和集成挑战，并在一个场景中表示所有数据。我们称之为业务数据图Business Data Graph。

作为一名开发人员，会面临着一个困境。产品或客户的概念对于构成LANDSCAPE中的许多业务系统来说是常见的。那应该使用哪一种定义呢?这些数据是如何管理的呢?SAP Graph通过引入统一的实体解决了这一难题，这些实体提供了业务模型的最常见属性，以便于使用，并连接到相应的系统特定业务对象，以获得业务对象的完整360°视图。

举例： 报价单由一个统一的SalesQuote实体Entity表示。报价与Customer实体有关联。报价也有多个行项目，每个行项目都引用一个Product实体，而Product实体又与其他实体(如Division)有多个关联。如下图所示: 每个实体Entity都有许多附加属性，例如KEY(在统一实体中称为id)和各种其他属性，这些属性可以是平面的、数组的，也可以是其他属性的更复杂的结构化组合。例如，items是一个结构化类型的数组。

使用SAP Graph，可以导航到并访问所需的数据，而不管这些数据位于何处。SAP Graph抽象了物理LANDSCAPE和不同产品堆栈的细节，并且提供了SAP管理数据的简单视图，可以通过单个API访问这些数据，涵盖所有关键用例。SAP Graph代表用户访问客户配置环境中的数据，在技术上充当中间件。SAP Graph本身不存储或缓存任何数据。