Business Connectivity Services

  • [アーティクル]

Office と SharePoint BCS を使用して社員報奨を管理する

Ying Xiong

社員報奨の管理は、どの企業においてもビジネスに不可欠な業務です。これは、マイクロソフトのような規模の大きい企業には特に当てはまります。マイクロソフトでは、社員の実績を基に、昇給、昇進、賞与、株式など、さまざまな報奨を適格者に付与しています。これらの報奨を、(地域、部門や組織、給与プラン、給与レベルに応じて設定されている) 会社のガイドラインと予算に従って管理するのは、複雑なプロセスです。

報奨を社員に付与する際は、多くのビジネス ルールが関係します。なんといっても、これらのルールによって、あらゆるレベルの組織がそれぞれの目標を達成し、各組織の予算とガイドラインを遵守しながらも、あらゆるレベルで業績トップの社員に最高の報奨が付与されるようにしています。毎年、管理者と人事担当者が、数字を分析し、すべてのレベルで各報奨のガイドラインと限度を決めています。このプロセス ("調整" と呼びます) は、時間がかかり複雑です。

マイクロソフトの管理者や人事担当者が現在使用している報奨管理ツールは、Windows フォーム アプリケーションです。このツールは設計どおりに機能していますが、ニーズのすべてを満たしているわけではありません。調整プロセスを簡易化および合理化できると思われる改善の余地が多くあります。

調整ツールの改善を求める声に応じて、マイクロソフト IT (MSIT)、人事部門、Microsoft Office および SharePoint 製品チームが協同で、Microsoft Office 2010 と SharePoint 2010 の Microsoft Business Connectivity Services (BCS) を基盤とする新しいソリューションを作成しました。BCS は基幹業務 (LOB) システム、Web サービス、データベースのほか、SharePoint and Office アプリケーションの外部データに対する読み取り/書き込みアクセスを提供します。

新しいソリューションでは、Microsoft Excel 2010 を報奨管理の UI に採用しました。また、BCS テクノロジを利用して社員データとビジネス ルールをキャッシュし、ユーザーのローカル コンピューターとバックエンド システム (報奨 Web サービスと SQL Server データベース) 間の同期を行います。

この記事では、この報奨管理 BCS システムを開発および展開した際のマイクロソフト チームの経験を紹介します。

プロジェクト開始時の状態

既存の報酬管理ツールは、社員の査定、調整、評価、および報奨全般を 1 つの包括的なツールセットにより処理する統合業績管理機能サポートすることが目的でした。図 1 は、既存のツールのアーキテクチャを示しています。このツールは、典型的な 3 層アプリケーションで、UI 層の Windows フォーム アプリケーションは、バックエンド Web サービスとの間でデータの読み取りと書き込みを行います。バックエンド Web サービスは、SQL Server データベースに格納されている社員レコード、ビジネス ルールなどの参照データを照会および更新します。

image: Architecture of Current Rewards-Management Tool

図 1 現在の報奨管理ツールのアーキテクチャ

このソリューションは、ユーザーのコンピューターと Web サービス コンポーネントをホストしている Web サーバー間のネットワーク トラフィックを最小限に抑えるように設計されていました。クライアント アプリケーションが起動すると、ユーザーにアクセス許可がある組織のデータから、すべての必要な参照データ、ビジネス ルール データ、および社員レコードを取得してキャッシュします。報奨管理ビジネス ロジックとルールのほとんどは、クライアント コンポーネントに実装されています。したがって、ユーザーが社員報奨を割り当てまたは変更するときは、バックエンドの Web サービスを呼び出すことなく、対応するビジネス ルールが実行されて、変更が検証されます。

Web サービス コンポーネントは、Microsoft .NET Framework 2.0 Web サービス フレームワーク (ASP.NET Web サービス) を使用して作成されています。前述のとおり、このコンポーネントは、社員レコードやビジネス ルール データをクライアント アプリケーションに返し、クライアントからデータベースに渡されたデータへの変更を保存します。Web サービスには、データがデータベースに保存される前にデータの整合性を確認するビジネス検証ロジックが組み込まれています。すべての Web サービス呼び出しは、同期メソッドとして設計されています。

Web サービス呼び出しが失敗するとユーザーにエラー メッセージが返されるため、ユーザーはエラーの性質を基に対処することができます。また、Web サービス サーバーとクライアント アプリケーション間で転送されるデータのサイズを最小限に抑えるために、Web サービスは社員やその他のデータ レコードをバイト配列にシリアル化し、そのバイト配列をクライアントに返すように設計されていました。

報奨データは Microsoft SQL Server 2005 に実装されているリレーショナル データベースに格納されます。このデータベースには、社員報奨のほか、過去の業績査定期間の履歴データの管理に必要なすべてのデータが格納されています。

