Dynamics 2011 - ベースライブラリソリューションにはどうすればよいですか？

Question

私は、solutionsを編成するためのベストプラクティスのアプローチを整理しようとしています。具体的には、「ベースソリューション」または「ライブラリソリューション」に含めるべきものがあります。

SDKには、次の言葉：複数のソリューションや大 エンタープライズ展開とISVのために

ソリューションライブラリが、それは多くのソリューションコンポーネントが を共有する必要があります を期待されています。 ソリューションがコンポーネントを共有する最適な方法は、 ソリューションライブラリを作成することです。あなたは別の 組織に 非管理ソリューションを作成することにより、 ソリューションライブラリを作成して、管理対象の溶液に、これらの コンポーネントをパッケージ化します。 別の組織に管理ソリューションをインストールし、 開発者が作成 ソリューションからこれらの共有 コンポーネントを参照しましょう 。

のMicrosoft Dynamics CRMソリューション フレームワークを使用すると、お互いに依存し ソリューションの層を構築することができます。 通常、 "基本" ソリューションを表すソリューション ライブラリを作成します。他のソリューションは、この基本ソリューションの上に を構築することができます。

ベース/ライブラリソリューションにはどのコンポーネントを配置するのが理想的ですか？コアビジネスエンティティとオプションセット？コア機能とワークフロー？

ダイナミクスのドキュメントに関する多くのガイダンスはないようです。

Answer 1

あなたがあなたの組織の残りの部分とは別にrevisionedされる複数の組織間で共有する予定のすべての機能を持っている場合は、私は別の溶液中にそれを入れて検討します。例えば

は、あなたがそれぞれ独自のCRM組織を持つことになりますあなたのビジネスで複数の領域を持っていると言うが、それらのそれぞれは、スコアリングおよび割り当てリードの標準的な方法を使用しています。このシナリオでは、その機能を包含するソリューションを作成して各組織にインストールし、プロセスが変更されたときに、同じソリューションをすべての組織にプッシュして、すべてのユーザーに同じ変更が適用されるようにします。

もう一つの可能​​性は、あなたが多分autonamingまたは自動番号の記録、またはいくつかのカスタムビジネスロジックの検証のようなもののために、複数の組織間で使用したいJavaScriptライブラリやプラグインの共通セットになります。その方法でバグが見つかった場合、同じ変更をすべての組織に適用することができます。

あなたは複数のCRM組織を持っていないか、ISVていない場合、私は解決策を気にしないだろう。彼らはCRMにとって大きな飛躍を遂げていますが、それは間違いなく最初の回りであり、それらを扱う際のいくつかの癖や頭痛があります。