• [アーティクル]

Microsoft Dynamics CRM 4.0 を展開する

Aaron Elder

 

概要:

  • CRM システムのソフトウェア コンポーネント
  • 開発ライフサイクル
  • CRM ソリューションの要素
  • マルチテナント機能について

目次

ソリューション開発ライフサイクル
CRM ソリューションの要素
マルチテナント機能について
デザイン時の考慮事項
重要な習得事項

CRM が単なる販売とマーケティングのための管理ツールだと考えている場合は、その考えを改める必要があります。Microsoft Dynamics Customer Relationship Management は、実在する物 (オブジェクト) に関連する情報やプロセスを管理および追跡するアプリケーションを開発するためのプラットフォームです。たとえば、このようなオブジェクトには顧客がありますが、CRM で開発したアプリケーションを使用すると、管理する必要があるあらゆる物 (および関連するアクティビティ) を管理して追跡することができます。

大規模なカスタム ソリューションと同様に、CRM の展開には、理解しなければならない基本原則があります。この記事では、Microsoft Dynamics CRM の展開に関する基本的な概念をいくつか紹介し、製品のライフサイクルを通じた展開をサポートするために、この概念を活用する方法についても説明します。また、1 つのソリューションの一部として複数の展開を管理する方法を紹介し、ソリューションのライフサイクルにおいて、マルチテナント機能は、どのように使用するべきで、どのように使用すべきではないのかについても説明します。

まず、この記事では「Microsoft Dynamics CRM ソリューション」という表現を、カスタマイズ、拡張、カスタム コード、スキーマの変更などの総称として使用していることに注意してください。ソリューションは、1 つのもので構成されているのではなく、すべての変更をひっくるめたものです。

Microsoft Dynamics CRM ソリューションのバックグラウンドでは、ASP.NET 2.0 と Microsoft .NET Framework 3.5 を使用した標準的なデータ ドリブン Web アプリケーションが動作しています。この 3 層で構成されたシステムの主要コンポーネントは下記のとおりです。

データ層 SQL Server 2005 データベースまたは SQL Server 2008 データベースです。SQL Server 2008 を使用するには、サポート技術情報の記事「Microsoft Dynamics CRM 4.0 と Microsoft SQL Server 2008 を共に実行する場合のサポート」に記載されている修正プログラムをインストールする必要があります。

中間層 Microsoft インターネット インフォメーション サービス (IIS) 6.0 以降の Web フロント エンド、SQL Server Reporting Services (SRS) 2005 または SRS 2008 、ASP.NET 3.5、およびカスタム Windows サービスです。

クライアント層 Microsoft Internet Explorer 6.0 以降のクライアント、ASP.NET 2.0 以降、Microsoft Office Outlook 2003 (オフライン アクセスを使用する場合は Office 2007 クライアント)、SDK ベースのクライアント、サードパーティ製のモバイル クライアントなどです。

また、Microsoft Dynamics CRM は、Microsoft Exchange Server 2003 以降や Active Directory など、さまざまな外部システムが必要です。

ソリューション開発ライフサイクル

Microsoft Dynamics CRM ソリューションは、図 1 に示すようなカスタム アプリケーション開発プロジェクトと同じライフサイクルを辿ります。

fig01.gif

図 1 アプリケーション開発ライフサイクル

この全プロセスは、開発システム、テスト システム、および運用システムで構成された複数の環境でサポートされています。言うまでもありませんが、複数のシステムに接続しているエンタープライズ アプリケーションでは、このプロセスは、さらに複雑になります。たとえば、ミラー化した環境を用意するには、図 2 のような環境が必要になります。

fig02.gif

図 2 開発環境、テスト環境、および運用環境のミラー化

つまり、ドメイン、ドメイン コントローラ、メール サーバー、Web サーバー、およびデータ ベース サーバーが、それぞれ 3 台必要になります。このモデルでは、SRS と CRM が同じコンピュータにインストールされることが想定されているので、負荷分散などについては考慮されていません。このモデルに冗長性を持たせて、Microsoft Office SharePoint Services (MOSS) などの外部サービスをいくつか追加すると、図 3 に示すような複雑な構成になってしまいます。

fig03.gif

図 3 複雑さが増したモデル