前述のとおり、このアプリケーション アーキテクチャはほぼ計画どおりに機能していて、それ以前の報奨および調整システムよりも格段に機能が向上していました。ただし、使用しているうちに、より簡単に少ない時間で調整を実行できるように、ツールを改善できる部分が多数見つかりました。新しいサービスで採用した設計の背景を理解できるように、古いシステムで見つかった問題の一部を簡単に説明します。

古い調整ツールで最初に見つかった、おそらく最も重要な問題は、報奨のモデル化の難しさが関係していました。調整プロセスでは、管理者は 2 種類の数値のバランスを取る必要があります。各社員は、業績評価に基づいて、適切な報奨を受け取る必要があります。ただし、組織全体としては、事前に決められた報奨の予算を守る必要があります。このバランスを適正にするのは、時間がかかる作業です。管理者は、社員の報奨金額を入力し、それがチームの報奨予算にどのように影響するかを確認し、報奨金額を調整して報奨のルールと予算とのバランスが取れるようにします。これを、最終的な報奨が決まるまで、何度も繰り返し行うことになります。

既存のツールは、報奨と予算のバランスを取るプロセスを容易にするものではありませんでした。既存のツールには、報奨ごとに異なる数値を入力する機能や、結果を分析して、予算とガイドラインにどのような影響があるかを分析する機能がありませんでした。社員データを Excel ワークシートにエクスポートして、手作業で報奨額と予算額をモデル化しなければなりませんでした。

調整が完了し、各社員の報奨が最終的に決定すると、手作業でデータをツールに入力して、承認を受けるために報奨内容を提出する必要があります。この二重のデータ入力も、時間のかかるプロセスです。

Windows フォーム ベースのツールは、バックエンド Web サービスに接続してデータの読み取りや書き込みを行う必要があるため、ユーザーがオンラインで社内ネットワークに接続している必要があります。これは、予定が詰まっていて出張が頻繁にある社員にとって、忙しさに輪をかけることになります。

また、既存の報奨管理ツールには、一連の組み込みレポートが用意されていましたが、調整プロセスの透明性を高め、より効率的に進められるように、追加のレポートや柔軟性の高いアドホックのレポート機能を求める声が多く寄せられていました。

BCS の基本

BCS は Office アプリケーション (Excel、Outlook、InfoPath、Word など) と SharePoint を使用して、バックエンド システムのデータを処理できるようにします。前述のとおり、BCS は Office 2010 と SharePoint 2010 のコンポーネントであるため、クライアント コンピューターからもサーバー コンピューターからも利用できます (BCS ツールおよびランタイム コンポーネントの詳細については、msdn.microsoft.com/library/ee556826 を参照してください)。

BCS 対応のソリューションを設計するときは、まず、外部システムに接続できるエンティティ モデルを定義し、外部データ構造のデータを BCS データ構造のデータにマップします。このエンティティ モデルを、外部コンテンツ タイプ (ECT) と呼びます。ECT は SharePoint Designer または Visual Studio を利用して、ソリューションに必要な数だけ作成できます。

エンティティ モデルを定義するコードも含め、ECT メタデータは、SharePoint メタデータ ストアに発行および格納されます。発行された ECT モデルは、SharePoint ワークスペースまたは BCS が提供するスタンドアロンのパッケージング ツールを使用して、ユーザーのクライアント コンピューターにダウンロードおよびインストールできます。

実行時には、クライアントまたはサーバーの BCS ランタイム コンポーネントが ECT モデルを呼び出して外部システムと通信します。クライアントでは、外部システムのデータがユーザーのコンピューターの SQL Server Compact Edition (SQL CE) データベースにキャッシュされます。キャッシュされたデータは、BCS API を利用して Office アプリケーションで表示および操作できます。キャッシュされたデータに対してユーザーが施した変更は、ユーザーのコンピューター上の同じ SQL CE データベースのキューに登録されます。その後、BCS ランタイム コンポーネントが、ECT モデルを利用して外部システムに変更を反映します。

新しい報奨ツール

前述の業務上の問題に対応するソリューションを、BCS フレームワークを使用し、UI に Excel を採用して、新しい報奨管理ツールとして作成しました。この Excel と BCS によるソリューションでは、社員情報、ビジネス ルールなどの参照データ用に合計 15 個の ECT を定義しました。BCS ランタイムはこれらの ECT を使用して既存の報奨管理 Web サービス (外部システム) に接続し、社員データやビジネス ルールのデータを取得してキャッシュします。

