Gateway的架构，设计原则和部署

image.png

OData介绍

OData是一种非常简单的接口协议，它有着简单的结构以及简单的操作方式。当我们提及接口的方式，目前首推的是RESTful，REST是Representational State Transfer的缩写，它是一种轻量的接口方式（和传统的SOAP的接口方式相比）。注意，REST不是协议，只是开发接口中的术语，这种接口方式有以下一些特点：

• 无状态交互（Statelessness）

  请求不会在服务端存储，任何的请求包含了所有服务所需要的信息。

• 可缓存（Cacheability）

  请求的返回信息可以定义是否需要缓存。

• 层级系统（Layered System）

  客户端不清楚访问的最终系统，有可能是直接连接，也可能是中间系统。

• 统一接口（Uniform Interface）

  统一的接口方式可以将客户端和服务端解耦。

• 按需编程（Code on demand）

  服务可以根据客户端传输的请求内容定制化。

REST请求的通用操作：

• GET

  客户端从服务端获取数据。

• POST

  客户端传送信息给服务端进行创建的操作或者修改的操作。

• PUT

  客户端传送信息给服务端进行创建的操作或者修改的操作。

• DELETE

  删除服务端的数据操作

• PATCH

  更新某一条数据中的某个属性。

OData的定义

OData是Open Data Protocol的缩写，是一种基于REST的数据访问方式。目前这种协议有微软进行维护和发布。

详细的OData的介绍请参考：www.odata.org

OData 协议遵循以下五种设计原则

• 数据多样性存储

  在一个服务里面可以定义多种数据的存储。

• 向下兼容

  客户端和服务端可以使用不同版本的OData服务，每个服务都可以向下兼容。

• REST原则

  遵循上文中提到的REST原则。

• 容易扩展

  如果需要额外的服务，应该能够进行简单的扩展。

• 简单

实施OData

如果需要实施OData服务，需要完成以下四个部分：

• OData模型

  定义数据结构，一般发生在后端系统。

• OData协议

  支持CRUDQ（创建，读取，修改，删除，查询）功能，数据的传输可以使用XML或者JSON。

• OData客户端库

  保证了客户端能够使用库函数方便的访问OData服务。注意，客户端库并不是必须的，但是尽量有，这样可以节省大量的编码工作。

• OData服务

  可以最终被客户端访问的服务。

OData服务的结构

• 服务文档（Service Document）
• 服务元结构文档（Service Metadata Document）

以上两种文档包含了：

• 实体（Entity）
• 实体类型（Entity Type）
• 实体集合（Entity Set）
• 属性（Property）
• 导航属性（Navigation Property）
• 关联（Association）

OData的操作

• 创建

  HTTP请求类型： POST

  成功返回：201

• 读取（包括单条读取-read_entity,多条读取read_entityset）

  HTTP请求类型：GET

  成功返回：200

• 更新

  HTTP请求类型：PUT

  成功返回：204

• 删除

  HTTP请求类型：DELETE

  成功返回：204

• 查询

  HTTP请求类型：GET/POST

  成功返回：200/201

  查询操作清单：

  操作	查询方式
  筛选	$filter
  排序	$orderby
  客户端换页	$top,skip,inlinecount
  数据量	$count
  嵌入内容	$expand
  格式化	$format

OData 在SAP中的方案

SAP对于标准的OData进行了扩展，特别是在对于字段属性定义上，如果熟悉SAP系统的人都知道SAP系统表中的字段定义往往很难理解，SAP的扩展中就包括了使用字段的描述作为OData的属性进行命名。

SAP对于OData的支持扩展包括：

• HTTP返回码可以自定义
• CRUD的支持
• CUD多媒体文件的支持
• 序列化处理
• 深层结构处理
• Merge/patch的支持
• Paging,filter的扩展支持

OData在SAP各种产品中的使用：

• SAP Fiori
• SAP Jam
• SAP Netweaver Portal
• SAP HANA

总结

本文简单的过了一下OData，也大概看了一下SAP中OData的使用，在接下来的一篇文章中会介绍Gateway的基本架构。

image.png

SAP Gateway简单来说，就是为了前端不懂ABAP开发的人员所设计的，将后端的数据模型封装成为标准的OData服务以供前端开发人员进行简单的调用。

使用SAP Gateway，后端的多套复杂系统将会被隐藏，暴露在前端可以使用的是一些列API，所以，开发人员不需要关心数据的来源，只需要集中在设计应用方面。

• 开放性

  服务可以被任何平台，任何设备调用。

• 永恒性

  服务可以应用于任何版本的SAP后端业务系统。

• 易用性

  应用程序接口可以被简单的调用，而不需要一定的SAP系统知识。

基本架构

使用 SAP NetWeaver Gateway产品基本符合三层架构：

• 前端

  包括各种平台的应用，例如手机，Web应用，各种企业应用，以及一些社交媒体应用。

• 中间层

  SAP NetWeaver Gateway，用于前后端的数据交互。

• 后端

  包括SAP的各种产品，例如CRM，ECC，SCM等等

SAP NetWeaver Gateway主要组件

• IW_FND && GW_CORE

  Gateway的核心组件，其中包括了：

  • OData库以及运行环境
  • OData服务注册和发布
  • OData元数据的存储
  • 服务的跟踪与监控

• IW_BEP

  • OData建模与设计工具
  • 数据连接服务
    • BAPI
    • RFC
    • BOL
    • HANA

• 其他组件作为扩展

  • IW_HDB

    连接SAP HANA系统作为数据提供者，这个包里包含了使用ADBC（ABAP Database Connectivity）协议进行OData服务的开发。

  • IW_PGW

    整合BPM（Business Process Management）的流程。

  • IW_GIL

    为Genil（Generic Interaction Layer）提供了OData适配器。

SAP NetWeaver Gateway的三种部署方式

• 集成在SAP后端系统中部署

  系统安装于SAP后端系统中，作为Add-on安装，这样，业务系统与Gateway在相同的环境之中。

• 作为中间层单独部署

  单独安装于一套服务器中，和后端系统的连接单独配置。

• 混合部署

  前后端分开，核心组件分别安装，后端需要IW_BEP，前端安装GW_CORE。在后端进行服务开发，在Gateway发布服务。

三种方式的比较

	集成部署	单独部署	混合部署
安装和配置	不需要额外的服务器，所有的动作在业务系统中完成	需要单独的服务器来安装Gateway组件，并且需要配置和后端系统中的连接	需要额外的服务器来安装Gateway，同时，也需要配置和后端系统的连接。
性能	在后端业务系统中增加额外的负载，但是同时却省掉了远程调用的负载。	Gateway服务器承担了增加的负载，后端需要承担远程调用的负载	Gateway承担服务负载，后端承担远程调用负载。
成本	不需要额外的费用	额外的服务器费用	额外的服务器费用
维护	Gateway的维护依赖于业务系统的维护周期。	单独维护，没有依赖	单独维护，没有依赖
开发	可以直接使用业务系统中的数据字典，结构，函数，直接操作后端系统。	需要后端提供RFC（远程函数调用），BAPI等支持	对于后端系统完全访问和操作，可以直接使用后端的数据字典或者结构等等。
适用场景	测试，可用性检查等等	可用性测试或者生产环境，如果在已经存在的SAP后端系统中不允许安装额外Gateway的组件的时候。	生产环境，如果使用SAP Fiori的话推荐使用这种部署方式。

总结

本文大概介绍了Gateway的特点，结构以及部署方式。我将会以混合部署的方式进行后续的讲解，接下来的文章中介绍SAP后端业务系统和Gateway的连接配置。