3

参考までに、ルックアップの更新を適切に設定する方法を認識しており、これを正しく行ったことは99%肯定的です。

アイテムが変更されたときにワークフローが自動的に開始するように設定すると、完全に機能するため、これを知っています。しかし、この設定を変更して新しいアイテムの作成時に自動的に開始されるようにすると、ワークフローがキャンセルされ、「強制に失敗しました:入力ルックアップデータを要求されたタイプに変換できません」というメッセージが表示されます。両方のオプションがチェックされている場合、作成は失敗しますが、アイテムのプロパティで[編集]をクリックするだけで、[保存]が機能します。

ワークフローはドキュメントライブラリ上にあり、次のように機能します。

ユーザーは、アップロード後にプロパティの編集フォームのドロップダウンから作業タスクのルックアップを選択し、アイテムを保存します(ドキュメントライブラリに追加します)。次に、ワークフローは、選択された作業タスクルックアップを確認し、作業タスクアイテムが持つアカウントと発効日タイプのルックアップIDを取得し、ドキュメントの同一フィールドを同じ値に設定することを想定しています。

役立つ場合は、ワークフローのコードを次に示します。

If Current Item: Parent Task is not empty
If Current Item: Sub Task is not empty
    Log Both are empty to workflow history list
    Then Set Account to Work Tasks:Account
    The Log Set Account to workflow history list
    Then Set Effective Date and Type to WorkTasks: Effective Date and Type
    The Log Set EffDateType to the workflow history list

これはすべて1つのステップで実行されます。また、アカウントと発効日のタイプのフィールドが正しく設定されているかどうかをテストし、再度設定されていないかどうかをテストするための手順を追加しました。しかし、変更時にワークフローを実行して機能するたびに、最初のステップ(上記の投稿)と追加のチェックログに基づいて、これらのフィールドが不要であるという履歴に常に正しく設定されます。

例として、Tasks:Accountの整数のルックアップは次のように機能するように設定されています。

Date Source: Work Tasks (a list)
Field from Source: Account (a lookup)
Return Field as: Lookup ID (as Integer)

Find the List Item
Field: Title (from the Work Tasks list)
Value: Current Item: Parent Task (Which is a look up of the "Title" 
Field from Work Tasks List, and is set to return the Value as a LookUp Value (As Text))

発効日とタイプの設定はほとんど同じです。

だから誰かが何か洞察を持っていますか?偽装されたステップとして実行し、ワークフローの一時停止を設定し(1分間)、最初から混乱した場合に備えてルックアップタイプを変更してみましたが、最終的には上記のワークフローは機能しますが、「必要なように「新しいアイテムの作成で自動的に開始する」ではなく、「アイテムの変更(編集)で自動的に開始する」。

そうそう、fyi、私はdocLibraryフォームのWorkTaskフィールドとSubTaskフィールドでSPServicesCascadingDropDownを使用していますが、これが私の問題とは何の関係もないと正直に信じています。

アップデート:

私は別の開発者と話をしましたが、彼は、アイテムがルックアップを実行するために必要なIDを作成する前に、ワークフローの実行が速すぎるという問題が原因であると考えています。彼は、ワークフローコードの最上部(If条件の上)に別の「ワークフローの一時停止」を追加して、1分間設定するように指示しました。

その後、正しく機能しました。

欠点は、これをアイテム作成のできるだけ近くでラベル付けすることです。ライブラリのビューは、アカウントと発効日およびタイプに基づくグループ化に依存しているためです。このダウナーに追加するために、Microsoftの一時停止ワークフローでは1分以上しか許可されておらず、これに使用されるタイマーがオフになっていることが多く、その結果、一時停止がそれより長くなります。これまでのところ、すべてのテストは現在、一時停止時に最低2分を示しています。

ファイルを即座に入力するための可能な代替ソリューションは、JavascriptとSPServicesを使用してタスクリストを検索し、アカウントと発効日を取得してから入力することですが、私のJavascriptはそれほど強力ではないため、サポートが必要です。これ。誰か提案があれば、私はそれらをいただければ幸いです。

4

1 に答える 1