社員データは、BCS ローカル キャッシュ API を使用する Excel アドインによって、Excel ワークシートとして表示されます。管理者は、たとえオフラインであっても、社員の報奨を完全に Excel 内で割り当て、調整、および管理でき、さらに BCS ローカル ストアにキャッシュされているデータに基づいてすべてのビジネス ルールを適用することもできます。Excel と BCS によるこのソリューションでは、選択した社員の一覧 (Excel ワークシートとして) やさまざまな統計情報 (Excel タスク パネルとして) を画面に表示できます。画面下部に表示される統計情報は、報奨額を変更すると動的に更新されます。また、ユーザーが選択したフィールドに応じて表示される統計情報が変わります。これは、格段に改善されたユーザー エクスペリエンスです。

管理者や人事担当者は、ピボットテーブルやグラフなど Excel のネイティブ機能を使用して、BCS によってキャッシュされたデータのさまざまなレポートを作成および表示できるため、生産性が向上します。Excel テンプレートを利用することで、容易にレポートを作成できます。しかも、レポートには IT 開発が不要です。

業務上のメリットのほかに、この新しい報奨管理ソリューションの開発中に、技術的にも興味深い点を発見しました。それは、既存の Web サービスが BCS 向けに設計も最適化もされていないのに、その既存の報奨 Web サービス コンポーネントを新しい BCS ソリューションに利用できたことです。また、既存のビジネス ルール データ オブジェクトと検証コードを Excel アドイン ソリューション内で使用することもできました。その結果、比較的短時間で新しいソリューションの導入およびデモを実施できました。

ソリューションのアーキテクチャ

新しいソリューションのアーキテクチャを図 2 に示します。ご覧のように、元のアーキテクチャから変更したのは、クライアント アーキテクチャ コンポーネントの部分のみです。この図では、緑の図形が、Office 2010 のインストール時にユーザーのコンピューターにインストールされる BCS コンポーネントを表しています。青い図形は、新しいソリューションのために開発したコンポーネントで、水色の図形は既存の報奨管理ツールのコンポーネントです。

image: Architecture of the New Rewards Solution

図 2 新しい報奨ソリューションのアーキテクチャ

新しい報奨ソリューション用に開発した ECT がユーザーのコンピューターにインストールされると、BCS 同期プロセス (BCSSync.exe) が直ちにエンティティ モデルを呼び出して、モデルに定義されている各 ECT のデータを外部の報奨 Web サービスから取得します。実際に同期されるデータは、ユーザーのデータ アクセス許可 (ユーザー セキュリティ Web サービスから取得) を基に決まります。この手順では、Web サービスにアクセスするため、ユーザーがオンラインである必要があります。

ある組織の社員レコードなど、取得したデータは、BCS 同期プロセスによって作成された SQL CE データベースに、ユーザーのローカル データ キャッシュとして格納されます。SQL CE のデータは、ユーザーの証明書を使用して暗号化され、ユーザー レベルでセキュリティ保護されます。

BCS 同期プロセスは定期的に実行され、ユーザーのローカル キャッシュと報奨サーバーを同期し、サーバー側での変更が反映されます。BCS フレームワークを利用すると、ECT ごとに異なる同期の実行頻度を定義できます。つまり、ビジネス ルールなどあまり変更されないエンティティについては同期頻度を長め (数時間または数日) に定義し、査定期間中に頻繁に変更される可能性のある社員の報奨データについては同期頻度を短め (数分または数時間) に定義できます。

社員データ、ビジネス ルール データなどの参照データをユーザーのコンピューターにキャッシュしておくことで、ユーザーは Excel を起動するだけで報奨管理ツールでの作業を始めることができます。報奨ツールの Excel アドインは、BCS の API を使用して SQL CE データベースからデータを取得して、そのデータを Excel ワークシートにバインドします。これにより、ユーザーは社員レコードと各社員の報奨データを Excel で参照できます。この Excel ファイルは、通常作成または使用する他の Excel ファイルと何ら変わりはなく、Excel のネイティブ機能を使用してデータを操作および分析できます。

ワークシートから変更を行い、能力給の昇給率、昇給額、株式報奨の株数など、社員の報奨を割り当てるか更新すると、該当するビジネス ルールが呼び出されて、変更が検証および処理されます。これは、Excel セルの値変更イベントを既存のビジネス ルールのコードにフックすることで、実現しています。

さらに、社員番号、役職、電子メール アドレスなど一部の社員データは、ユーザーが変更できてはいけません。この要件は、Excel のネイティブ機能であるロック機能を使用して実現しています。

ユーザーが (オンラインであれオフラインであれ) 変更をバックエンド サーバーに送信する準備ができたら、変更は SQL CE データベースにあるローカル キューに送信されて格納されます。BCS 同期プロセスが、キューから変更を 1 つずつ取り出し、バックエンドの報奨 Web サービスに送信します。ユーザーがオフラインであるか、バックエンド Web サービスが利用できない場合、BCS プロセスはユーザーがオンラインになるか Web サービスが利用可能になるまで変更の送信を再試行します。

