SharePoint 2013 形式ワークフローの障害復旧について

こんにちは SharePoint サポートの森 健吾 (kenmori) です。今回の投稿では、オンプレミス版の SharePoint Server 2013  以降における SharePoint 2013 形式ワークフローの障害復旧手順を記載します。 本投稿の内容は SharePoint 2010 形式ワークフローでは考慮の必要はありません。 SharePoint 2010 形式ワークフローは、SharePoint 内にワークフローのランタイムが組み込まれています。そのため、コンテンツ データベース内にワークフローのインスタンスなども存在し、コンテンツ データベース単位のバックアップ・復元だけで障害復旧できるため、運用時の負担が少ないというメリットがあります。 これに対し、SharePoint 2013 形式では、SharePoint 外部に .NET Framework 4.x における Windows Workflow Foundation のフレームワークとなる製品である Workflow Manager がランタイムを担っています。そのため、バックアップ・復元作業は SharePoint だけの作業にとどまりません。 運用環境に SharePoint 2013 形式ワークフローを展開する場合には、障害復旧についても想定しておく必要があります。 タイトル : Workflow Manager 1.0 での障害復旧とスコープ復元 アドレス : https://msdn.microsoft.com/ja-jp/library/jj730570(v=azure.10).aspx   SharePoint Server…

2

SharePoint 2010 形式ワークフローの動作制御について (チューニング)

こんにちは、SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、SharePoint における 2010 形式ワークフロー (SharePoint 2007、2010 のワークフローと SharePoint 2013 および SharePoint Online の 2010 形式ワークフロー) ランタイム側の仕組みについておさらいします。 下記投稿を現時点 (2015 年 5 月) での最新である SharePoint Server 2013 の情報に更新した内容であり、トラブルシューティング時に役立てていただけるよう記載させていただきました。 タイトル : SharePoint ワークフローのチューニング アドレス : http://blogs.technet.com/b/sharepoint_support/archive/2011/01/12/sharepoint.aspx なお、2013 形式のワークフローは Workflow Managerという別製品上にホストされて動作しますため、本投稿の記載は該当しません。   1. ワークフローの動作について ワークフローは、長い場合には数年、数か月など長期にわたるビジネス ロジックを安定して実行可能なように実装されています。また SharePointは、より即時性が求められる Web サーバーの処理を優先させながら、サーバー負荷を考慮してリソースを調整し、許容量を計算した上でワークフローを動作させる仕組みになっています。 2. ワークフローのホスト プロセスについて ワークフローは、様々なプロセス上で処理をロードして少しずつ実行する仕組みとなります。 ワークフローを構成するアクティビティは永続化ポイント (*1)…


2013 形式ワークフローでリストアイテムの権限変更を行う方法について

こんにちは、SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、SharePoint Online (または SharePoint Server 2013 On-Premises) において 2013 形式ワークフローで権限変更を行う方法についてご紹介します。 2019.2.18 追記 本ブログ記事には、SharePoint Online における現在の見解とは異なる内容が多く記載されていたため、大幅に編集しております。 導入 : 詳細に設定されたアクセス許可(FGP) を実現する方法 事前注意 : SharePoint でアイテムごとに個別にアクセス権を付与するとパフォーマンス劣化の要因となります。はじめに要件定義や設計フェーズで、この運用の方針を回避いただくことをお勧めします。どうしても、アイテムごとにアクセス権を付与する方法を実現するためにはカスタマイズが必要となりますが、リストやライブラリ スコープの上限については十分な注意を払ってください。 SharePoint Online ・・・ 5,000 SharePoint オンプレミス ・・・ 50,000 (ただし推奨は 5,000) タイトル : SharePoint Online の制限 アドレス : https://docs.microsoft.com/ja-jp/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits 方法論 : SharePoint On-Premises 製品で本機能を実現する場合は、迷わず Visual Studio を使用してファーム ソリューションでアイテム イベント レシーバーを開発し展開することが適切です。つまり、ItemAdded や…


SharePoint Online にて、2010 形式ワークフローでエラー発生したアイテムの一覧を取得するサンプル

