0

Workfront API 返回的结果与我们的网络报告不同：

在我们工作区的 Web 前端，其中一份报告的日期范围从$$TODAYbw到$$TODAYe+6m，它返回了大约 500 行。

我像这样在 API 上尝试了相同的查询（格式化以便于阅读）

/v7.0/RSALLO/search
?fields=DE:project:Probability,allocationDate,scheduledHours,project:name,project:status,roleID,project:status,role:name
&allocationDate_Mod=between
&allocationDate=$$TODAYbw
&allocationDate_Range=$$TODAYe+6m
&AND:0:project:status_Mod=notin
&AND:0:project:status=CPL
&AND:0:project:status=DED
&AND:0:project:status=REJ
&AND:0:project:status=UZF
&AND:0:project:status=IDA
&AND:0:roleID_Mod=in
&AND:0:roleID=55cb58b8001cc9bc1bd9767e080f6c10
&AND:0:roleID=55cb58b8001cc9bd9fc0f8b03a581493
&AND:0:roleID=55cb58b8001cc9bfaa01243cd6024b6d
&AND:0:roleID=55cb58b8001cc9c0afa399dece405efd
&$$LIMIT=1000

几乎没有返回任何结果。注意&allocationDate_Range=$$TODAYe+6m线。如果我将其更改为=$$TODAY+6m不带结束日修饰符的读取，API 将返回约 500 行。

我检查了每个过滤条件，只有 allocationDate 范围出了问题。我为日期修饰符找到了这个资源，其中没有e+6m示例，但它适用于我们的 Web 前端报告。

API 是否存在缺陷，或者 Web 报告是否在后台执行了额外操作？

4

1 回答 1

1

对于您的问题，我没有确切的解决方案，但我可以确认 API 确实在解析通配符时遇到了一些困难，就像您尝试使用的那样，而且它们并不总是以我们期望的方式出现。此外，API 解析事物的方式与文本模式报告不同，因此在后者中看起来不错的查询可能会返回与前者不同的东西。

如果我可以提出不同的解决方案，因为您已经在 Workfront 之外对其进行了编码，那么我建议您只需自己执行日期计算并将显式日期时间对象传递给 Workfront，而不是允许它使用自己的逻辑。我知道这并不能回答“什么是可以准确返回我想要的查询”的问题，但它应该为您提供正确的最终结果。

对于它的价值，我花了大约 15 分钟试图让一个例子在我的最后工作，我放弃了，因为它一直返回应该超出我自己日期范围的值。

于 2017-06-05T15:31:09.977 回答