次の方法で共有

Project Online でユーザー設定フィールドを一括更新し、ワークフローからプロジェクト サイトを作成する

  • [アーティクル]

お客様がProject Onlineを最大限に活用し、サービスの拡張性と柔軟性を向上させるために、Project Onlineアプリとワークフローで使用できる 2 つのメソッドをクライアント側オブジェクト モデルに追加しました。

値
UpdateCustomFields
プロジェクトのユーザー設定フィールドを一括更新します。 Project Onlineのみ。 REST API でのみ使用できます。
CreateProjectSite
プロジェクト サイトを作成します。 Project Onlineのみ。 REST API、マネージド クライアント オブジェクト モデル、JavaScript クライアント オブジェクト モデルで使用できます。

これらの方法は、柔軟性を高めるだけでなく、ワークフローでプロジェクトを保存および発行するときにパフォーマンスが大幅に向上します。 この記事では、REST API のメソッドを使用する方法について説明し、カスタム フィールドを一括更新するワークフローと Project サイトを作成するワークフローを作成する手順について説明します。

注:

SharePoint 2013 ワークフローから REST API を呼び出す方法の詳細については、「SharePoint 2013 REST インターフェイスの概要と使用」および「SharePoint Designer ワークフローから SharePoint 2013 Rest API を呼び出す」を参照してください。

ワークフローからプロジェクトのユーザー設定フィールドを一括更新する

以前は、ワークフローで更新できるユーザー設定フィールドは一度に 1 つだけでした。 プロジェクトのユーザー設定フィールドを一度に 1 つずつ更新すると、ユーザーがプロジェクト詳細ページ間を切り替えたときにエンド ユーザー エクスペリエンスが低下する可能性があります。 各更新では、 プロジェクト フィールドの設定 アクションを使用して個別のサーバー要求が必要であり、待機時間が長く帯域幅の低いネットワークで複数のカスタム フィールドを更新すると、簡単ではないオーバーヘッドが発生しました。 この問題を解決するために、カスタム フィールドを一括更新できる UpdateCustomFields メソッドを REST API に追加しました。 UpdateCustomFields を使用するには、更新するすべてのユーザー設定フィールドの名前と値を含むディクショナリを渡します。

REST メソッドは、次のエンドポイントにあります。

https://<site-url>/_api/ProjectServer/Projects('<guid>')/Draft/UpdateCustomFields()

注:

例のプレースホルダーを<site-url>、Project Web App (PWA) サイトの URL に置き換え、プレースホルダーを<guid>プロジェクト UID に置き換えます。

このセクションでは、プロジェクトのカスタム フィールドを一括更新するワークフローを作成する方法について説明します。 ワークフローは、次の大まかな手順に従います。

  • 更新するプロジェクトがチェックインされるまで待ちます。

  • プロジェクトのすべてのユーザー設定フィールドの更新を定義するデータ セットを構築します。

  • プロジェクトをチェックアウトします。

  • UpdateCustomFields を呼び出して、ユーザー設定フィールドの更新をプロジェクトに適用します。

  • ワークフロー履歴の一覧に関連情報をログに記録します (必要な場合)。

  • プロジェクトを発行します。

  • プロジェクトをチェックインします。

最終的なエンドツーエンドのワークフローは次のようになります。

エンドツーエンド ワークフロー エンドツーエンド