コストと複雑さの問題から、「環境を分離する必要性」および「コスト削減と管理容易性の向上」という 2 つのニーズのバランスを見極める必要があります。そのため、組織では、この問題への対策として、仮想化や Microsoft Dynamics CRM の組み込み機能であるマルチテナント機能など、さまざまな技法に期待が寄せられました。

CRM プロジェクトのライフサイクルをサポートする一連の環境をデザインする際には、いくつかの考え方がありますが、何を重視するかによって、どの考え方を採用すべきかが異なります。ある極端な考え方を持つデザイナーは、環境を完全に複製して、各環境を完全に分離することを主張します。このデザイナーは、ソリューションが運用環境と同じように動作するかどうかを確認するには、運用環境とまったく同じ構成のテスト環境を用意する必要があると考えています。また、テスターと IT プロフェッショナルによって、テスト対象のシステムやソリューションが運用環境でも動作すると認められるには、すべてのサーバーから細部の設定に至るまで、テスト環境は運用環境とまったく同じである必要があると考えています。

これに対して、このレベルの分離は、まったく必要ないと考えるデザイナーもいます。このようなデザイナーは、可能であれば、運用環境で直接開発やテストを行います。冗長性は時間とコストの無駄であり、運用環境で開発やテストを行えば、システムをより簡単に構築できると考えています。

皆さんは、この両極端なデザイナーの中間的な見解を支持して、Microsoft Dynamics CRM ベースのソリューションでは、複雑さ、コスト、分離、および管理容易性のバランスが取れたハイブリッド アプリケーションを開発できるというアイデアを受け入れていただければさいわいです。

CRM ソリューションの要素

Microsoft Dynamics CRM ソリューションのコンポーネントは、4 種類に分類できます。開発するソリューションには、1 種類のコンポーネントだけを含めることも、2 種類、3 種類、または 4 種類すべてのコンポーネントを含めることもできます。

カスタマイズ この種類のコンポーネントには、フォーム、グリッド、スキーマ、およびメタデータに関する変更、セキュリティ ロール、ワークフロー、システムの設定、およびテンプレートなどがあります。Microsoft Dynamics CRM のカスタマイズは、zip 形式の XML ファイル (通常は、1 ～ 2 ファイル) で提供されます。カスタマイズは、Outlook クライアントや Web クライアントの設定やカスタマイズにより CRM 展開にインポートされ、公開することでアクティブになります。この一連の処理は、Microsoft Dynamics CRM SDK に従ってコードを記述することで自動化できます。

拡張 この種類のコンポーネントには、カスタマイズとは個別に展開する必要があるプラグインなどのカスタム コードやレポートなどがあります。プラグインの登録情報は、XML ファイル形式で保存されているので、コマンド ラインまたはマイクロソフトが提供している Windows フォーム アプリケーションを使用して展開できます。この処理も、Microsoft Dynamics CRM SDK に従ってコードを記述することで自動化できます。

カスタム コード この種類のコンポーネントには、ソリューションの一部として開発されたものが含まれます。たとえば、外部 Web サービス、カスタム Web アプリケーション コンポーネントなどで構成されているものがあります。カスタム コードの展開に関する規則と原則は、他のカスタム Web アプリケーションと同様です。

データ この種類のコンポーネントには、環境にインポートしないと環境が機能しない情報が含まれます。たとえば、ドメイン データ (たとえば、製品コードの一覧)、ユーザーなどが、これに該当します。ソリューションで必要なデータは、スクリプト化したコードや CRM の一括インポート機能を使用したり、BizTalk Server や他の ETL (抽出、変換、読み込み) ツールによる外部処理を使用して Microsoft Dynamics CRM インスタンスに展開できます。ただし、ユーザーなど、一部のデータは、手動で作成するか、Microsoft Dynamics CRM SDK の呼び出しによって作成する必要があります。

私は CRM ソリューションの展開は、カスタム アプリケーション開発の展開と同様に考えるのが望ましいと考えています。つまり、開発とテストを行う際には、ソリューションの新しいビルドは、クリーンな状態のシステムからインストールし、なるべく多くの処理を再利用可能にし、スクリプト化すべきだと考えています。

マルチテナント機能について

