在 SAP Gateway 项目里，创建销售订单时经常会碰到一个很现实的问题。销售订单抬头还没有创建成功之前，后台分配的SalesOrderID根本不存在，可销售订单行项目的创建请求又必须知道自己属于哪一张销售订单。如果按照普通 REST 调用思路处理，流程很自然。客户端先调用一次POST SalesOrderSet，等服务器返回新生成的销售订单号，例如0500000123，客户端解析响应，再发第二个请求创建销售订单行项目。这种方案当然能工作，但它把一个业务动作拆成了两次 HTTP 往返，而且两个请求之间形成了很强的客户端状态依赖。更麻烦的是，如果销售订单创建成功，而行项目创建失败，客户端还需要决定是否删除已经创建的销售订单。原本属于一个业务事务的操作，被拆散成了多个网络事务。OData 的$batch与change set正是为这类问题准备的。SAP Gateway Foundation 支持把多个 OData 操作封装在一次$batchHTTP 请求里。$batch外层使用multipart/mixed，一个 batch 中既可以出现查询请求，也可以包含一个或者多个change set。change set则专门用来组织数据修改请求，并作为一个原子工作单元处理。OData 协议要求 change set 中的修改要么全部成功，要么全部不生效。真正棘手的地方不在批量发送，而在操作之间的依赖关系。 从 Content-ID 到 CHANGESET_PROCESS，拆解 SAP Gateway $batch 中的跨操作依赖与事务处理
在 SAP Gateway 项目里，创建销售订单时经常会碰到一个很现实的问题。销售订单抬头还没有创建成功之前，后台分配的SalesOrderID根本不存在，可销售订单行项目的创建请求又必须知道自己属于哪一张销售订单。如果按照普通 REST 调用思路处理，流程很自然。客户端先调用一次POST SalesOrderSet，等服务器返回新生成的销售订单号，例如0500000123，客户端解析响应，再发第二个请求创建销售订单行项目。这种方案当然能工作，但它把一个业务动作拆成了两次 HTTP 往返，而且两个请求之间形成了很强的客户端状态依赖。更麻烦的是，如果销售订单创建成功，而行项目创建失败，客户端还需要决定是否删除已经创建的销售订单。原本属于一个业务事务的操作，被拆散成了多个网络事务。OData 的$batch与change set正是为这类问题准备的。SAP Gateway Foundation 支持把多个 OData 操作封装在一次$batchHTTP 请求里。$batch外层使用multipart/mixed，一个 batch 中既可以出现查询请求，也可以包含一个或者多个change set。change set则专门用来组织数据修改请求，并作为一个原子工作单元处理。OData 协议要求 change set 中的修改要么全部成功，要么全部不生效。真正棘手的地方不在批量发送，而在操作之间的依赖关系。 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
