このブログのエントリの詳細は、「可能性の領域で" エントリ対. コンクリートの情報.

我々 は、手動で開始されるワークフロー プロセスによってサイト コレクションでサイトを作成していく技術のデザインを持っています。. 基本的には, ユーザー データを入力、「初めてのお客様へ" カスタム リストとし、彼らが完了し、データ入力プロセスを検証しているとき, その顧客のサイトを作成する必要があります。.

私は弱い visual studio ワークフローのプログラマだけでなく、宣言型ワークフローの大ファン, SharePoint デザイナーを使用して要件を満たしていたので.

これを詳しく書く予定します。 (うまくいけば、ユーザー グループまたは 2 つの来年に提示), しかし、ここでは、全体的なソリューション:

• SPD と統合するカスタム アクションを作成します。.
• カスタム アクション SPD XML の文字列を渡すと、web サービスを呼び出すことができます。.
• Web サービス カスタム リスト内の行を検索し、カスタム サイト定義を使用して新しいクライアントのデータに従って新しいサイトを作成します.
• Web サービス次カスタム リストに新しいサイトへのリンクなどの情報を更新します。.

他のアプローチと考え, イベント ハンドラーなどに基づいて visual studio ワークフロー. SPD によりエンド ・ ユーザー プロセスをもう少し制御. 付与, このソリューション内の c# コードの多くがあります。, 宣言型ワークフロー内にラップされてしかし, 我々 はサイト作成サービスにフック中宣言型ワークフローの利点のいくつかを得るため.

私たちが今必要なのは、Visual Studioのワークフローのためのように簡単に私たちができる限り自動的にSPDが周りのワークフローに移行するための簡単なツールであると私はいくつかの民族がそこにこの問題に取り組んでいることを理解🙂私たちは本当にガスで調理をすることだろうと私は、彼らが思っていますすぐにそれにいくつかの良い成功.

</終了>

私のブログを購読します。.

私は SharePoint デザイナーのためのカスタムの動作をいくつかの時間を遊んでてきた (ここを参照してください。 いくつかの詳細なもの, 場合は、あなたの興味).

私の現在のプロジェクトで, かなり重い負担をしなければし、関連付けられているビジネス プロセスを管理する宣言型 SPD ワークフローを使用します。.

長い話を短く, これは完全に可能です。. 私は「ヘルパー サービスを呼び出す私の Codeplex プロジェクトを拡張" 今我々 は SPD ワークフローから直接 web サービスを呼び出すことができます。.

ここでは、署名です。:

 パブリック 文字列 ディスパッチャー(
        Guid WebID, // ランタイム環境によって渡される
        Guid SiteID, // ランタイム環境によって渡される
        文字列 ListID, // RTE によって渡される (分からないなぜこのような文字列, GUID ではないです。)
        int ListItemID, // RTE によって渡される.
        文字列 指定します) // SPD で宣言されている、ユーザーによって渡されました。.

これは、我々 が重要なワークフロー情報で得ることができるという事実を活用してください。, サイトのような, リスト ID, など. これはよく独自のカスタム アクションを作成するのに興味があるあなたのそれらのいくつかの場所に記載されています。. アイデアは、ディスパッチの適切な手順をユーザーが指定した XML 文字列を抽出するには. 楽しいもの!

悲しいことに, これは明らかにダウンへの片道切符です。 "リラックスしました。" アンチ パターンの土地, それはレンガの壁を打つよりはましです🙂

アンチ パターンだとわかっていてもそれを行う場合、アンチ パターンは?

近い将来、Codeplex の中これをラップしたいです。. そう私に興味があるなら, 私に突くを与える (電子メール またはコメントを残してください) そして私はそれをやっについてのより多くの熱狂的なことでしょう🙂

</終了>

私のブログを購読します。.

私 5 異なる SharePoint Designer ワークフローを使用して、いくつかのドキュメントの承認を処理するプロジェクトに取り組んでいます. SPD は、ユーザーから「収集データを提供します。" アクションは異なるビット情報のユーザー入力を求めることができますように, 彼らがそれを承認するかどうかなど, いくつかのコメントと多分彼ら他の夜の夕食のためていたものを求める.

フォームが完全に機能. 彼らはコンテンツ タイプとしてタスク リストに関連付けられています。. 彼らは 100% システムが生成しました。. これは自分の強さと弱さ. 既定のフォームに住むなら, 我々 は行ってもいいなら. ただし, SPD がフォームを作成する方法をあまりにも多くの制御を持っていません。. 既定の動作を好きではない場合, それを回避する様々 なトリックに頼る必要があります。 (たとえば, タスクの優先度の設定).