今度は、CRM を展開する環境の適切な状態について説明しましょう。Microsoft Dynamics CRM 4.0 Enterprise Edition で、マルチテナントと呼ばれる機能がサポートされていることについてはご存じかもしれませんが、この機能を使用すると、1 つの展開の中で Microsoft Dynamics CRM の複数インスタンスに境界を設けることができます。つまり、それぞれが独自のレポート、ワークフロー、カスタマイズ、およびスキーマを保持している、まったく関連のない複数の組織が、同じ物理サーバーで同じデータベース インスタンスと IIS Web サイトを使用して、同じハードウェア上で実行することが可能になります。

一見すると、これは、管理容易性、分離、およびコストというすべての問題を解決する救世主であるかのように見えるかもしれません。このようなソリューションは、図 4 のような状態になります。

fig04.gif

図 4 マルチテナント機能のみを使用したソリューション

各組織は、共有の SQL Server またはインスタンスで、各組織専用の物理データベース (カスタマイズ、ワークフロー、ユーザー、ロール、および設定を含む) と SQL Server Reporting Services フォルダを使用できるので、論理的であるように見えます。

これらの関連のない組織が別のチームや部署のソリューションの一部である場合、このモデルは何の問題もなく機能します。というのも、マルチテナント機能は、このような場合に使用することを想定してデザインされた機能だからです。各組織 (テナント) は、それぞれ独自のデータベースを所有しますが、同じ組織単位 (OU) と Active Directory グループを共有しているので、同じプラットフォーム サービスとフロントエンド アプリケーションを共有することになります。つまり、これらの組織では、同じ非同期のサービスと IIS Web サイトが共有されるということになります。フロントエンド サーバーでは、URL に基づいてホストする組織を判断する URL プロバイダにより、複数の異なる組織をホストすることができます。

たとえば、crmserver/ContosoDevOrg/loader.aspx および crmserver/ContosoTestOrg/loader.aspx という URL を見てみましょう。CRM サーバーでは、ルート ディレクトリを参照して、サービスを提供する組織名を判断します。crmserver/loader.aspx という URL のようにルート ディレクトリに組織名が含まれていない場合、CRM サーバーでは、展開で最初に作成された組織または呼び出し元のユーザーがアクセスできる組織が既定で対象の組織であると見なします。

この例では、どちらの組織でも同じ Web サイトが使用されるため、ソリューションでカスタム コードを使用している場合は、カスタム コードも、両方の組織で共有されることになります。たとえば、crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx と crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx では同じカスタム コードが使用されます。

どちらのページでも、ディスク上にある同じ物理ファイル (たとえば、C:\inetpub\wwwroot\isv\mycustomdialog.aspx) をポイントしています。開発環境、テスト環境、および運用環境では、カスタマイズした拡張のバージョンが異なる可能性が高いため、これは深刻な問題になることがあります。たとえば、現在、アプリケーションのビルド 11 を開発中で、UAT (ユーザー受け入れテスト) でビルド 9 が使用されているとしましょう。マルチテナント機能を使用して、環境間の問題を解決しようとすると、2 つのビルドを分離するという困難な作業に対応しなければならなくなります。このような状況では、図 5 のようなソリューションを使用したことがある方もいらっしゃるでしょう。

fig05.gif

図 5 カスタム ソリューションのコードを分離するために環境ごとに別の IIS サーバーを使用する

このモデルでは、ユーザーが、次のような URL を入力することができます (ただし、ネットワーク負荷分散アドレスを使用していない場合に限ります)。

開発環境 192.168.1.100/ContosoDevOrg/loader.aspx

テスト環境 192.168.1.105/ContosoTestOrg/loader.aspx

運用環境 192.168.1.110/Contoso/loader.aspx

このモデルでは、3 台のフロントエンド サーバーを使用して、3 つの組織をホストし、ディスク上では 3 つの異なるコード ベースを用意することができます。ユーザーが間違って別のサーバー上にある別の組織の URL にアクセスすることがなければ、すべて問題なく機能します。

残念ながら、すべてのフロントエンド サーバーは、同じ展開の一部と見なされるため、問題は一見するよりも深いところにあります。このことは、ソリューションで非同期のプラグインやワークフローを使用している場合に問題となります。というのも、このようなソリューションでは、ユーザーがアクセスするサーバーは制御できますが、どの非同期サービスがどの組織のイベントや要求を処理するのかについては制御できないからです。

