Sharepointをインストールしなかった場合、州および営利団体のかなり多数の組織が、少なくともMicrosoftマーケターのおかげで、それで何ができるか聞いて想像してください。
この記事では、Sharepointでワークフローを作成するために知っている主な方法について簡単に説明し、追加のトピックとして、アプリケーションソリューションの1つであるEOS for Sharepointでこれを行う方法を説明します。 ワークフローのテーマはワークフローです。
ドキュメント、アプリケーション、またはその他のエンティティを調整するビジネスプロセスを想像してください。図1（線形ルートに沿った順次調整）のように概略的に示し、アプローチを考慮して交互に実行できます。
1. Sharepointに組み込まれたSharepointビジネス承認プロセスを使用する（3つのステップ）
2. Sharepoint Designerでのプロセスモデリング
3. Visual Studioでのワークフローの作成
4. EOSでSharepointのワークフローを作成する
ここでは、カスタムアクティビティ+ Sharepoint Designerの作成、Visual Studioでのワークフローデザイナーの作成、Infopathフォームのロジックの使用などの方法を意識的に省略します。 1つ目はSharepoint Designerと比較して論理的柔軟性がわずかに向上し、2つ目は開発が難しく、独自のボックスソリューションを開発する場合にのみ正当化されます。 InfoPathフォームはEnterpriseバージョンでのみ使用でき、誰もがEnterpriseを購入したいわけではありません。
図1-線形マッチングスキーム
明らかに、自動化されたビジネスプロセスが図1のようになっている場合は、いくつかの注意事項がありますが、どの方法も適しています。これは便宜上のことです。 組み込みのワークフロー+ページとリストビューの便利なレイアウトを使用します。
しかし、調整プロセスが図2のようになったらどうでしょうか。 ここで、調整プロセスは非線形であり、ルートはいくつかの条件に依存します。
図2-非線形マッチングスキーム
文書サポート部門（第2ステップ）では、ドラフト文書を受け取った後、プロセスに追加のコーディネーターを追加する必要があると判断する場合があります。 さらに、プロジェクトの契約額が900,000ルーブルを超える場合にのみ、プロジェクトをCFOに送信して承認を受ける必要があります。
可能な手段に関して、ここの状況は異なります。
1. Sharepointの組み込みのビジネス承認プロセスを使用する
ビルトインプロセスは分岐をサポートしていません。つまり、問題の解決には適していません。
2. Sharepoint Designerでのプロセスモデリング
Sharepoint Designerでプロセスをシミュレートする条件が与えられた場合、いくつかの呪いを使って、図3に示すようなものを記述します。
図3-Sharepoint Designerのワークフロー
条件ステートメントと、図4に示すようなカスタマイズ可能なタスクフォームの組み合わせにより、プロセスを実装できます。
図4-Sharepoint Designerのカスタムタスク
アプローチの利点：
1.ある程度の準備、忍耐、および自由時間を使用して、有能なマネージャーまたは適切な管理者もこのタスクに対処します。
2.プロセスを再調整できます。
3.ワークフローを作成するユーザーの権限を制限する機能。
アプローチの短所：
1.かさばって不透明に見えます。
2.ブランチが増えると、ワークフローダイアグラムを紙に個別に描画する必要があります。SharepointDesignerでどのように見えるかを理解することは困難です。
3. Sharepoint Designer 2010では、ワークフローのサイクルはまだ発明されていないため、少なくとも明白な方法では、障害が発生した場合にプロセスを再起動することはできません。
4.プロセスのロジックに関連しない多数の追加アクション。
3. Visual Studioでのワークフローの作成
Visual Studioを使用すると、柔軟で複雑なビジネスプロセスを自由に作成できます。 たとえば、上記のプロセスの一部は次のようになります（図5）。
図5-Visual Studioワークフローのスニペット
ロジックは、Whileループ、If-ElseおよびConditionalActivityブランチを使用して制御できます（詳細については、 http：//msdn.microsoft.com/en-us/library/hh824675 （v = office.14）.aspxを参照してください ）。
アプローチの利点：
1.高い論理的柔軟性
2. .NET機能
アプローチの短所：
1.実装の複雑さ、変更。
2.プログラミングおよびファーム管理者の権限が必要です。
3.文書作成プロセス中にのみ、および重要な文書を含む透明性。
4. SharepointのEOS
Eos for Sharepointは、完全な電子文書管理システムです。 ここには視覚的なプロセスエディタはありませんが、詳しく調べると非常に強力で使いやすい組み込みのコンストラクタがあります。 そのため、上記のプロセスは、すべての段階を順番に調整することで構成されます（図6、7、8）。
図6-ステージ参加者の選択
図7-ワークフローを開始するための条件
各ステージで、参加者を選択し、権限を自動的に構成し、ワークフローの履歴を維持する方法を決定し（図6）、起動条件を構成し、ユーザーにフィールド値を要求できます（図7）。 追加のマッチングが必要な段階では、個別のカスタマイズされた承認ワークフローを実行できます。
各ステップの構成を完了した後、ワークフロー全体のパラメーターを構成できます。たとえば、コーディネーターの1つが失敗した場合にワークフローを再起動します（この場合、ワークフローは図8の最初のステップから始まります）。
図8-ワークフローパラメーターの設定
SharepointのEOSの各ステージのシーケンシャル構成を使用すると、非常に短時間で複雑さを調整するビジネスプロセスをシミュレートできます。 追加のアクション、チェック、および検証はありません-有能なITスペシャリストがプロセスの作成に対応します。
おわりに
Sharepointビジネスプロセスの自動化の選択は、ほとんどの場合、その複雑さに依存します。 プロセスが非常に単純な場合は、標準ツールを使用してください。 プロセスが複雑で分岐している場合、SPDまたはVisual Studioでのロジックの実装は長く複雑になる可能性があります。この場合、実装の微妙な部分に進むことなくプロセスロジックに集中できるサードパーティツールを使用する方が効果的です。