変更をバックエンド サーバーに送信できる状態ではなく、草案として変更を保存する場合は、通常の Excel ファイルの保存操作として処理します。

ECT を定義する

前述のとおり、BCS 対応プロジェクトで重要な最初の作業は、ソリューションの ECT を作成することです。ECT の設計は、Office または SharePoint ソリューションで使用するデータ エンティティをモデル化するプロセスです。ECT の数と各 ECT のデータ構造は、アプリケーション データの性質、データの使用方法、および外部システムが提供するインターフェイスによって決まります。

ECT エンティティのデータは、外部システム (ここでは、報奨 Web サービス) から取得されるため、エンティティをモデル化する最も簡単な方法は、外部システムから返される型と同じになるようにエンティティを設計することです。この方法であれば、構造間のデータ マッピングが不要です。ただし、常にこの方法が使用できるわけではありません。特に、外部 Web サービスが複雑なデータ型や階層が深いデータ型を返す場合は使用できません。さいわい、今回の報奨管理システムには、この方法を使用できました。

既存の報奨 Web サービスは、クライアント側でカスタムの System.Data.DataTable 型にシリアル化解除する必要があるシリアル化されたバイト配列を (社員データとビジネス ルール データとして) 返します。ただし、このようなカスタム データ型は、BCS の既定ではサポートされていません。

新しい報奨システムの ECT 実装では、社員エンティティとビジネス ルール エンティティに、比較的フラットなデータ構造を定義しています。また、この ECT 実装では、(シリアル化解除後に) カスタム データ テーブルのデータをフラットな ECT 構造に変換またはマップもします。ECT を介してユーザーがデータを更新すると、データはカスタム データ テーブルの型に戻され、変更がバックエンド Web サービスに送信されます。

どの ECT にも、少なくとも 2 つのメソッドが定義されている必要があります。Finder メソッドは、すべてのデータをダウンロードするために、BCS ランタイムによって呼び出されます。社員 ECT の場合は、ユーザーにアクセス許可があるすべての社員レコードが返されます。クライアント コンピューターへの ECT のインストール時に、インストール プロセスはこの Finder メソッドを基に、BCS ランタイムが定期的に ECT を同期するためのサブスクリプションを作成します。

SpecificFinder メソッドは、エンティティの ID (社員番号) を基に、データ (社員) の特定のインスタンスを返します。SpecificFinder は、その特定の社員インスタンスとバックエンド サーバーとの同期を取るために、BCS ランタイムによって使用されます。社員レコードなど、クライアント側でユーザーが更新するデータ エンティティの場合、ECT には BCS ランタイムが更新をサーバーに送信するために呼び出すことができる更新メソッドを含めます。同様に、ユーザーがあるエンティティの新しいレコードを作成する必要がある場合は、ECT に作成メソッドも定義します。ユーザーが変更しない参照データ エンティティの ECT には、更新メソッドも作成メソッドも必要ありません。

カスタム ECT 実装には、外部 Web サービスを呼び出す前にデータを検証または処理するために必要なビジネス ロジックを追加できます。これは、ビジネス ロジックを直接 ECT に組み込み、クライアントとサーバーの両方で実行できるという、BCS ならではの便利な設計オプションです。

ECT を設計および作成する方法には 2 とおりあります。外部システムから比較的フラットで厳密に型指定されたデータ型が返される場合は、SharePoint Designer を使用して ECT を生成できます。SharePoint Designer は外部システムのインターフェイスを基に ECT を生成します。Windows Communication Foundation (WCF) Web サービスの場合は、操作とデータ コントラクトがこのインターフェイスに当たります。ただし、現時点では、カスタムのデータ セットやデータ テーブルなど、複雑なカスタム型を SharePoint Designer はサポートしていません。

2 つ目の、より強力な方法は Visual Studio を使用して ECT を設計および作成することです。Visual Studio 2010 には、まさに BCS エンティティ モデルを作成するためのプロジェクト テンプレートが付属しています。今回、報奨ソリューションに使用した方法はこちらです。

ECT の展開とインストール

報奨管理システムを使用できるようにするには、ECT モデルをクライアント コンピューターにダウンロードしてインストールする必要があります。Microsoft Office および SharePoint 2010 では、2 とおりの方法で ECT を展開できます。図 3 は、Office 2010 のインストール時にユーザーのコンピューターにインストールされる SharePoint Workspace を使用した展開プロセスを示しています。図 4 はもう 1 つのプロセスを示します。

image: ECT Deployment Process Through SharePoint Workspace

