OData和sapgateway的主要重点是为数据消费提供一个轻薄的协议。在大多数用例中，创建操作只对单个实体执行。但是，也存在需要同时创建多个实体的有效场景。

例如，云服务器租用价格，我们将创建一个新的服务"ZGWSAMPLE\u MASSINSERT\u SRV"，作为现有"GWSample\u Basic"服务的重新定义，该服务作为SAP Gateway Foundation（组件SAP\u GWFND）NW 7.40 SP09及更高版本的一部分提供。此服务使用EPM数据模型，大数据与云计算，我们将为现有业务伙伴创建新产品。假设我们需要用一个调用创建100个新产品，最简单的方法是使用$batch请求将所有100个POST调用合并到一个服务调用中：

在URI的末尾添加sap statistics=true选项提供了有关不同sap网关相关层需要多少处理时间的更多详细信息。下表显示了创建1到2500个产品的运行时间（以毫秒为单位）：

让我们看看以这种方式创建100个产品时在幕后发生了什么：

–在解析请求负载时反序列化JSON负载100次

–在SAP Gateway Hub中处理单个请求100次系统

–在后端系统中进行100次单请求处理

–100次序列化JSON负载以生成响应负载

所有这些步骤都是必要的，因为每个变更集操作都必须单独处理！

这一点在我们查看SAP网关性能跟踪（事务：/n/iwfnd/traces）后变得更加明显：

在本例中，我们已经创建了10个新产品，可以看到每个新产品都会调用CREATE_ENTITY方法。

下表显示，数据分析平台，每个服务调用的总体运行时大约有40%–45%是与SAP网关相关的开销。假设与应用程序相关的编码已经优化，物联网系统，进一步提高性能的关键因素是最小化与SAP网关相关的开销。

这可以通过建模一个额外的实体集来实现，该实体集将接收产品列表并通过深度插入功能创建产品。因此，我们将创建一个名为"ProductMassInsert"的新实体，其相应的实体集为"ProductMassInsertSet"。此外，我们还需要一个由主体实体"ProductMassInsert"和从属实体"Product"以及基数1:M定义的关联。该关联用于创建deep insert功能，并将命名为"ToProducts"。我们现在需要做的就是在*DPC\u EXT类中重新定义CREATE\u DEEP\u ENTITY方法来处理产品的创建解析请求有效负载时仅对JSON有效负载进行1次反序列化

–在SAP网关集线器上仅对单个请求进行1次处理

–在后端系统上仅对单个请求进行1次处理

–仅对JSON有效负载进行1次序列化以生成响应有效负载

正如预期的那样，应用程序运行时在后端类似，因为编码尚未进一步优化。

在给定的场景中，大数据应用技术，有效的性能提升是SAP网关集线器的性能提高约90%，后端系统的性能提高约90%，已经从100个实体开始。由于性能在非优化场景中遵循线性模式，因此它甚至会随着要创建的实体数量的增加而提高。这不会对后端应用程序本身的性能产生任何影响，但重要的是将SAP网关开销降至最低。

再次查看SAP网关性能跟踪（事务：/n/iwfnd/traces），我们可以看到，无论使用这种深插入方法创建多少产品，CREATE\u deep\u实体方法只调用一次。

在给定的示例中，我们可以将CREATE场景中的总体运行时减少50%！！！

值得一读：关于SAP Gateway 2.0 SP09的一些新功能的详细信息–对$batch的性能改进（立即更改集/延迟模式更改集）

解决这个问题的方法非常好。很好的博客Tobias Griebe

很好的统计Tobias.

关于解决方案：缺点是我们正在规避OData标准来适应我们。这个类似于使用deep实体进行深度更新（OData不支持）。这样，每个变更集都可以转换为一个深度创建，但我不确定这是否是您的建议。

在这种情况下，我不建议使用Gateway，而是一个简单的REST服务最适合。

嗨，克里希纳，

感谢您的回复。

以上解决方案侧重于SAP网关框架和我们手头的选项/挑战。

我没有将其与简单的REST服务作任何比较，因为它在处理此类请求时可能会更快。ODATA不适用于大规模更改/更新场景，但我在几个项目中也看到类似的事情。所以，如果您仍然想使用SAP网关使用ODATA，这将是一个考虑的选项。