更新プログラム: SPD ワークフローをサイト定義に埋め込む方法を研究してきた. この MSDN フォーラム チェーンはいくつかの興味深い情報. 決定的ではないです。, しかし、ジャングルのパスを指す.
私はこのポストは少し変わり者」動作を与えています。" 以来、私はそれから結論を描画の少し不信感につながる. SPD ワークフローは、します。 … 気質.
人々 が求めている多くの場合 / 疑問に思う / SPD ワークフローを 1 つの場所から別に移動に. 今日, これらの手順に従ってし、これらの観測を行った:
- ドキュメント ライブラリに接続されているサイトで SharePoint デザイナーを使用してワークフローを作成.
- 関連付けられているドキュメント ライブラリは既にいくつかの文書を収容.
- 私は、サイト テンプレートとして保存します。.
- テンプレートとしてサイトを保存した場合, 同様のコンテンツを保存.
- そのテンプレートを使用して、同じサイト コレクションで新しいサイトを作成しました。.
この時点で, ワークフローを実行してみました. それは速やかにログ メッセージ自体を終了, 「開始時に失敗」.
これを期待. SPD ワークフローを移動するとき低期待している私.
私は続けた:
- SharePoint Designer で、サイトを開設.
- ワークフローでピークを持っていた. それが正常に見えた.
- 「完了」をクリック.
- ワークフローを走った.
今度こそです, それは見事に働きました.
このワークフロー使用"データ収集ユーザーからを追加します" フードの下で比較的複雑なアクションはアクション.
一応結論づけてのプロセス"仕上げ" 原因に正しく SPD ワークフローを新しいドキュメント ライブラリに関連付ける SPD ワークフロー. 私も、XOML およびその他の XML アーティファクトが合理的に「ゆるい」を締結します。. ドキュメント ライブラリに超密結合がないです。.
これはどういう意味? それは信頼性が高く、再現性のあるプロセスと仮定すると, 我々 はそれらを移動する使用できます少なくとも 1 つの大まかな方法があります。. かどうかこれが働けば、サイト コレクションの境界を渡るかも知らないより大幅に, 新しいファームの全体 (例えば. prod にステージに dev).
これを読んでいるし、傾向がある場合, コメントを投稿してくださいまたは 私にメールします。 SharePoint Designer の移行体験談. 私は喜んで従って提供される任意の洞察力を持つこの投稿を更新します.
</終了>