図 3 SharePoint Workspace による ECT 展開プロセス

image: ECT Deployment Process Through BCS Solution Packaging Tool

図 4 BCS ソリューション パッケージ ツールによる ECT 展開プロセス

最初に、ECT が Visual Studio から SharePoint Server のメタデータ ストアに発行されます (手順 1.)。Visual Studio から ECT メタデータを SharePoint データ ストアに発行するには、SharePoint 2010 がインストールされているサーバーと同じサーバーで Visual Studio が実行されている必要があります。

次に、発行された ECT ごとに外部リストを作成します (手順 2.)。外部リストは、SharePoint Server に接続できるコンピューターであればどのコンピューターでも、SharePoint ホームページから作成できます。

ECT の外部リストが作成されると、SharePoint によって直ちに ECT が実行されます。ECT は外部システムに接続し、外部システムからデータを取得して、データを SharePoint サイトにリスト コンテンツとして表示します。この展開プロセスでは、ECT から返されたデータを、クライアントの Office アプリケーションだけでなく、SharePoint Server 上でも表示できます。これは必要な機能である場合もありますが、必須ではありません。報奨管理ソリューションでは、社員報奨という機密データを SharePoint によって公開したくないので、この機能は使用していません。

今度は、手順 2. で SharePoint Server から作成した外部リストをローカル コンピューターにダウンロードします (手順 3.)。ダウンロードを始めるには、Internet Explorer から SharePoint ホームページに接続し、[サイトの操作] をクリックし、[SharePoint Workspace と同期] をクリックします。これにより、クライアント コンピューター上の SharePoint Workspace プログラムが起動し、1 つずつ外部リストのダウンロードが開始されます。Workspace 2010 の現在のリリースでは、ダウンロード対象の外部リストごとに [インストール] ボタンをクリックする必要があります。

外部リストをダウンロードすることで、SharePoint Workspace によって自動的に ECT (メタデータとアセンブリ) が BCS ローカル データ ストアにインストールされます (手順 4.)。また、インストールされた ECT 用に、BCS ランタイムが ECT データを外部システムと定期的に同期するためのサブスクリプションが作成されます。既定のデータ同期頻度は 6 時間に 1 回です。

報奨管理ソリューションでは、2 番目の展開プロセスを使用して、ECT をユーザーのクライアント コンピューターにインストールします (図 4 参照)。

この展開方法では、BCS ソリューション パッケージ ツール (code.msdn.microsoft.com/odcsps14bcspkgtool、英語) を使用しています。また、この展開プロセスでは外部リストは使われません。したがって、SharePoint Server メタデータ ストアは利用していますが、SharePoint ホームページや SharePoint Workspace は不要です。

この展開プロセスでは、ECT が SharePoint メタデータ ストアに発行された後に、SharePoint Designer を使用して ECT をモデル ファイル (.bdcm) 形式でエクスポートしています。SharePoint Designer はサーバー コンピューターでもクライアント コンピューターでも実行でき、エクスポートしたモデル ファイルは共有フォルダーに保存できます。BCS ソリューション パッケージ ツールはモデル ファイルを読み取り、ユーザーが実行できる Visual Studio Tools for Office (VSTO) インストール パッケージを生成します。

ユーザーからすると、これは実に簡潔明瞭なインストール プロセスです。setup.exe の実行中に 1 度クリックするだけで、SharePoint Designer からエクスポートされたすべての ECT がインストールされます。また、このインストール プロセスでは BCSSync.exe が直ちに起動されて ECT が実行され、ECT データが外部システムから直接 BCS ローカル データ キャッシュにダウンロードされます。

Excel アドイン

前述のとおり、既存の Windows フォーム アプリケーション コンポーネントを Excel アドイン コンポーネントに設計し直して、Excel を社員の報奨を管理する UI に採用しました。Excel アドインは、次の主要機能を実行します。

  • 社員レコードと、関連する操作手順および統計情報を Excel ワークシートおよび作業ウィンドウとして表示します。
  • BCS API を使用して、社員データとビジネス ルール データを BCS ローカル キャッシュから取得し、変更がある場合は BCS ローカル更新キューに書き戻します。
  • ユーザーが社員報奨を変更した場合、既存のビジネス ロジック コードを呼び出して、変更が該当するガイドラインに準じていること、および最小と最大の範囲内であることを確認します。

図 5 に、報奨管理の Excel ベースの UI を示します。画面の上半分は、Excel ワークシートで、ユーザーの組織の社員レコードが表示されています。画面の下半分は作業ウィンドウで、強調表示されている社員 (選択されている行) に対応するガイドラインと、組織の統計情報が表示されています。選択した列に対応するガイドラインと統計情報は、画面下部に表示されます。

