2017-06-02 9 views
0

workfront APIは、弊社のWebレポートと同じ結果を返すされていません:レポートのworkfront 1に、当社の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範囲だけです。私は日付修飾子のためにthis resourceを見つけました。その中にはe+6mという例はありませんが、私たちのウェブのフロントエンドのレポートでも動作します。

APIに欠陥があるか、バックグラウンドで余分なことを行うWebレポートですか?

答えて

1

私はあなたの問題の正確な解決策はありませんが、APIが使用しようとしているようにワイルドカードを解析するのに問題があることを確認できます。さらに、APIはテキストモードのレポートと同じ方法で物を解析しないので、後者ではすばらしいクエリは前者では何かを返すことがあります。

私は別のソリューションを提案するかもしれませんが、すでにWorkfrontの外でこれをコーディングしているので、独自の日付計算を実行して明示的なdatetimeオブジェクトをWorkfrontに渡して、論理。私はこれが "私が欲しいものを正確に返すクエリは何ですか?"という質問に答えることはできないが、正しい結果が得られるはずであることは分かっている。

価値があるのは、私は約15分を使って私の終わりに取り組んでいる例を得ようとしていました。

+0

確認していただきありがとうございます。回避策はあなたが提案したように、アプリケーションがdatetimeを把握してAPIに渡すことですが、Webレポートをカスタムプログラムに変換するのが面倒です。 – Zorgarath

+0

APIがリクエストから解析されたパラメータのリストを返した場合にも役立ちます。そのようにして、どの値が正しく追加されたかを確認することができました。 – Zorgarath

+0

私はあなたの2番目のコメントに同意します。私はそれが何をしているのかを解析するために返されたタイムスタンプを見ようとしていましたが、私はそれを素早く迷惑にしていたと言いました。すでにいくつかのクエリが構築されているため、より困難な立場にありますが、datetimeクエリが唯一難しいのであれば、これらの少数のアイテムをコード内のソリューションに変換することは、世界で最悪のものであってはなりません。おそらく、誰かがこの不満を扱った人を連れてくるだろうし、より関連性の高いアドバイスを持っているでしょう。公式のWorkfrontフォーラムも試してみることができます。 –

関連する問題