通过这个博客，我想分享一些我在Gateway项目中遇到的分页方面的问题。

是只显示总记录列表中选定记录的过程。典型的例子是我们的文字处理器"microsoftword"，它内部有分页符文件底页仅按需显示。我试图从网关的角度分析分页以及对性能的影响

作为初始步骤，云服务器平台，我设置了一些数据

我有两个表，一个是雇员表，私人云服务器，另一个是雇员表的文本表

雇员表

雇员文本表

我还为英语和德语保留了一些虚拟值。。请原谅我的语言错误。

员工表格条目

员工文本表格条目

我们有两种分页方式

这里客户称为快照。客户机决定要加载的记录数。这并不意味着客户机从后端获取所有记录，将其缓冲在客户机中，并根据用户请求显示记录（向下拖动）。

我在实现这种分页的项目中见过，其中从后端获取整个记录。然后在网关层过滤记录。这是UI应用程序性能受到的最严重影响。在标准BAPI的情况下，也可能发生这种情况，因为在标准BAPI中，没有限制最大记录数的选项（没有iv\u max参数）。唯一的选择是将筛选条件应用于记录集。

我们将尝试通过创建一个FM API来模拟这种"不太好的方法"，该API从上述表中获取所有记录

在这种情况下，FM的接口中没有iv_max或upto参数。

我们将尝试将FM映射到实体并从URL.

如您所知，在本例中，淘客助手，将自动为该查询生成DPC类代码。如果您查看了相应的实体，请获取\u ENTITYSET方法。这个正在从数据库获取所有记录后进行分页。

如果您还有多个排序参数要处理，情况会变得更糟。在这里，您应该注意排序和分页的顺序。先排序，然后分页，网建站，否则你会变得很奇怪结果。而且框架不会自动处理排序部分方法。所以呢如果我在GW client

1/sap/opu/odata/sap/ZARS\u PAGE\u SRV/EmployeeSet中运行以下URL？$skip=2&$top=2

我得到了正确的结果（即使性能不好）

2/sap/opu/odata/sap/ZARS\PAGE\u SRV/EmployeeSet？$skip=2&$top=2&$orderby=Id desc

这仍然会产生相同的结果…

您需要像下面的博客中提到的那样显式处理排序。

SAP GW–为Cust EXT类实现更好的orderby

我正在复制这段代码

PS:it顺序（来自io技术请求上下文），它在blog包含网关属性的ABAP字段名。在大多数情况下，它与abap后端API结果字段不同。

例如，我已将GW property Id的abap字段名称更改为EMPLOYEEID。

这将触发DPC代码的相应更改

因此在这种情况下，如果我们必须处理排序和分页。然后您需要执行以下步骤

1循环通过后端内部表来填充et\u entityset（id EmployeeId）映射

2传递et\u entityset到sorting utility method（如博客中所述）来获取排序后的表

3使用lv\u skip和lv\u top参数进行分页

示例代码如下

这里我们看到很多执行不必要的循环以获得正确的结果。为了避免这种循环，我们有另一种方法…是的，你猜对了，将分页推到后端。这种方法我将在下一部分介绍

这里我们将skip和top参数传递到后端FM。因此，我们只从后端选择（几乎）所需的记录。

如果我们说skip 2和top 4，则表示来自3的记录第一步我们继续，改变后端API接口

现在我们改变源代码来处理分页

这里我选择带有"upto"子句的记录，并删除所有索引等于或小于lvèu skip的记录。我同意这不是最有效的分页方法。但是我们不得不接受$skip和$top在opensqlselect中直接不受支持的情况。

AMDP（Abap托管数据库过程）有一些解决方法，它们支持LIMIT（top）和OFFSET（skip）。但它不支持动态价值观。另一个方法是使用ADBC动态本机sql，但这也有其自身的缺点。

现在我们需要重新定义DPC\u EXT GET\u ENTITYSET方法来集成这个调用……

是时候测试代码了。我们前往GW客户端并运行以下URL

/sap/opu/odata/sap/ZARS\u PAGE\u SRV/EmployeeSet？$skip=2&$top=3

正如您在这里看到的，我们得到了正确的结果

在这里，我试图解释一种高效（几乎）的客户端分页方法。在我的下一篇博客中，移动物联网卡，我将尝试介绍服务器端分页和CDS-views/AMDPs分页。请让我知道你对博客的评论