こんにちは、SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、SharePoint Online で2010 形式ワークフローを使用して運用してエラー発生した際に、エラー発生しているアイテムの一覧を取得し、メール通知するサンプル コードをご案内します。 以前の投稿である On-Premises 版のサンプル コードは過去のブログ (下記) をご参考にしてください。 タイトル : 内部エラー (WinWF Internal Error) 発生を想定したSharePoint ワークフローをデザインする アドレス : http://blogs.technet.com/b/sharepoint_support/archive/2012/11/27/a-sharepoint.aspx   クラウド上の高スペック マシンにホストされた SharePoint Online でも、On-premises 同様、様々な事情によりワークフローでエラーが発生することはあります。他のあらゆるシステム同様、ワークフローでもエラーが発生することを 100% 防ぐことはできません。 ワークフローは一部の処理でリトライ機能をもつものの、一般的にはエラーが発生した際にはエラー発生という状態を表示し、特に処理を行うことはありません。そのため、エラーが発生する時に、どういったアクションをとるかは引き続き運用側に委ねられています。 特に重要なビジネス ロジックを含むワークフローにおきましては、エラー発生した際に即座に対処をとりたい場合も多いでしょう。 On-Premises 版のサンプルでは自動的に再起動する処理までを実装しておりました。ところが、SharePoint Online では、サーバー上で動作させる SSOM (Server Side Object Model) を使用することができず、代わりにリモート実行のライブラリである CSOM (Client Side Object Model) で同じ動作を実装する方法を検討する必要がありました。 検討の結果、SSOM…


SharePoint Designer 2010 で作成したワーク フローでユーザー プロファイルのフィールドが取得できない

こんにちは。SharePoint サポートチームの多田です。 今回は SharePoint Designer 2010 で作成したワーク フローでユーザー プロファイルのフィールドが取得できない現象の説明と回避策をご案内します。   – 環境 SharePoint Server 2010 SP2 + 2013 年 12 月 CU (KB 2849971) SharePoint Designer 2010   現象 === SharePoint Server 2010 SP2 + 2013 年 12 月 CU (KB 2849971) において、SharePoint Designer 2010 にてワークフローを作成する際に、ユーザー プロファイルを参照すると以下のエラーが発生します。     メッセージ:「サーバーからプロファイル スキーマを取得できませんでした。プロファイル ストアが正しく構成されていることを確認してください。」   現象の再現手順 ^^^^^^^^…


System.Workflow.Activities.EventDeliveryFailedException を防止する Part 2

こんにちは SharePoint サポートの森 健吾 (kenmori) です。 今回の投稿では、2011 年 4 月に私が投稿した記事 (System.Workflow.Activities.EventDeliveryFailedException を防止する) の続編ではありますが同一の現象ではなく、SharePoint 2010 の 2012 年 12 月の CU を含む、それまでの修正プログラムにて、類似事象が複数回にわたって、いくつか修正されてきていることをお伝えする内容です。 今回の現象の診断ログ抜粋 (英語環境) EngineRunWorkflow: System.Workflow.Activities.EventDeliveryFailedException: Event “OnTaskChanged” on interface type “Microsoft.SharePoint.Workflow.ITaskService” for instance id “8df07135-0710-4056-a286-49244a0bbb61” cannot be delivered. —>System.Workflow.Runtime.QueueException: Event Queue operation failed with MessageQueueErrorCode QueueNotFound for queue ‘Message Properties InterfaceType:Microsoft.SharePoint.Workflow.ITaskService Method Name:OnTaskChanged CorrelationValues: 743944d4-f704-4731-9bca-ce47b36cf6b3…


ワークフローと SQL Server デッドロックについて

こんにちは SharePoint サポートの森 健吾 (kenmori) です。今回の投稿では、ワークフローをご使用のお客様より時折発生すると報告のあるデッドロックという現象について説明します。 診断ログの抜粋 07/27/2011 12:06:00.80  w3wp.exe (0x353C)                       0x3170 Windows SharePoint Services    Workflow Infrastructure        72fr UnexpectedWorkflow Save Instance: System.Data.SqlClient.SqlException: トランザクション (プロセス ID 115) が、ロック 個のリソースで他のプロセスとデッドロックして、このトランザクションがそのデッドロックの対象となりました。トランザクションを再実行してください。     場所 System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)     場所 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)     場所 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)     場所 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)     場所 System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior…