ビューのプロパティを開いたこれらタスク フォーム上のリンクを提供するために必要な (dispform.asxp) 「関連項目の" 新しいウィンドウで. これは関連項目のメタデータへのワンクリック アクセスを提供します. これはどういうことか:

ありがたいことに, 我々 はそれを行うことができます、それは非常にハードではないです。. 大まかに言えば, SPD を起動します。, ワークフロー ファイルを格納するディレクトリに移動し、変更する ASPX ファイルを開く. これらは、ちょうど古典的な XSL 変換命令と itemstyle.xsl と、汚したきたかどうか, 検索または他の XSL のシナリオ, これはあなたのために簡単になります. 実際, 生成されたフォームが次の主要な検索結果 web パーツと比較して容易になるので一般に容易にそれを見つけた (または、 悪夢のような CWQP).

もちろんです, 1 つの大きな落とし穴があります。. SPD のワークフロー エディターがそのファイルを完全に制御を期待してください。. それを変更する場合, SPD は、右の状況の設定、変更を与えるが上書きされます幸せ. どのように悪いこの得ることができる 2 つのクイック テストを行った. 彼らは両方をユーザーから「収集データを使用して、有効な SPD ワークフローを細工した前提と" ステップ.

テスト 1:

• ASPX ファイルを手動で変更します。.
• それをテストします。 (変更が正しく保存され何かを壊していないことを確認します。).
• ワークフローを開き、関連のないアクションの追加 (「歴史にログ」など).
• ワークフローを保存します。.

結果: このケースでは, SPD は、フォームを再作成しません。.

テスト 2:

• 同じことを行う #1 直接を除いて、"データを収集するユーザーから変更します。" アクション.

結果: これは、再スクラッチからフォームを作成されます。, 変更内容を上書き.

最終的な注意事項:

• 少なくとも 2 つの SPD のアクションはこのようなフォームを作成します。: "ユーザーからデータを収集します。" 「項目を割り当てる」と. これらのアクションの両方’ フォームを手動で変更することができます。.
• Dispform.aspx へ私のリンクを生成することができた, このケースでは, 関連項目に関連項目の URL に埋め込まれた ID. それを抽出し、構築することができた、 <href> ワンクリック メタ データ アクセス機能を提供するためにそれに基づく. あなたの URL がこの規則に続くことは考えにくい. 関連項目の ID を取得する他の方法がありますが、私はその橋を渡って持っていなかった, 場合を知らないので、溝の反対側に取得.
• 私はしなかった調査, テンプレート内のファイルのいくつかの種類がある場合は驚いてはないが、 12 レジストリ ハイブを SPD を既定のフォームを生成する方法に影響する変更 (アラート ・ テンプレートを変更できますと同様).

</終了>

私のブログを購読します。!

私はこのようなビジネス シナリオがあります。:

• ユーザーがドキュメントをドキュメント ライブラリにアップロードします。.
• 彼女は、コンテンツの種類を選択し、必要に応じてメタ データを入力. 1 つのメタ データ フィールド フラグです。, 「緊急」.
• これは、SharePoint Designer ワークフローをトリガーは, 他のものの間で, 「収集データから、ユーザーを使用して" アクション.

"ユーザーからデータを収集します。" そのドキュメントの承認を要求するタスク一覧に項目を作成します。.

承認のための緊急の要求を示し、タスク一覧のビューを作成するために必要な.

ソリューション: 言葉「緊急:" これらのタスクのタイトルに.

私は希望優先順位フィールドを直接指定するには. ただし, いくつかの理由のことを行うことができなかった:

1. データを収集するアクションは、タイトル以外の任意のフィールドを更新するメカニズムを提供しません (それらのデータを収集する追加のフィールド).
2. "割り当てを行う項目を" アクションは、同じ問題を抱えて.
3. リストに項目を挿入することは (すなわち. 項目をタスク一覧に直接挿入します。) しかし、このブロックのアクションではなく. つまり、ワークフローはユーザーがタスクを完了するを待たず.

前にいくつかのアプローチを考慮 (ありがたいことに) 私達はちょうど可能性が実現する"緊急を置く" タイトルで.

