关于OData$batch processing已经有很多文章。这些都是丰富知识的。本文试图提供一些更实际的例子，说明如何显式地使用json进行$batch处理。本系列共分两部分，涵盖$batch processing的基本和高级功能。
主题包括：
1）$batch wit GET，POST&PUT
2）$batch with$filter
3）变更集处理–默认行为
4）变更集处理–延迟处理
5）比较默认与延迟
6）使用内容ID
环境是：
1）Netweaver7.4 EHP7 GWFND 740 SPS 22
2）邮递员客户端
采用的Odata模型为物料，与工厂对应
以下为Odata模型：
Odata模型
导航与关联
准备邮递员客户端
获取X-CSRF-TOKEN
请求主体：注意，如果没有"接受"，个人用云服务器，结果将以xml
获取请求
响应正文：
GET response
结果详情：
json details
json details
在$batch中的这些取数操作默认是并行处理的。为特定服务启用/禁用并行化的设置可以通过/IWBEP/CONF\u service
启用/禁用并行化
从/IWFND/MAINT\u service通过以下方式进行：service implementation->click configuration
Request:
GET with navigation
Response:
GET Response with navigation
json的详细信息结果：
json详细信息
请求：按"Created\u On"日期检索物料
使用$filter获取
其余查询选项与平时基本相同。让我们转到后期操作
在我们进入后期操作之前，是时候引入变更集了。根据SAP，$批处理请求由一系列有序的检索操作和/或更改集组成。
1）更改集是由一个或多个插入、更新或删除操作组成的无序组。检索操作不是一个更改集。
2）每个更改集都被视为单独的LUW，确保"全部"或"无"事务行为
如果有2个更改集，小程序建站，其中包含一些操作，则意味着处理2个LUW。使用$batch和changesets时，软件企业条件，提交和回滚由GW框架完成。下面是一些更改集操作的示例。
示例：包含一个POST操作的更改集
更改集示例
下面的$batch请求包含一个包含一个操作的更改集。
请求：
包含一个POST操作的更改集
响应：
POST Response
内部的更改集由2个API方法处理：-
CHANGESET\u BEGIN–默认情况下，每个变更集只允许1个操作
变更集结束–此处完成修改更新。框架在这个方法的末尾发出提交工作
请求主体：变更集C01有2个POST操作
变更集C01
变更集C01
响应：一个变更集中不允许有多个操作
不允许有多个操作
为了有多个操作，淘客大玩家，需要多个更改集
以下$batch请求包含：
更改集C01–1 POST operation.
更改集C02–1 POST operation.
记住每个更改集将被视为一个单独的LUW.
请求主体：
更改集C01 POST
更改集C02 POST
响应：
深插入POST响应
深插入POST响应
假设其中一个变更集被中止，这不会影响另一个变更集。
下面的$batch request包含两个变更集。其中一个肯定会失败。
更改集C01–LUW将因输入错误而出错
更改集C02–此LUW将成功
请求主体：
操作中值错误的更改集
操作成功的更改集
响应：
响应更改集C01和C02
每个更改集允许一个操作。这是默认行为。
要在更改集中处理多个操作，必须更改默认行为。这是使用延迟模式实现的。它也被称为延迟处理。
我们如何做到这一点？我们重新定义了后端数据提供程序的这些方法
DPC Change set methods
，因此本质上我们使用defer mode
1）通过实现CHANGESET\u BEGIN来设置defer mode='X'。这表明后端数据提供程序能够同时处理多个操作。
2）后端数据提供程序将使用新方法CHANGESET\u process处理多个操作。此方法收集所有更新和修改。确保在LUW中没有调用commit来遵守ALL or Nothing原则。
3）在变更集的末尾，云主机云服务器，调用CHANGESET\u end方法。框架在这里发布提交工作来执行数据库更新。
引入延迟模式处理，通过处理更改集中的多个操作来实现性能。
