WorkFront/AtTask API $$ TODAYe + 6m缺陷？

的workfront API沒有返回相同的結果。我們的網絡報告：

論workfront我們的web前端的一個報告具有$$TODAYbw到$$TODAYe+6m日期範圍和它返回約5〜50行。

我想在這樣的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

它幾乎沒有返回任何結果相同的查詢。請注意0一行。如果我將其更改爲=$$TODAY+6m而沒有結束日期修飾符，則API返回〜500行。

我經歷了每個過濾條件，它只是出現錯誤的allocationDate範圍。我發現日期修飾符爲this resource，其中沒有e+6m示例，但它適用於我們的Web前端報告。

API是有缺陷的還是網絡報告在後臺做了額外的事情？

來源

2017-06-02 Zorgarath

我沒有針對您的問題的確切解決方案，但是我可以確認API解析通配符時遇到了一些難題，例如您正在嘗試使用，並且它們並不總是按照我們的預期方式出現。此外，API不會像文本模式報告那樣解析事件，因此後者看起來很棒的查詢可能會在前者中返回不同的內容。

如果我可能會提出一個不同的解決方案，因爲您已經在Workfront之外對此進行了編碼，那麼我建議您只需自行執行日期計算，並將明確的日期時間對象傳遞給Workfront，而不允許它使用自己的邏輯。我知道這並不回答「什麼是查詢將完全返回我想要的」的問題，但它應該給你正確的最終結果。

爲了什麼是值得的，我花了大約15分鐘試圖得到一個工作在我的最終的例子，我放棄了它不斷返回應該超出我自己的日期範圍的值。

來源

2017-06-05 15:31:09

感謝您的確認。解決方法與您的建議一樣，讓應用程序計算出日期時間，然後將其傳遞給API，但它確實將Web報告轉換爲自定義程序更乏味。 – Zorgarath

如果API返回了從請求中解析出的參數列表，那也是很有用的。這樣我們可以看到它正確添加了哪些值。 – Zorgarath

我同意你的第二條評論。我試圖看看一些返回的時間戳來解析它在做什麼，但就像我說我很快就對它感到惱火。由於您已經構建了一些查詢，因此您處於更困難的位置，但是如果日期時間查詢是唯一棘手的問題，那麼將這些少數項目轉換爲代碼內解決方案不應該是世界上最糟糕的事情。也許別人會過來處理這種挫折，並有更多相關的建議。您也可以嘗試官方的Workfront論壇。 –

WorkFront/AtTask API $$ TODAYe + 6m缺陷？

回答

相關問題