image: Excel Design for the Rewards-Management Solution

図 5 報奨管理ソリューションの Excel 画面

この簡潔で使いやすい Excel インターフェイスは、管理者や人事担当者が社員報奨を効果的に管理するうえで役立っています。すべての作業を画面上で実行しながら、組織全体の報奨の状態を把握することができます。もちろん、ピボットテーブルやピボットグラフなど Excel のネイティブ機能を使用して、ワークシートの社員データを基に、追加の統計やグラフを作成できます。

Excel プログラムを起動すると、Excel アドインによってメニュー バーにカスタムの [Rewards] (報奨) タブが追加されます。[Rewards] (報奨) タブをクリックすると、報奨管理ソリューションを起動および使用するための各種ボタンがあるリボンが表示されます。

BCS API を使用する

当然、BCS API はどの BCS ベースのソリューションでも核になります。サンプル コードのいくつかを分析して、BCS API の使い方を説明しましょう。

まず、ローカル キャッシュ ストアから全社員レコードの取得に使用するコードを見てみましょう (図 6 参照)。

図 6 社員レコードを取得する

string entityNameSpace = "MSIT.HR.Rewards.BCS";
string entityName = "EmployeeDetails";

// Initialize and connect to BCS local cache
RemoteSharedFileBackedMetadataCatalog catalog = 
  new RemoteSharedFileBackedMetadataCatalog();

// Get the ECT for employee entity
IEntity entity = catalog.GetEntity(@entityNameSpace, entityName);

// Get the finder method defined for employee ECT
string methodName = entity.GetMethodInstance(
  MethodInstanceType.Finder)[0].Value.Name;
IMethodInstance mi = entity.GetMethodInstance(
  methodName, MethodInstanceType.Finder);

// Get external system instance
ILobSystemInstance LobSysteminstance = 
  entity.GetLobSystem().GetLobSystemInstances()[0].Value;

// Retrieves all instances of employee ECT
IEntityInstanceEnumerator instanceEnumerator = 
  entity.FindFiltered(entity.GetDefaultFinderFilters(),
  mi, LobSysteminstance, OperationMode.CachedWithoutRefresh);

// Loop each employee and add it to Excel worksheet list object
while (instanceEnumerator.MoveNext()) {
  ... // Loop each instance of employee record and
      // add it to Excel worksheet list object
}

IEntity は、ソリューション用に定義した ECT に対するメインの BCS インターフェイスです。IEntityInstance は、データを取得するエンティティの特定のデータ インスタンスを表します。各 ECT には、エンティティ名前空間内に一意のエンティティ名があります。各エンティティ インスタンスは、ECT の定義時に定義する一意 ID によって識別されます。この場合は、社員番号が一意 ID に当たります。

社員レコード (より正確には、社員 ECT インスタンス) は BCS のエンティティ インスタンス更新メソッドを使って更新できます。これにより、BCS ローカル キューに更新操作が作成されます。したがって、10 件の社員レコードを変更すると、ローカル キャッシュのキューに 10 件の操作が格納されます。BCS 同期プロセスは、この操作を 1 つずつ処理します。このコードを次に示します。

// Query the employee instance you want to change
Identity identity = new Identity(employeeNumber);
IEntityInstance myEmployee = 
  entity.FindSpecific(identity, LobSysteminstance);

// Update the employee bonus amount
myEmployee["BonusAmount"] = 1000;

// Submit the changes to BCS local cache
myEmployee.Update();

図 7 のコードは、外部システムが使用できないか、エラーまたはデータ競合が発生したために、保留中または失敗したすべての操作についての情報を BCS キャッシュに照会する方法を示しています。

図 7 保留中または失敗した操作をチェックする

// Initialize and connect to offline cache store
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISynchronizationManager syncManager = 
  offlineRuntime.GetSynchronizationManager();
IMetadataCatalog catalog = 
  offlineRuntime.GetMetadataCatalog();

// Get all current operations from local operation queue
IOperationCollection allOps = syncManager.GetOperations();

foreach (IOperation op in allOps) {
  // ECT associated with the operation
  IEntity entity = op.Entity;

  // Query for operation status
  string operationstatus = op.OperationStatus.ToString();

  // Query for operation retry count
  int retryCount = op.RetryCount;

  // Get last exception message if operation errored out
  string errMsg = op.LastException.Message;

  // Retry the operation if status is pending or error
  op.Retry();

  // Decide if error is due to data conflict
  if (errMsg.Contains("ConflicDetectedException"))
    // Then the error is due to data conflict
}