内部エラー (WinWF Internal Error) 発生を想定したSharePoint ワークフローをデザインする

こんにちは SharePoint サポートの森 健吾 (kenmori) です。今回の投稿では、内部エラー (WinWF Internal Error) 発生を想定したSharePoint 2007 および 2010 におけるワークフローをデザインする方法をお伝えします。 少し古くなってしまいますが、前回の投稿 (http://blogs.technet.com/b/sharepoint_support/archive/2011/01/12/sharepoint.aspx) と合わせて、ワークフローの導入前や導入後においても問題を最小限に抑えるためにご確認いただきたい内容をまとめています。   導入 : アプリケーションの内部エラーという宿命 SharePoint ワークフローも、他のアプリケーションと同様内部エラーが発生することがあります。 アプリケーション開発者が、アプリケーションで予期せぬエラーが発生することを全て予期し完全に避けるようコーディングすることは不可能です。そのため、一般的にアプリケーション開発者は、例外処理として該当コードブロック内でエラー発生時にカスタム処理を実装して、予期せぬエラーが発生した場合はログを記載したり、例えばエラーを管理者に通知したり、場合によってはリトライしたりする実装を行います。 C# 例外処理の例 —- try{    // 処理}catch(Exception ex){    // 例外処理} —-  事前に認識しておくべき点として、SharePoint ワークフローは標準機能では診断ログにエラー内容を記録するよう留めています。様々な種類のワークフローが動作する基盤を提供しており、ランタイム側は各処理の重要度がどのようなものかや、エラーの種類 (入力ミスなどを含む) を認識できませんのでやむを得ません。このことから、 Visual Studio 等でカスタマイズ (FaultHandler などを定義) しない限り、標準機能の範囲でエラーを捕捉して独自処理 (特定のアドレスに通知) を実装したり、リトライしたりということはできません。 ただし、エラー終了してしまうことはシステム上やむを得ないとしても、ビジネス フローが止まってしまい、それに気づかずに業務が遅延または処理されないなど影響を与えてしまうことは、業務上あってはならないことです。 SharePoint ワークフローでは、このようにエラーとなったワークフローに対する対処策としては、エラーの原因が入力ミスの場合等を除き、速やかに一旦終了した上で再度開始させるのみとなります。このような問題解決に対する対処をあらかじめ想定しておくことは、ワークフローを使用する上で不可欠になると考えています。また、多くのユーザーの間で、Visual Studio を使用しない範囲でワークフローを使用するにとどめていることも認識しており、そのような条件下においてエラー発生時をシミュレーションした現実的な対処策を練っていく必要があると認識しています。 今回の投稿では、その対処策として考えられるベスト プラクティスとしての一案を共有させていただきたいと考えています。   エラーを想定したワークフロー テンプレートの実装方法…


ワークフローの開始処理の動作変更について

みなさん、こんにちは。 今回は 2011 年 12 月にリリースされた更新プログラムで、ワークフローの開始処理が変更された点についてご案内します。(2011 年 12 月にリリースされた更新プログラム についてはこちらをご参照ください。)   – これまでのワークフローの動作変更について これまでに SharePoint Server 2007 で行われたワークフローに関する大きな動作変更として下のようなものがありました。   サービスパック 1 サービスパック 1 を適用した後の環境では、”アイテムの作成” および “アイテムの更新” をトリガとして自動起動するように設定されたワークフローが設定されたリストやライブラリに対して、”システム アカウント” でアイテムの操作を行った際にワークフローが自動起動しないように変更されました。 こちらの動作については、以下の資料もご参照ください。 タイトル : Windows SharePoint Services 3.0 Service Pack 1 をインストールした後は、宣言型ワークフローを自動的に起動しません。 アドレス : http://support.microsoft.com/kb/947284/ja   サービスパック 2 サービスパック 2 より前の環境では、アイテムの更新をトリガとして自動起動するワークフローの中で、対象のアイテムの列の値などを変更した場合に、再び “更新” イベントが発生してワークフロー処理が無限ループする現象が発生していましたが、サービスパック 2 で修正されました。 こちらの動作については、弊社エンジニアのブログになりますが以下の資料もご参照ください。 タイトル…