ソリューションを組織する

  • [アーティクル]

 

公開日: 2017年1月

対象: Dynamics 365 (online)、Dynamics 365 (on-premises)、Dynamics CRM 2016、Dynamics CRM Online

ソリューションを作成する前に、先の計画に時間をかけます。 たとえば、どれだけの数のソリューションを公開するか、また、それらのソリューションでコンポーネントをどう共有するかを検討します。

また、一連のソリューションの開発に必要となる Microsoft Dynamics 365 組織の数を決定します。 このトピックで説明する戦略の多くについては、使用する組織が 1 つだけでもかまいません。 しかし、最初に組織を 1 つだけと決めて、後になって複数の組織が必要だとわかった場合、ソリューションを既にインストールした人々を考慮してソリューションを変更するのは、容易なことではありません。 複数の組織を使用すると、導入はより複雑になりますが、柔軟性は増します。

ソリューションの編成戦略

以下、ソリューションの開発戦略を、単純なものから複雑なものへと順に説明します。

  • カスタム ソリューションなし

  • 単一ソリューション

  • 複数ソリューション

  • 複数ソリューションで一部共有コンポーネントを使用

  • ソリューション ライブラリ

カスタム ソリューションなし

ソリューションを作成する必要はありません。 既定のソリューションを使って Microsoft Dynamics 365 を直接カスタマイズすればよいからです。

それでも既定のソリューションをアンマネージド ソリューションとしてエクスポートすれば、組織間でソリューションを移動できます。

ヒント

既定の発行者のカスタマイズ接頭辞の値を、将来作成しようと考えている別の発行者の値と対応するように変更すると、その後に作成する新しいカスタマイズでは名前にこのカスタマイズ接頭辞が含められます。 こうしておけば、ソリューションを使う場合に、既定のソリューションで以前作成したカスタマイズをアンマネージド ソリューションに追加しても、名前の一貫性が保たれます。

単一ソリューション

ソリューションの開発とは一連の実用的なカスタマイズを確定することでもあります。 結果として、実際にカスタマイズしたアイテムを簡単に見つけることができます。

この方法は、作成するマネージド ソリューションが 1 つだけの場合にお勧めします。 将来、ソリューションを分割する可能性があると思われる場合には、複数ソリューションの戦略を検討してください。

複数ソリューション

コンポーネントを共有しない 2 つの無関係なソリューションがある場合は、2 つのアンマネージド ソリューションを作成するのが素朴なやり方です。

注意

ソリューションでアプリケーションのリボンやサイト マップが修正されるのはよくあることです。 これらのソリューション コンポーネントが両方のソリューションから修正されるなら、それらは共有コンポーネントだと言えます。 共有コンポーネントを使用する方法については、次のセクションを参照してください。

複数ソリューションで一部共有コンポーネントを使用

複数のソリューションでコンポーネントを共有することがあります。 複数のソリューションに共通の機能セットがあって、その機能セットが各アプリケーションに固有の他のどの機能とも両立するような状況です。 たとえば、各ソリューションが一連ユーティリティ プラグインを使用しているような状況では、それぞれのソリューションはまだ相互にコンポーネントを共有していません。

この場合は、個々のソリューションを 1 つの組織内だけで開発できます。 コンポーネントを複数のソリューションに含めることができるのは、それらのコンポーネントに対する変更が、それらのコンポーネントを使用する他のどのソリューションとも矛盾しない場合に限られます。 この点で、すべてのソリューションが同一のソリューション発行者を共有することが重要です。 ソリューション発行者が一意に特定されなければ、複数のソリューションを開発しても、それらが組織にインストールされることはありません。

ソリューション ライブラリ

複数のソリューションを所有する ISV や、企業内システムを大規模に展開するケースでは、どうしても多数のソリューション コンポーネントを共有することになる可能性があります。 ソリューションを共有する最善の策は、ソリューション ライブラリを使用することです。 ソリューション ライブラリの作成は、別々の組織で作成したアンマネージド ソリューションをコンポーネントとしてマネージド ソリューションにパッケージ化するという流れで行われます。 このマネージド ソリューションを別の組織にインストールすれば、そこで開発者がそれらの共有コンポーネントを参照できるようになります。

Microsoft Dynamics 365 Solutions Framework では、相互に依存するソリューションを多層的に構成できます。 通常は、"基底" のソリューションとなるソリューション ライブラリを 1 つ作成します。 その他のソリューションは、この基底のソリューションの上層に構築されていきます。 これでコンポーネントの分離がより明確になります。 ソリューション ライブラリにかかわる開発チームと、それに依存するソリューションにかかわる開発チームが、それぞれ異なるペースで開発を進めることになるからです。 依存ソリューションの開発は、ソリューション ライブラリがインストールされない限り始まりません。

これは利用者が最初にインストールしないと依存ソリューションをインストールできないような必須ソリューションの開発が必要なことを意味します。 ソリューション ライブラリにかかわる開発者は、それを必要とする依存ソリューションが破棄されない限り、そのライブラリの開発や更新を続けることになります。

関連項目

ソリューション開発のためのチーム編成
ソリューション開発の計画

Microsoft Dynamics 365

© 2017 Microsoft. All rights reserved. 著作権