ISynchronizationManager は、BCS エンティティ同期プロセスのメイン インターフェイスです。各操作 (IOperation) は、BCS ランタイムが処理すべきエンティティ データへの変更を表します。ランタイムによる処理後は、各データ更新操作の状態が Pending または In Error になります。操作を正常に処理すると、操作がキューから削除されるため、同期マネージャーを利用してその操作を照会することはできません。

Pending 状態は、外部システムが使用できなかったために、操作が保留中であることを示します。BCS は、その操作が成功するかエラーになるまで、自動的に処理を繰り返し試みます。

In Error 状態は、検証エラー、データ整合性エラー、またはデータ競合エラーのために、操作が外部システムによって処理できなかったことを示します。

場合によっては、BCS ランタイムによる定期的な同期を待たずに、外部システムのローカル キャッシュを明示的に更新したいときがあります。すべての ECT のデータを強制的に更新するコードを以下に示します。

// Initialize and connect to offline cache
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISubscriptionManager subManager = 
  offlineRuntime.GetSubscriptionManager();

// Get all subscriptions
ISubscriptionCollection mysubs = subManager.GetSubscriptions();
IEnumerator<ISubscription> ie = mysubs.GetEnumerator();

while (ie.MoveNext()) {
  ISubscription mySub = ie.Current;
  mySub.RequestRefresh(true);
}

前述のとおり、ECT がユーザーのコンピューターに初めて展開およびインストールされると、外部システムのデータをローカル データ ストアに取得するためのサブスクリプションが BCS ランタイムによって作成されます。BCS ランタイムはこのサブスクリプションを使用して、ECT データと外部システムを同期しています。

上記のサンプル コードでは、ISubscriptionManager が、BCS データ ストアに作成されたすべてのサブスクリプション (ISubscription) を取得するためのインターフェイスです。サブスクリプション オブジェクトを使用すると、ECT の同期頻度の変更、新たなクエリ パラメーターの追加、最後の更新状態の取得、即時更新の要求 (この例のケース)、ECT で同期されるインスタンス数の取得など、さまざまな処理を実行できます。

得られた教訓

新しい報奨管理ソリューションの設計、開発、および展開中に、Office アドインの開発と SharePoint 2010 BCS の実装について、多くの実践的で現実的な経験が得られました。この経験を通して得られた教訓をいくつか紹介します。

まず、ソリューションの ECT の設計にはできるだけ時間をかけるようにします。ECT の設計が、BCS ソリューションが成功する鍵です。ECT は BCS ランタイムの動作に直接影響するため、ECT が適切に設計されていないと、BCS ランタイムのクラッシュやメモリ不足例外の発生につながる可能性があります。

この教訓は、今回の苦い経験から得ました。当初、1 つのインスタンスですべてのビジネス ルールを返す、大きな ECT を設計しました。この 1 つのインスタンスには 40 MB の配列が含まれていましたが、この配列をオブジェクトにシリアル化解除するときに、BCS ランタイムは最大 600 MB ものメモリを使用することになりました。

メモリ使用量の問題を緩和するため、この大きな ECT をルールのカテゴリを基に複数の ECT に設計し直しました。カテゴリ別の各 ECT は、実際のルール数と同じ数のエンティティ インスタンスを返します。このように新しく対象を絞った ECT を用意したことで、BCS 同期プロセスははるかに効率的に機能しています。

また別のベスト プラクティスは、厳密な型指定と比較的フラットな構造をできる限り使用して ECT を定義することです。SharePoint Designer をして ECT を生成できると、開発時間を大幅に節約できます。Visual Studio で多数のエンティティ属性を使用して ECT を作成すると柔軟性は高まりますが、時間がかかる面倒な作業になり得ます。

ユーザーのローカル コンピューターにダウンロードおよびキャッシュできるデータ量について、要件を十分に検討してください。これにより、ECT の Finder メソッドの実装方法が決まります。もちろん、外部システム呼び出しから返されるデータによって、ダウンロードできるレコード数には制限があります。ECT の設計上、制限以上のデータが必要な場合は、要件に合わせて外部システムを変更する必要があります。

この報奨ソリューションでは、管理者がダウンロードおよびキャッシュできる社員レコードは、自分の組織のものだけです。したがって、ユーザーが異なれば、それぞれのユーザーのローカル キャッシュにダウンロードされる社員データもおそらく異なります。既存の報奨 Web サービスでは、ユーザーを認証してから、そのユーザーがアクセス許可を持つ社員データのみを返していました。つまり、データのフィルターは外部システム側で処理され、ECT 実装がユーザー許可に基づくデータのフィルターを実行する必要はありません。この動作がソリューションに不適切であれば、ローカル キャッシュで ECT データのフィルターを処理するための設計と開発を行う時間も考慮する必要があります。

