ソリューション

8 分

ソリューションは、Dataverse 環境でカスタマイズを追跡、管理するコンテナーです。ソリューションは、アプリやコンポーネントをある環境から別の環境に転送したり、一連のカスタマイズを既存のアプリに適用するために使用します。

複数の環境がある場合は、それぞれに独自のソリューションのセットがあります。

ソリューションの概要環境を示す図。

メモ

Sales などの Microsoft Dynamics 365 アプリがある場合、アプリは同じソリューションフレームワークを使用してインストールされます。 ISV も、ソリューションを使用して製品を出荷します。

ソリューションには次の特徴があります。

構成データにメタデータと特定のエンティティを含む。ビジネスデータはソリューションに含まれない。
モデル駆動型アプリ、キャンバスアプリ、サイトマップ、フロー、テーブル、テーブルメタデータ、列、フォーム、ビュー、ビジネスルール、プロセス定義、カスタムコネクタ、Web リソース、選択、グラフ、コンポーネントなどのコンポーネントや、開発者が作成したスクリプトやコンパイルされたコードなどのさまざまな Microsoft Power Platform コンポーネントを含む。
他の環境にエクスポートまたはインポートする際はユニットとしてパッケージ化される。または、分解されアセットのソースコードとしてソース管理にチェックインされる。
既存のソリューションに変更を適用するために使用される。

ソリューションのタイプ

ソリューションには、次の 2 つのタイプがあります。

アンマネージド - 開発中に使用され、他の開発環境への転送に使用されます。
マネージド - 非開発環境への配布に使用されます。

アンマネージドソリューションは、開発環境でアプリケーションに変更を加えるときに使用します。その後、アンマネージドとしてエクスポートされたソリューションを、ソース管理システムにチェックインします。アンマネージドソリューションは、ソースとして考える必要があります。

管理ソリューションは、テスト、ユーザー受け入れテスト (UAT)、システム統合テスト (SIT)、運用環境など、開発環境ではないすべての環境に配置するために使用します。

管理ソリューションは、任意の環境にある他の管理ソリューションとは別にサービス提供 (更新、パッチ、削除) できます。 ALM のベストプラクティスとして、管理ソリューションはビルドサーバーで生成し、ビルドアーティファクトとして考慮します。

ソリューションの階層化

ソリューション階層は、コンポーネントの動作を拡張または変更する各ソリューションを通じて、コンポーネントを提供するルートソリューションからの依存関係チェーンを表します。階層は、既存のコンポーネントの拡張 (依存関係に基づく)、またはソリューションの新しいコンポーネントや新しいバージョンの作成によって作成されます。

ソリューションの階層化は、コンポーネントレベルで実装されます。マネージドおよびアンマネージドソリューションは、Microsoft Dataverse 環境内の異なる階層に存在します。 Dataverse には 2 つの異なる階層があります。

アンマネージド階層 - インポートされたすべてのアンマネージドソリューション、および特別なカスタマイズは、この階層に存在します。すべてのアンマネージドソリューションは、1 つのアンマネージド階層を共有します。
マネージド階層 - インポートされたすべての管理ソリューション、およびシステムソリューションは、このレベルに存在します。複数の管理ソリューションがインストールされている場合、最後にインストールされたソリューションは、前にインストールされた管理ソリューションの上にインストールされます。したがって、インストールされる 2 番目のソリューションは、前にインストールされたソリューションをカスタマイズすることができます。 2 つの管理ソリューションに競合する定義がある場合、実行時には、最後にインストールされたものが適用されるか、結合ロジックが実装されます。管理ソリューションをアンインストールすると、その下の管理ソリューションが有効になります。すべての管理ソリューションをアンインストールすると、システムソリューション内で定義されている既定の動作が適用されます。マネージド階層レベルの最下層にはシステム階層があります。システム階層には、プラットフォームの動作に必要なエンティティとコンポーネントが含まれています。

ソリューション階層を示す図。

ソリューションアーキテクトは、ビジネスソリューションで使用するソリューションの数を決定する必要があります。 1 つのソリューションを使用することもできますが、リリースへの依存が生じ、大規模なソリューションのエクスポートとインポートには時間がかかる場合があります。ほとんどのプロジェクトでは複数のソリューションを使用します。ソリューションアーキテクトは、ソリューションを更新する際や複数のソリューションがインストールされている際のマージ動作やコンポーネントへの影響を理解する必要があります。

次の例では、Common Data Model 医療向けアクセラレータ、Contoso Common ソリューション、およびアプリを含む階層化された 2 つのソリューションを含む、4 つのソリューションが使用されています。たとえば、Common Data Model 医療向け拡張機能では、連絡先フォームがカスタマイズされています。同じフォーム要素が、Contoso Common ソリューションでは変更されています。ユーザーには、Contoso Common ソリューションからの変更が表示されます。

ソリューション階層の例を示す図。

ソリューションの構造

以下に、ソリューション作成のための戦略を、最も簡単なものから最も複雑なものまで一覧表示したものを示します。

単一のソリューション
複数のソリューション
共有コンポーネントを含む複数のソリューション

単一のソリューションを作成することで、使用できるカスタマイズセットを確立することができます。このアプローチを使用することで、カスタマイズした項目を簡単に見つけることができます。さらに、管理ソリューションを 1 つだけ作成する場合もこの方法をお勧めします。将来、ソリューションを分割する必要がある可能性がある場合は、複数のソリューションの使用を検討してください。

コンポーネントを共有しない 2 つの関連しないソリューションがある場合、最も直接的なアプローチは、2 つのアンマネージドソリューションを作成することです。

複数のソリューションでコンポーネントが共有されている場合もあります。複数のソリューション内に特定の共通機能があり、その共通の機能が各ソリューションに固有のその他の機能と互換性を持つ場合もあります。ソリューションに対するすべての変更が、使用される他のすべてのソリューションと互換性がある場合、一部のコンポーネントを複数のソリューションに含めることができます。すべてのソリューションで同じソリューション発行者を共有することが重要です。ソリューション発行者が同じでない場合、複数のソリューションをインストールすることはできません。

ソリューションでは、次のルールに従います。