展開に含まれるすべての非同期サービスはラウンドロビン方式で動作するので、開発サーバーの非同期サービスで、テスト サーバーのワークフロー、システム ジョブ、また非同期のプラグインの応答を処理する可能性があり、その結果、分離の要件を満たすのが非常に困難になります。また、この非同期プロセスによって実行されるカスタム コードが、サーバーのディスク上に展開されていなければならないファイル (構成ファイル、グローバル アセンブリ キャッシュ (GAC) に含まれるファイルなど) に依存している場合は、バージョンの競合という問題が発生します。

ただし、このような問題の大部分は、ディスク上に展開する必要があるカスタムコードを記述しているか、カスタム コードが特定のサーバーでしか利用できないリソースに依存している場合にしか生じることはありません。ソリューションが単純で、カスタマイズ (スキーマ、フォーム、ビューなど)、ワークフロー、およびレポートしか使用していない場合、図 4 のアプローチを使用しても何の問題もありません。

では、マルチテナント機能は何のために用意された機能で、製品のライフサイクル環境で使用する適切なタイミングはいつかということについて、ご説明しましょう。当初、マルチテナント機能は、運用環境で複数のテナントをホストする際に発生していたハードウェアの問題を解決するためにデザインされたもので、このような問題には適切に対処できます。ただし、Microsoft Dynamics CRM 3.0 では、各展開 (テナント) 専用の SQL Server または SQL Server インスタンスと、フロント エンド サーバーを用意する必要がありました。

展開固有の設定がレジストリとディスクに格納されていたという事実を含め、これらの要件は、さまざまな理由から、理にかなったものでした。このような構成情報は、すべてデータベースに移行されたので、1 台のアプリケーション サーバーで複数の組織に対応できるようになりました。マルチテナント機能は、Microsoft Dynamics CRM オンラインを含む、ホストされている CRM で使用すると便利な機能です。

デザイン時の考慮事項

潜在的な問題について説明したので、今度は、展開のデザイン時の留意点について説明しましょう。もちろん、その内容は状況によって異なります。Microsoft Dynamics CRM 4.0 バーチャル マシンのデモンストレーションからわかるように、1 台のコンピュータで (ドメイン コントローラー、SQL Server、および Web サーバーを含む) 完全な CRM 環境を実行することは可能です (このデモンストレーションの URL については、「CRM の関連情報」を参照してください)。開発環境では 1 台のコンピュータで構成された CRM 環境の仮想イメージを使用するのはごく一般的なことです。ただし、テスト環境では、運用環境で発生する主要な問題を評価することが重要になるので、運用環境と同じ構造を再現することをお勧めします (設備能力について再現する必要はありません)。たとえば、図 6 のような環境を用意することができます。

fig06.gif

図 6 テスト環境では運用環境の構造を再現する必要がある

このアプローチでは、仮想化を使用してインフラストラクチャで使用する物理的なハードウェアを最小限に抑え、テストする必要がある主要シナリオのみを仮想化することでリソースの仮想化をさらに抑えようとしています。開発者がソリューションの展開先となる環境に注意を払い、その環境を認識するようになれば、複数の開発者が 1 つのサーバー イメージで開発を行えるようにすることができます (開発者が各自のデスクトップ PC にバーチャル マシンをインストールしている場合は、複数の開発者が複数のサーバー イメージを使用して開発を行うことが可能になります)。開発者が注意を払わなければならない問題は、評価に使用するテスト環境を構築する際に注意しなければならない問題と同じです。これには、次のような問題があります。

設定を構成できるようにする たとえば、サーバーが localhost や特定のポートに応答すると仮定しないこと。

複数台のサーバーを意識する プロキシ ユーザーや委任のための信頼を構成しないで何かが動作すると仮定しないこと。

負荷分散を意識する セッションの状態やキャッシュに注意を払うこと。Microsoft Dynamics CRM は、完全にステートレスで、ラウンドロビン方式のロード バランサーと適切に連動するようにデザインされています。

マルチテナント機能を意識する 1 台のコンピュータで複数のテナントをホストしている場合、プロセス領域が共有されます。つまり、キャッシュなどの要素は、組織名でアクセス制限を設けて、ユーザーが知らないうちに別の組織のデータを使用しないようにする必要があります。また、サーバーへのリンクやコールバックを含むクライアント側コードがある場合には、その呼び出しで、URL に組織名が含まれるようにする必要があります。組織名が含まれていないと、既定の組織の URL にアクセスしたり、想定していない組織の URL にアクセスする可能性があります。