ECT 実装では、慎重に外部システム例外を処理してください。Finder メソッドと SpecificFinder メソッドの ECT 実装は、どこかの時点で外部システムのメソッドを呼び出してデータを取得する必要があります。外部システムからスローされる例外は、コード内でキャッシュおよび処理する必要があります。ただし、例外を処理したら、BCS ランタイムに例外を戻すことも必要です。そうしないと、BCS ランタイムは、外部システムへの呼び出しが成功したものと見なし、データを 0 行返して、ローカル キャッシュ内の既存のデータを削除します。外部システムの例外のためにローカル データ キャッシュが削除されるのは避ける必要があります。

また、ECT 実装にサードパーティのライブラリを使用する場合の注意点もあります。今回の ECT の 1 つでは、追加のビジネス ロジックとデータ変換を実行するために、他のグループが開発したアセンブリを参照する必要がありました。この ECT の開発しているときに、参照先のアセンブリが ECT インストール中にクライアント コンピューターに展開されないことに気付きました。このため、BCS によってこの ECT は実行されず、データがダウンロードされませんでした。

本稿執筆時点では、BCS 製品チームと協力してソリューションを開発していたため、VSTO インストールの一環としてグローバル アセンブリ キャッシュにアセンブリを追加することでこれを回避しました。

ECT のテストとデバッグは非常に重要です。ECT は BCS ランタイムによってバックグラウンドで実行されますが、ECT がクライアント コンピューターで実行中の場合は、Visual Studio から ECT をデバッグできません。そこで、SharePoint で外部リストを作成して、サーバー側で ECT のテストとデバッグを行うことをお勧めします。SharePoint リスト ページで外部リストの内容を表示および変更するときは、その外部リストに関連付けられている ECT コードを実行しながら、SharePoint と同じサーバー上で実行されている Visual Studio を利用して、ECT をデバッグできます。

最後になりますが、BCS API のエンティティ操作モードを理解することは、非常に重要です。BCS API を使用して ECT エンティティ インスタンスを操作するクライアント側アプリケーションでは、ECT データの管理に使用できる操作モードが 4 種類あります。以下に、各モードの動作の概要を簡単に紹介します。

  • OperationMode.CacheWithoutRefresh: エンティティ インスタンスにこの操作モードが使用されると、BCS はエンティティ インスタンスをキャッシュから返します。データがキャッシュ内になければ、外部システムのデータでキャッシュを更新し、キャッシュされたデータを返します。外部システムに接続できなければ、例外をスローします。
  • OperationMode.CacheWithImmedicateRefresh: この操作モードでは、BCS はまずキャッシュ内のエンティティ インスタンスを外部システムのデータで更新してから、キャッシュされたデータを返します。外部システムに接続できなくても、キャッシュされたデータを返します。エンティティ インスタンスがキャッシュされておらず、外部システムに接続もできない場合は、例外を返します。
  • OperationMode.Offline: オフライン操作モードでは、キャッシュにデータがなくても、外部システムには接続しません。BCS はキャッシュからエンティティ インスタンスを返します。キャッシュになければ、例外をスローします。
  • OperationMode.Online: オンライン操作モードでは、BCS はローカルにキャッシュされたデータを使わずに、常に外部システムに接続してエンティティ インスタンスのコピーを取得します。外部システムに接続できなければ、例外をスローします。

まとめ

BCS が付属する Microsoft Office と SharePoint 2010 は、使い慣れた Office UI を使用して複数の外部システムの企業データを管理するための、簡潔で使いやすく強力なソリューションを実装する基盤となります。この基盤は、ビジネス データやビジネス プロセスの場所や時間を問わない利用を促進し、ひいては企業の生産性向上につながります。

BCS の同期インフラストラクチャは、データのコピー、変更、および競合に関するさまざまな問題を解決します。BCS 同期が他のデータ同期フレームワークよりも優れている点の 1 つは、BCS では ECT 実装を利用することでソリューションの同期プロセスにビジネス ロジックとデータ検証ロジックを埋め込めることです。BCS のもう 1 つの優れている点は、他の多くの同期フレームワークが提供するポイント ツー ポイントのデータ同期ではなく、複数の異種システムの複合データを (この場合も ECT 設計によって) 同期できることです。

Ying Xiong はマイクロソフト IT チームの主席アーキテクトで、マイクロソフト社内のエンタープライズ アプリケーションおよび統合のアーキテクチャ策定と設計を担当しています。分散エンタープライズ アプリケーションの作成に必要なさまざまなマイクロソフト テクノロジに取り組んでいます。Xiong の連絡先は yingx@microsoft.com (英語のみ) です。

この記事のレビューに協力してくれた技術スタッフの Rolando Jimenez Salgado と Satish Thatte に心より感謝いたします。