カスタム フィールドを一括更新するワークフローを作成するには

  1. 省略可能です。 プロジェクトの完全な URL を、ワークフロー全体で使用できる変数に格納します。

    プロジェクトの URL を変数に格納する する

  2. [プロジェクト イベントの待機] アクションをワークフローに追加し、[プロジェクトがチェックインされたとき] イベントを選択します。

    [プロジェクトがチェックインされるまで

  3. Build dictionary アクションを使用して requestHeader ディクショナリを作成します。 このワークフロー内のすべての Web サービス呼び出しに同じ要求ヘッダーを使用します。

    requestHeader ディクショナリを

  4. 次の 2 つの項目をディクショナリに追加します。

    名前 型 値
    Accept
    		 String
    		 application/json;odata=verbose
    Content-Type
    		 文字列
    		 application/json;odata=verbose

    Accept ヘッダーの追加 Accept

  5. Build dictionary アクションを使用して requestBody ディクショナリを作成します。 このディクショナリには、適用するすべてのフィールド更新が格納されます。

    各ユーザー設定フィールドの更新には、フィールドの (1) メタデータ型、(2) キー、(3) 値、および (4) 値型の 4 つの行が必要です。

    • __metadata/type フィールドのメタデータ型。 このレコードは常に同じであり、次の値を使用します。

      • 名前: customFieldDictionary(i)/__metadata/type ( i は辞書内の各ユーザー設定フィールドのインデックスであり、0 以降)

      • 型:String

      • 値: SP。KeyValue

      ユーザー設定フィールドの更新の定義

    • キー ユーザー設定フィールドの内部名の形式: Custom_ce23fbf43fa0e411941000155d3c8201

      ユーザー設定フィールドの内部名は、 InternalName エンドポイントに移動することで確認できます。 https://<site-url>/_api/ProjectServer/CustomFields('<guid>')/InternalName

      カスタム フィールドを手動で作成した場合、値はサイト間で異なります。 ワークフローを複数のサイトで再利用する場合は、ユーザー設定フィールド ID が正しいことを確認してください。

    • 値 ユーザー設定フィールドに割り当てる値。 参照テーブルにリンクされているユーザー設定フィールドの場合は、実際の参照テーブルの値ではなく、参照テーブル エントリの内部名を使用する必要があります。

      ルックアップ テーブル エントリの内部名は、次のエンドポイントにあります。 https://<site-url>/_api/ProjectServer/CustomFields('<guid>')/LookupEntries('<guid>')/InternalName

      複数の値を受け入れるように設定されたルックアップ テーブルのユーザー設定フィールドがある場合は、 を使用 ;# して値を連結します (下の辞書の例に示すように)。

    • Valuetype 更新するユーザー設定フィールドの型。

      • [テキスト]、[期間]、[フラグ]、[LookupTable] の各フィールドには、Edm.String を使用します

      • [数値] フィールドには、Edm.Int32、Edm.Double、またはその他の OData で受け入れられる数値型を使用します

      • [日付] フィールドには、Edm.DateTime を使用します

      次の辞書例では、3 つのユーザー設定フィールドの更新を定義します。 1 つ目は複数値参照テーブルのユーザー設定フィールド用、2 つ目は数値フィールド用、3 番目は日付フィールド用です。 customFieldDictionary インデックスがどのようにインクリメントされるかに注意してください。

      注:

      これらの値は、説明のみを目的としています。 使用するキーと値のペアは、PWA データによって異なります。

      名前 型 値
      customFieldDictionary(0)/__metadata/type
      		 String
      		 Sp。KeyValue
      customFieldDictionary(0)/Key
      		 文字列
      		 Custom_ce23fbf43fa0e411941000155d3c8201
      customFieldDictionary(0)/Value
      		 文字列
      		 Entry_b9a2fd69279de411940f00155d3c8201;#Entry_baa2fd69279de411940f00155d3c8201
      customFieldDictionary(0)/ValueType
      		 文字列
      		 Edm.String
      customFieldDictionary(1)/__metadata/type
      		 String
      		 Sp。KeyValue
      customFieldDictionary(1)/Key
      		 String
      		 Custom_c7f114c97098e411940f00155d3c8201
      customFieldDictionary(1)/Value
      		 String
      		 90.5
      customFieldDictionary(1)/ValueType
      		 String
      		 Edm.Double
      customFieldDictionary(2)/__metadata/type
      		 String
      		 Sp。KeyValue
      customFieldDictionary(2)/Key
      		 String
      		 Custom_c6fb67e0b9a1e411941000155d3c8201
      customFieldDictionary(2)/Value
      		 String
      		 2015-04-01T00:00:00
      customFieldDictionary(2)/ValueType
      		 String
      		 Edm.DateTime

      ユーザー設定フィールドの更新を定義する

  6. HTTP Web サービス呼び出しアクションを追加して、プロジェクトをチェックします。

    Checkout メソッドを呼び

  7. Web サービス呼び出しのプロパティを編集して、要求ヘッダーを指定します。 [ プロパティ ] ダイアログ ボックスを開くには、アクションを右クリックし、[プロパティ] を選択 します。

    Web サービス呼び出しプロパティで要求ヘッダーする

  8. UpdateCustomFields メソッドを呼び出す HTTP Web サービス呼び出しアクションを追加します。

    HTTP Web サービス呼び出しアクションの作成

    Web サービス URL の /Draft/ セグメントをメモします。 完全な URL は次のようになります。 https://<site-url>/_api/ProjectServer/Projects('<guid>')/Draft/UpdateCustomFields()

    UpdateCustomFields メソッドを

  9. Web サービス呼び出しのプロパティを編集して、 RequestHeader パラメーターと RequestContent パラメーターを作成したディクショナリにバインドします。 ResponseContent を格納する新しい変数を作成することもできます。

    ディクショナリを要求ヘッダーとコンテンツにバインドする 要求ヘッダーする

  10. 省略可能です。 応答ディクショナリから読み取り、キュー ジョブの状態をチェックし、ワークフロー履歴リストに情報をログに記録します。

    ログ記録の設定

  11. 発行エンドポイントに Web サービス呼び出しを追加して、プロジェクトを発行します。 常に同じ要求ヘッダーを使用します。

    Publish メソッドを呼び出す

    Web サービス呼び出しの発行のプロパティ Web サービス呼び出し

  12. Checkin エンドポイントに最終的な Web サービス呼び出しを追加して、プロジェクトをチェックします。

    Checkin メソッドを呼

    Checkin Web サービス呼び出しの

ワークフローからプロジェクト サイトを作成する

すべてのプロジェクトには、チーム メンバーが共同作業、ドキュメントの共有、問題の発生などを行うことができる独自の専用の SharePoint サイトを用意できます。 以前は、サイトを最初に発行するか、Project Professionalのプロジェクト マネージャーまたは PWA 設定の管理者が手動で作成するか、無効にすることもできます。

プロジェクト サイトを作成するタイミングを選択できるように、 CreateProjectSite メソッドが追加されました。 これは、プロジェクト提案が最初の発行時ではなく、事前に定義されたワークフローの特定のステージに達したときにサイトを自動的に作成する組織に特に役立ちます。 プロジェクト サイトの作成を延期すると、プロジェクトの作成のパフォーマンスが大幅に向上します。

前提 条件：CreateProjectSite を使用する前に、[PWA 設定] [接続済み SharePoint> サイトの設定] でプロジェクト サイトの作成に対して [ユーザーの選択を許可する] 設定>を設定する必要があります。

PWA 設定の [ユーザーの選択を許可する] の

プロジェクト サイトを作成するワークフローを作成するには

  1. 既存のワークフローを作成または編集し、プロジェクト サイトを作成する手順を選択します。

  2. Build dictionary アクションを使用して requestHeader ディクショナリを作成します。

    requestHeader ディクショナリを

  3. 次の 2 つの項目をディクショナリに追加します。

    名前 型 値
    Accept
    		 String
    		 application/json;odata=verbose
    Content-Type
    		 文字列
    		 application/json;odata=verbose

    Accept ヘッダーの追加 Accept

  4. HTTP Web サービスの呼び出しアクションを追加します。 POST を使用するように要求の種類を変更し、次の形式を使用して URL を設定します。

    https://<site-url>/_api/ProjectServer/Projects('<guid>')/CreateProjectSite('New web name')

    CreateProjectSite エンドポイント URI の

    Project サイトの名前を文字列として CreateProjectSite メソッドに渡します。 サイト名としてプロジェクト名を使用するには、空の文字列を渡します。 次に作成するプロジェクト サイトが機能するように、必ず一意の名前を使用してください。

  5. Web サービス呼び出しのプロパティを編集して、 RequestHeader パラメーターを作成したディクショナリにバインドします。

    要求へのディクショナリのバインド 要求

関連項目