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的连接配置。
网友评论