1. 新しいタスクが作成されるように自体のタスク リストにワークフローを開始します。, それはどういうわけかクロス参照、最初のワークフローを開始ドキュメントに戻る, 緊急のフラグ値を引き出し、必要に応じて優先度を更新.
2. 何かイベント レシーバーと類似しています。. タスクの作成時に, 関連付けられているドキュメントと必要に応じて更新プログラムの優先順位を検索します。.
3. 「リスト アイテムを作成使用して" フィールドの変更を"待機と共にアクション" アクションとイベント レシーバー. リスト アイテムを作成する場合, 私たちは私たちが望むすべてのフィールドを指定できます。. イベント レシーバーを使用して、ユーザー タスクとフィールドの変更を"待機が完了すると、元のアイテムを更新" アクションの条件が満たされ、ワークフローに進むでしょう. (いくつかの理由, 私はもっとまたはより少なく賢く、しばらく離れて歩くことを決める前に、このアプローチに定住していた).

私の解決策の欠点があります。 (タイトルのテキストのみが緊急性を示すこと明白な事実はさておき). "フィードバックの収集から" ハード コーディングされたタイトル名だけを受け入れる, 2 つの異なるフィードバックの収集アクションの唯一の違いは、ハード コード化されたタイトルを使用したいのですが。.

しかし, 少なくともイベント レシーバーまたは SPD のカスタム アクションを必要としないソリューションです。.

誰かがより巧妙な方法でこれを解決する場合, 私に知らせてください。.

</終了>

更新プログラム: Madjur Ahuja からこのリンクを指摘します。 ニュースグループ ディスカッション: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. それはかなり明確.

===

多くの場合 SharePoint Designer ワークフローから送信されるメールに InfoPath フォームへのハイパーリンクを埋め込むにしたいです。. ユーザーがこれらのメールを受信するとき, メールからのリンクをクリックして、InfoPath フォームに直接移動.

このモンスターの URL 構造は私の作品します。:

http://server/sites/departments/Technical Services/InformationTechnology/HelpDesk/_layouts/FormServer.aspx?XmlLocation=/sites/departments/Technical Services/InformationTechnology/HelpDesk/REC REM RED Forms/REC2007 12 18T11_33_48.xml&ソース = http % 3a% 2f% 2fserver% 2ecorp% 2edomain% 2ecom% 2fsites% 2fdepartments% 2ftechnical% 2520services% 2finformationtechnology% 2fhelpdesk% 2frec% 2520rem% 2520red% 2520forms% 2fforms% 2FAllItems .aspx&DefaultItemOpen = 1

フォームの名前と、赤い太字のテキストを置き換える, 次のスクリーン ショットに示すように:

その URL にハードコード パスの多くがあることに注意してください。, URL エンコードされたコンポーネントだけでなく、. これが特定の状況に翻訳するも難しい場合, フォーム ライブラリの通知を無効にしてください。. ポスト フォームとメールを取得するとき, メールのソースを表示して表示されますすべてを含める必要があります。.

明敏な読者は上記の電子メールの本文にフィルター処理されたビューを介してタスクに直接アクセスするリンクが表示されますあります。. 私は今後の記事で詳しく説明する予定します。.

</終了>

私は主に読み取り「NT_AUTHORITYAuthenticated ユーザーにのみサイトの SharePoint デザイナーを使用して、ワークフロー実装しました" (すなわち. 誰もが). InfoPath フォーム用のフォーム ライブラリがあります。. ワークフローが動作するように、同様の関連付けられたワークフローのタスク リストがあります。, それは人々 にタスクを割り当てることができます。.

認証されたあらゆるユーザーがフォームを作成してに割り当てられたタスクを更新できるように、フォーム ライブラリ、タスク リストの権限を破る.

私は私の低特権テスト アカウントでテストします。.

保存するライブラリにフォームを埋めることができます。? –> はい

タスクが電子メールのリンクからアクセスできます。? –> はい

編集ワークフロー タスクのリンクを見ることができます。 –> はい

私はそのリンクをクリックすることができます。? –> いいえ … アクセスが拒否されました.

なぜそれをクリックしたときにアクセス許可を拒否、編集リンクを見ることができます。? それがないどのようにそれは動作するようになっては…

セキュリティ構成をもう一度を通過します。, 非常に密接に. 再びそれを行う. この投稿を削除する検討してください。 明らかにセキュリティについては何も知らないので.

最後に, インターネットを検索しています。. 私はこの非常に低い MSDN フォーラムのスレッドを見つける: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

ポスター表示ドライブ プラッタにワークフローをエクスポートする単純な行為は、MOSS のセキュリティ問題を修正を示唆します。? 私はほとんどそれを入力を信じることが. 私はについてのサウスパークのエピソードを思い出したよ、 9/11 スタンは私たち Preznit を求めて陰謀, "本当に?" 何度も繰り返し.

