かなり一般的な状況は、Microsoft Dynamics CRMの標準機能が十分でない場合、またはシステム内の一部のオブジェクトまたはエンティティの操作を構成できない場合です。 顧客のビジネスプロセスの特性により、特定のエンティティの動作をやり直す必要がある場合があります。
これらの非自明なケースでは、CRMコンサルタントと開発者はプラグインとアドオンを使用します。プラグインとアドオンの目的とこれらのエンティティの違いを考慮します。 これらのソフトウェア製品を開発する際には、いくつかの制限もありますが、そのうちのいくつかを簡単に説明します。
プラグインは、Microsoft Dynamics CRMに統合してプラットフォームの標準的な動作を変更できるカスタムビジネスロジックです。 プラグインを使用して、既存のCRMイベントハンドラーを中断および置換します。 プラグインは、CRMを他のソフトウェアシステムと統合するために広く使用されています。
拡張機能（アドオン）は、個別のプロジェクトとして開発されたCRM上で開発されたアドオンで、新しいエンティティとオブジェクトを導入したり、CRMでこれらのエンティティを変更する新しい形式を使用したりできます。
通常、プラグインには視覚的な形式のシステムアドインはありません。 プラグインとは対照的に、拡張機能には視覚的なフォームを含めることができます。 開発後のプラグインと拡張機能はCRMに組み込まれています。
すべてのCRMオブジェクト、エンティティ、および構造はデータベースに保存されます。 プラグインと拡張機能は、CRM SDKを使用して実装する必要があります。 CRM SDKは、開発者がさまざまなCRMオブジェクトを管理するためのAPIです。 正式には、CRM SDKをバイパスして直接データベース接続を実装することができます。 これは、内部のニーズに合わせて設計されたプラグインおよび拡張機能で使用できます。 しかし望ましくありません。 顧客に配布されるプラグインのSDKをバイパスして、Microsoft Dynamics CRMデータベースへの直接接続を実装することはできません。 直接接続を使用するプラグインおよび拡張機能は、Microsoftに登録できません。
さらに、CRMデータベースに直接接続すると、Microsoft Dynamics CRMのセキュリティスキームとユーザー権限が侵害されます。 これは、データベースに直接接続する場合、オペレーターは、接続に使用するデータベースのユーザーが許可するすべてのオブジェクトにアクセスできるという事実によるものです。
データベースに直接接続する場合、CRMでイベント処理をサポートすることも難しく、特定のプロセスを引き起こす可能性があります。 データベースへの追加はテーブルで直接行われるため、このサポートは複雑です。 それに応じて、内部CRMイベントハンドラーは失敗するか起動しますが、すべての場合ではありません。
プラグインと拡張機能はNETアセンブリです。 プラグインとアドオンを開発するには、Visual Studioツール環境を使用します。 開発テクノロジー-ASP。 プログラミング言語としてC＃またはVisual Basic NET。 プラグインと拡張機能は、Microsoftの要件に従って特別な方法で設計する必要があります。 この設計では-アプリケーションの動作に影響する多くのニュアンス。 これについては、次の出版物で詳しく説明します。
CRM拡張機能の視覚的なフォームを開発する場合、これらのフォームが既存のCRMデザインに適合するようにこれらのフォームの外観を作成する必要があり、コンポーネントの動作は標準のCRMコンポーネントの動作に類似する必要があります。 残念ながら、Microsoftはそのようなコンポーネントを開発者に提供していないため、これには多少の困難があります。 したがって、さまざまな開発者が開発環境の既存の従来のコンポーネントを個別に変更し、これらのコンポーネントの動作を標準のCRMコンポーネントの動作に合わせて調整します。 一部の開発者にとってはこれは良いですが、誰かにとっては悪いです。 ただし、Microsoft Dynamics CRMのユーザーは、いずれの場合も、コンポーネントの標準的な動作に慣れているため、拡張機能でこの方法を遵守することをお勧めします。
一度の実装ではなく複数の販売を目的としたプラグインと拡張機能を開発する場合、インストールキーを生成し、開発したソフトウェア製品を特定の数のユーザーにライセンス供与する問題に対処する必要があります。 通常、製品のコストは、この製品を使用するユーザーの数に依存します。 この場合、2つのアプローチが可能です。 最初のアプローチでは、インストール中にMicrosoft Dynamics CRMのユーザー数を確認します。 また、CRMのユーザーと同数のライセンスを購入するようクライアントに要求します。 2番目のアプローチはより柔軟です。特定のユーザーがプラグインまたは拡張機能を最初に起動したときに、購入したライセンスをこのユーザーにバインドします。 この場合、クライアントは、実際にプラグインまたは拡張機能を使用するユーザーのライセンスに対してのみ支払います。
おもしろいなら、続けて...