当前位置:主页 > 云计算服务 >

华为云_异常生物见闻录百度云_新用户

今天我试图向我的一个SAP NetWeaver网关服务发出如下请求:

:/SAP/opu/odata//?%21deltatoken=%27token%27

但是当我看到响应时,我想知道为什么我的服务的delta机制不起作用。所以我开始调试请求,我注意到在我的数据提供程序类'io\u tech\u request\u context->get\u deltatoken()'的方法'/iwbep/if\u mgw\u appl\u srv\u runtime~get\u entityset'中,返回了一个空的deltatoken('rv\u deltatoken'是initial)。

首先我认为我犯了一个错误,不允许转义URL查询参数名称,软件企业条件,但当我开始研究时,淘客公众号系统,我发现了一个关于github问题的有用答案,它指向IETF的RFC(征求意见)3986,名为"统一资源标识符(URI):通用语法"。本RFC第2.2节指出:

由于SAP Gateway正式使用/支持OData 2.0版协议,OData 2.0版基于HTTP,好评返现怎么操作,SAP NetWeaver Gateway还必须根据HTTP尊重和实施IETF RFC。相反,现在不可能使用正确编码的OData系统查询选项(URL查询参数),例如%24top($top)或%24skip($skip)。%21德尔塔托肯(!deltatoken)。

我现在能想到的解决这个问题的最好方法(直到SAP有希望解决这个问题!)是在类`/IWFND/CL\u SODATA\u PROCESSOR`中的私有方法`INIT\u REQUEST`的末尾进行以下增强:

现在您只需要添加所有其他需要解析的参数名,或者为此提出一个通用实现。不需要通用方法,因为只需要`!德尔塔托肯现在受到影响。如果你想知道为什么只有`,请仔细看看我对这篇文章的第一次更新!deltatoken`受到影响。

正如Andre在评论中指出的,并不是所有的系统查询选项都受到影响。我刚刚调试了一些请求,发现这是因为并不是所有的系统查询选项都被同等对待:

在SAP NetWeaver Gateway处理请求的第一次过程中,url查询参数被提取到context对象中,在类"/IWFND/CL\u SODATA\u ROOT\u HANDLER"的方法"DISPATCH"的起始行167:

现在"io\u context"的属性"mt\u parameter"如下:

后面在类"/IWCOR/CL\u DS\u HDLR\u ROOT"的方法"DISPATCH"的起始行43:

现在"io\u context"的属性"mt\u parameter"如下:

下面的代码行处理正在进行,然后在方法`/IWCOR/IF\U DS\U PROC\U ENTITY\U SET~READ`in class`/IWFND/CL\U SODATA\U PROCESSOR`的起始行63中,个人大数据,调用了我昨天在原始帖子中提到的方法` INIT\u REQUEST`:

查找堆栈跟踪变量` iv\u skip`,` iv\u top`,…使用存储在"io\u context"c"mt\u parameter"表中的"/IWCOR/CL\u DS\u URI"实例的相应属性进行填充。因为交给`/IWCOR/CL\u DS\u URI\u FACADE`(在`/IWCOR/CL\u DS\u URI`的子类`/mt\u parameters`中实际引用的类)的构造函数的参数被正确解码,构造函数可以将它们检测为系统查询选项,并将值存储在其相应的属性中。

现在我们查看class`/IWFND/CL\u SODATA\u PROCESSOR`中的方法`INIT\u REQUEST`是否有任何代码访问存储在`mt\u parameters`的`IWFND/query\u parameters`中的仍然编码的参数(注意:我添加了注释)包括在方法中可以找到代码片段的行号):

因此,如果以下四个参数的编码表示与解码表示不同,则无法识别:

现在我们可以清楚地看到为什么只有参数`!德尔塔托肯受到影响。这跟它用的是''一点关系都没有!,而不是使用"$"的其他系统查询选项。这只是一个巧合

我会将"deltatoken"作为变量添加到"/IWCOR/CL\u DS\u URI"中,后者在对象创建过程中从解码参数中提取。然后将import参数"iv\u deltatoken"添加到class`/IWFND/CL\u SODATA\u PROCESSOR`中的方法"INIT\u REQUEST",并在其中使用此变量,而不是使用"READ TABLE"实现我自己的解析。

我不会将"io\u context"的"mt\u parameter"的"IWFND/QUERY\u PARAMETERS"的值从编码参数更改为解码参数不能肯定地说,这不会造成副作用,在其他SAP编码或现有的客户编码!

注意:所有行号都是在SAP\U GWFND 740 SPS 09上获取的

嗨,Manfred,

我很快检查了行为,发现似乎只有编码"!"的问题在URL中使用deltatoken,而"'"的编码工作正常。另外,在正常的filter语句中对"$"符号的编码也起作用。

我使用博客中描述的服务测试了以下语句如何在SAP NetWeaver Gateway中实现基本的增量查询支持

/SAP/opu/odata/SAP/ZPRODUCT\ U SRV/ProductSet\ U DQ?%21deltatoken='005056B22F131EE4B8E4B82C6A6B1559\u 20150415041326'

-->不工作

/sap/opu/odata/sap/ZPRODUCT\u SRV/ProductSet\u DQ?!deltatoken=%27005056B22F131EE4B8E4B82C6A6B1559\U 20150415041326%27

-->是否工作

/sap/opu/odata/sap/ZPRODUCT\U SRV/ProductSet?%24filter=Price eq 1249.0000

-->也能正常工作

所以您发现在一个(特殊)情况下编码不能正常工作

所以这似乎是一个应该修复的错误,而不是正确编码的URL参数的问题。

致以最良好的问候,

Andre

嗨Andre,

感谢您的测试!我对此进行了更深入的研究,改进了博客文章的标题,并更新了我的文章的更多细节

我们刚刚发布了以下

SAP note 2188358-"处理网关URI中的$编码"

作为对这个问题的修复

,服务器云

猜你喜欢

微信公众号