CRM の関連情報

Microsoft Dynamics CRM 4.0 実装ガイド

ビジネス アプリケーション開発プラットフォームとしての Microsoft Dynamics CRM 4.0

Microsoft Dynamics CRM チーム ブログ

Microsoft Dynamics CRM 4.0 バーチャル マシン

Microsoft Dynamics CRM 4.0 の最適化と管理

重要な習得事項

分離の重要性 ソリューションをデザインする際には、どのアプローチ (図 4、5、または 6 に示したもの) が最適であるかに留意し、カスタム コードが実行される可能性のある場所とタイミングを認識する必要があります。ソリューションで使用する拡張の種類によっては、このような問題を考慮する必要がない場合もあります。

仮想化 仮想化は、運用環境の主要なテスト シナリオを再現した環境を構築するという複雑な作業を緩和するのに役立ちます。このような環境の設定方法を簡単に紹介しましょう。CRM と SQL Server を別のサーバーにインストールします。この構成により、委任のための信頼とそれに関連する他の問題を検証できます。CRM サーバーでは負荷分散を行う必要があります。これは、セッション、キャッシュ、およびサーバー間の問題を特定するのに役立ちます。最後に、ドメイン コントローラと電子メール サーバーを別のサーバーにセットアップします。この構成は、接続に関する問題を特定するのに役立ちます。

ビルドごとに環境を新しくする 一般的には、サーバーを通常の状態に戻すために復元できる仮想化環境のバックアップを作成するか、単純に Microsoft Dynamics CRM データベース (Data データベースと Config データベース) のバックアップを作成するのが得策です。ビルドごとに、新しい環境にクリーンな完全展開 (カスタム コード、カスタマイズ、プラグイン、ドメイン データを含む) を行います。

冗長性とパフォーマンスのテストは個別に行える 非常に大きな組織は例外ですが、フェールオーバーとパフォーマンスのテストは、個別にシミュレーションを行うことが可能で、実世界と同じ環境を構築する必要はありません。つまり、冗長性とパフォーマンスをテストするためのテスト環境は必ずしも構築する必要はありません。また、運用環境や独立した単独の環境のいずれかでテストを行うこともできます。

最後になりますが、Microsoft Dynamics CRM は、スケーラブルなエンタープライズ クラスのシステムで、適切に構成して展開すると、小さなチームからエンタープライズ規模まで、さまざまな規模のソリューションに対応できます。適切な製品ライフサイクル環境は、さまざまな要素によって変化します。

一般的に、マルチテナント機能は、複雑なソリューションの製品ライフサイクル開発の問題への対応には適していません。また、この機能について詳しい知識がなければ、この機能を最大限に活用することはできません。基本的なカスタマイズのみが必要で、ディスク上にあるリソースやサーバー固有のアクセスを必要としていない適切にコーディングおよび分離されたカスタム拡張を使用している単純なソリューションでは、図 4 に示したモデルで十分に対応できます。

ソリューションでより厳密な分離、サーバー固有のリソースやアクセス (たとえば、VLAN 経由ではサーバー A からサーバー B に対してしか外部サービスを利用できない) などが必要な場合は、図 6 に示したモデルを採用することをお勧めします。また、図 5 に示したアプローチは、ハイブリッドなハッキングを引き起こす可能性があるので、このアプローチは使用しないことをお勧めします。

また、Microsoft Dynacmics CRM は、さまざまな構成で展開することができるので、最適な構成は、ソリューションで実現する必要があることによって異なります。マルチテナント機能、単一サーバーによる開発環境、仮想テスト環境、およびテストできるシナリオのうちどれが重要であるのかについての理解を深めると、適切に機能し、かつコスト効率のよい製品ライフサイクル展開をデザインできるようになるでしょう。

Aaron Elder は、Microsoft Dynamics CRM の MVP 保持者で、テクノロジ コンサルティングと双方向マーケティングを行っている Ascentium に勤めています。ぜひ、Ascentium 社のブログ (ascentium.com/blog/crm) にアクセスしてみてください。