だから, 失うものは何, SPD を起動します。, ワークフローを右クリックし、私の c を保存:\ ドライブ. それは c になります。:\ 私のラップトップのドライブ. 探しています私の肩越しに全体の時間、誰が私に尋ねる, 「なぜ保存しているワークフローをノート パソコンに?"

信じられないほど, 私の問題を解決します。. タスクを編集することができます。.

私はここの最も奇妙なワークフロー回避であることを指名します。 2007.

</終了>

アイテムまたはワークフローをトリガー ドキュメントへのハイパーリンクを含む電子メールを送信する必要がしばしば. 現在の項目の"エンコードされた絶対 URL を使用することができます。" この目的のため. ただし, それは、常に「http を使用するようだ" URL プロトコルの. あなたのサイトは、HTTPS で実行する場合、それはあなたのため動作しない.

私の知る限りでは, この問題にボックス ソリューションのうちはありません。. HTTPS を使用する必要がある場合, あなたのボックスのオプションの外はありません。.

それを解決するには, あなたのワークフローで使用する文字列置換機能を提供するカスタム アクションを作成します。. 別の方法として, ここで優秀なパッケージなどサードパーティのツールを使用します。: http://www.codeplex.com/spdwfextensions 🙂

</終了>

時折フォーラム ユーザーを求める: なぜ SharePoint デザイナーをしてください。 ???? 私の電子メールには、フィールド値の代わりに?

これが起こる理由の 1 つであるに、参照変数が null です。.

「現在のアイテムからフィールドを参照しようとしているのでこれが起こることができます" しかし、ユーザーは、決してそのフォーム フィールドに値を入力.

<終了/>

シナリオ: SharePoint Designer ワークフローで, 日付フィールドが空白のかどうかを決定する必要があります。.

問題: SPD は日付以外の日付を比較するための直接法を行いません. このような条件を作成することはできません。: 「場合 [フィールド] 空白に等しい」.

ソリューション: 日付を文字列に変換します。. 文字列比較を使用して、日付が空白かどうか.

スクリーン ショット:

次のスクリーン ショットは、どのようにこれを表示します。. このシナリオでは, フィールドのアイテム, 「環境許可:最初の許可通知の日」, 送信とワークフロー発生応答.

メモ:

私がこれを試みたとき, それが動作することを学ぶに驚いた. SharePoint Designer が文字列割り当てを許可可能性があります心配していた (変数:StringReminderDateDate) しかし、それはそれをすることでした。.

私もそのことを心配, 値が null といずれか、WF ランタイムで爆破か多分地球の温度を上げる 1/2 学位, しかし、これらの懸念が設立されました。.

</終了>

これら 2 つの定義は非常に重要な違いがあることちょうど簡単な観察:

<FieldBind フィールド「InParam1 =" DesignerType「StringBuilder を =" Id ="2" 本文 =「入力パラメーター ＃ 1」/>

対:

<FieldBind フィールド「InParam1 =" Id ="2" 本文 =「入力パラメーター ＃ 1」/>

最初このように SPD に示しています:

このような中後者の番組:

私はこれらのスクリーンショットがどのように役立つかわからないが、私はあなたがそれらを見るために持っているので、それらを作るために努力を🙂

これは観測です。: StringBuilder 文字列を作成することができます。 (明らかに) 文字列リテラルとワークフロー データを一緒に混合 ("経由で参照を追加" 左下隅のボタン). 参照の追加] ボタンを使用する場合, トークンのフォームを挿入します。"[%トークン %]". SharePoint がカスタム アクションを呼び出すタイミング, (私の場合の c# コード), SharePoint トークン自体を渡します, トークンの値ではなく. 既定のデザイナーの種類を使用する場合 (2 番目のタイプ), SharePoint トークンを拡大し、トークンの実際の値をアクションに渡します.

StringBuilder = 悪い, 既定のデザイナーの種類 = 良い.

もちろんです, それは私が本当に意味何ではないです。. ちょうど試してみて、デザイナーを入力するとき、カスタム アクションにパラメーターを渡すしない StringBuilder を =. フロントまで、ワークフローの複雑な文字列を構築する場合に既定のデザイナーの種類とチェーンに StringBuilder を使用します。 (ちなみに正確に 1 つは動的件名電子メール アクションを作成する何です。, それは別のブログのエントリの件名です。, あんた).

<終了/>