オーバーレイから拡張機能への移行
概要
アプリケーションの最初のリリース時に、カスタマイズのオーバーレイの代わりに拡張機能を使用することを強くお勧めしました。 オーバーレイヤーに基づくカスタマイズは、コードの移行を通じてリリースごとに移行され、アプリケーション コードの多くのカスタマイズは引き続きコードのオーバーレイヤーがベースとなります。 ほとんどのパートナーについては、少なくともソリューションの一部が引き続きオーバーレイに基づいており、および一部のパートナーはソリューション間でたくさんのオーバーレイを持ちます。
オーバーレイ コードから拡張への実装を変更するために必要な作業の金額は、そのコード自体によって異なります。 いくつかのオーバーレイヤーされたコードは、比較的シームレスに変更できます。 ただし、いくつかの変更については、拡張機能によりそれを達成できるよう適切な方法を見つけるためのカスタマイズを再考する必要があります。 したがって、複数の場所にコードが重複している場合、完全なソリューションを変更することが大きな課題になる可能性があります。 このような仕事には、ソリューションへの投資が必要です。 カスタマイズは現在、拡張を介したアプリケーション プログラミング インターフェイス (API) に基づいているため、この投資のメリットはよりシームレスなアップグレード プロセスにあります。 また、オーバーレイ コードの場合と同様に、長いコード アップグレード プロセスは不要になりました。 さらに重要なことに、実行中の環境を日々保守すると多くの利点があります。 コア アプリケーションと拡張機能をまとめてコンパイルする必要がなくなり、プリ コンパイルされたアセンブリをデプロイすることでパッチを適用することができます。 したがって、顧客は比較的シームレスにシステムにパッチを適用することができ、ダウンタイムの量は最小限に抑えられます。 ただし、この結果が得られる前に行う必要がある作業があります。
このタスクには複数の方法がありますが、既にオーバーレイから拡張機能に移行を開始した独立系ソフトウェア ベンダー (ISV) および付加価値再販業者 (VAR) との緊密な連携を通じて経験を積んでいます。 この記事ではエクスペリエンスの一部を共有します。
重要なものから順番に
今後の課題はかなりあり、私たちは共有投資が配当を支払うことを確実にしたいと考えています。 カスタマイズを通じて作業するため、目標に注意してください。 カスタマイズが正しく完了したとき、ソリューションには次の品質が含まれます。
- 侵入的なカスタマイズはありません。
- 他の ISV ソリューションと横に並べる配置をサポートします。
- Microsoft コードでの変更に対して復元力があります。
- その他の ISV ソリューションでの変更に対して復元力があります。
- 今後のバージョンに自動的にアップグレードすることができます。
この種のカスタマイズは、アプローチが根本的に変化することを表しています。 以前は、主な目的は、現在のバージョンで機能の要件を実装するためのものでした。 ソリューションをアップグレードするために手動作業が必要であることがわかっていたため、この目標は受け入れられました。 以前は、優れたエンジニアは、手動アップグレード コストを最小化していました。 現在は、各エンジニアがアップグレードの労力をゼロにするソリューションを実装する必要があります。
適切なパスに残る
自動車は安全であるように設計されています。 ただし、まだ事故を防ぐことはできません。 事故防止は、ドライバーの責任です。 同様に、拡張機能用に開発ツールセットが設計されています。 ただし、侵入的なカスタマイズのすべてのタイプを防ぐことは、ツールセットにはまだできません。 エンジニアとして、侵入的なカスタマイズを回避することは職責です。
場合によっては、煩雑なカスタマイズを実装することによってのみ、機能の目標に到達できることがわかる場合があります。 この場合、正しい解決策を見つけるために Microsoft に問い合わせる必要があります。 ご自分のやり方で進めないようにしてください。 それ以外の場合、たとえば、自動アップグレード後にサービスの停止が発生した顧客が、ソリューションに結局将来性がないことに気づく可能性があります。
将来性のあるソリューションは競合の利点を表しているため、それを正しく行うための特別な努力は価値があります。
コードの概要の取得
コードの概要を作成するときは、ソリューションをまとめて分析するのではなく、各ソリューションの分析をまず検討します。 この方法は、さまざまなチームが個々のソリューションで作業している場合でも実用的な場合があります。 他のチームよりも前に関与するチームを 1 つ選択することで、いくらか経験を積むことができます。 経験は、作業を分析し計画するのに役立つだけでなく、チームがランプアップして拡張性モデルに慣れることにも役立ちます。 したがって、あなたとあなたのチームが得た経験は、後のソリューションにも適用できる貴重な「教訓」となります。
各 ISV ソリューションを順番に実行する ISVと、VAR として機能して顧客のソリューションを後で実行する ISV の両方について、実際的な経験を得ました。
どのような形で作業がソリューションにまとめられていても、カスタマイズ分析のレポート (CAR) を使用してオーバーレイされたものに関する情報を取得できます。 このレポートは、Microsoft Dynamics Lifecycle Services (LCS) のコード移行ツールにソリューションを提出すると生成されます。 レポートは Microsoft Excel 形式で、重複したコードを持つすべての場所の一覧が含まれています。 レポートを使用すると、ソリューションのすべてのオーバーレイ インスタンスの分析と分類の両方をすることができます。
概要を得るには、オーバーレイヤーされたそれぞれのインスタンスを分類すると便利です。 オーバーレイされたインスタンスに適用するカテゴリは、カスタマイズを拡張に変更するために必要なおよその労力を表す必要があります。 いくつかのカスタマイズは、拡張機能に簡単に変更されます。 ただし、その他のカスタマイズについては、変更がより難しくなります。
さまざまな ISV を操作する経験から、次のカテゴリが良い出発点であることがわかりました。
| カテゴリ | 説明 |
|---|---|
| 拡張可能な列挙 | 拡張機能を使用して新しい列挙値を追加することができます。 詳細については、拡張機能による列挙への値の追加を参照してください。 |
| throw による構築 | ほとんどのコンストラクト メソッドは単純で、ポストイベント ハンドラーを使用して拡張することができます。 ただし、一部の construct メソッドはより複雑であり、クラスを作成していないとき例外をスローします。 |
| メンバーを公開 | 定義にプライベートのアクセス修飾子があるメンバー変数は、パブリック メソッドを通じて公開されない限り、拡張機能を通じてアクセスできません。 このために現在公開されていない拡張を通じて、メンバーに対するアクセス許可の追加を要求することができます。 保護されたメンバーへのアクセスは通常、拡張クラスを通じて有効になることに注意してください。 |
| DataEvents を発生させないデータ操作メソッド | アプリケーションの一部の場所では、insert() および update() などのデータ メソッドは super() を呼び出しません。 したがって、これらのメソッドは、拡張機能を追加する DataEvents を生成しません。 Microsoft は、これらの場所で拡張機能を有効にする追加のメソッドが含まれるように、標準のアプリケーションのリファクターを計画しています。 これを追加するために Microsoft の要求を送信する場合は、それらのメソッドがまだ転記されていない場合は、現在オーバーレイする必要がある影響を受けるメソッドのいずれかを追加します。 |
| メソッドの抽出 | このカテゴリは、コマンドの連鎖ではできないメソッドの途中でのコード変更用です。 メソッドの抽出を要求するときは、抽出するメソッドの行と、新規メソッドの署名を何にする必要があるかをかならず指定します。 |
| SQL ステートメント操作 | アプリケーション コードで直接記述されている SQL ステートメントは、拡張機能を有効にしません。 これらの SQL ステートメントの拡張を要求するときは、フィールド一覧、WHERE 句、または注文などの、拡張を必要とする内容を明示的に指定していることを確認します。 |
| メタデータのオーバーレイ | メタデータ (プロパティ値) を変更する必要があると思われる要素のアプリケーション オブジェクト ツリー (AOT) のパスを提供します。 メタデータの変更は、現在の拡張機能を通じて行うことはできません。 |
| メソッドのオーバーレイ | このカテゴリは、メソッドがオーバーレイされているカスタマイズのためのものです。 代替機能ではなく拡張機能ごとに変更がクリーンになるように、オーバーレイ メソッドを拡張機能に変換することを検討してください。 |
| メソッド シグネチャの変更 | オーバレイによるメソッド シグネチャの変更機能は廃止されます。 同様の結果を実現するための他のパターンが必要です。 拡張性をサポートするために、標準シグネチャへの変更を要求することができます。 必要な追加パラメーターについての情報が含まれていることを確認します。 |
| 在庫分析コード | マクロを編集および標準アプリケーションのコンパイルでは、分析コードを追加することができなくなりました。 実行時に配置される定義済分析コードに関連する別の方法が提供されます。 この方法では、新しいディメンションが追加される既存のカスタマイズに対する変更が行われます。 |
| 拡張性プラットフォーム | いくつかのカスタマイズは、新しいプラットフォーム機能が追加されない限り、拡張機能から使用できない場合があります。 カスタマイズが拡張機能を通じて現在実行できないと判断した場合は、シナリオと必要な内容を説明する拡張依頼を開きます。 |
| レポート | レポート デザインのカスタマイズでは、拡張性のサポートが限られています。 一般に、新しいレポートを作成する必要があります。 データ プロバイダー クラスは、追加情報を含むようにカスタマイズすることもできます。 一部の場所では、標準のアプリケーションを変更して、このタイプのカスタマイズを有効にする必要があります。 |
| 外 | このカテゴリは、他のカテゴリに収まらないインスタンスをオーバーレイするためのものです。 |
オーバーレイするすべてのコードを分類することによって、変更が必要な対象の概要を得ることができます。
影響の分析と作業の見積もり
作業の影響を評価する標準的なアプローチでは、タスクを具体的なものに分割します。 この方法はこの作業にも当てはまります。 前のセクションで説明したカテゴリは、同様のカスタマイズをフレームするのに役立ちます。また、これらのカテゴリおよびソリューションを構成する同様のカテゴリの全体的な見積もりを作成することで、見積もりの最初のパスを構築できます。 指定したカテゴリのカスタマイズ グループには、いくつかの点で優れていることが多く、これらのカスタマイズの見積もりを個別に確立することが適切な場合があります。
一部のカスタマイズでは、拡張性を有効にするために Microsoft への要求、または拡張性を介して行うことができるようにカスタマイズの大幅なリファクタリングが必要になることを考慮してください。 これらの両方のシナリオはソリューションを移行するための見積を増加させます。
侵入的な変更を実行するカスタマイズは、拡張機能に変換する場合、より複雑な場合があります。 これらの変更については、カスタマイズにアプローチする正しい方法を考慮する必要があります。 これらの変更の例を次に示します。
- インライン デリゲートを要求するカスタマイズ。
- SalesLinetype のような、複雑なクラスまたはメソッドのカスタマイズ。
- メソッド シグネチャの変更。
- 在庫分析コードの追加。
- レポート定義およびレポート データ プロバイダー クラスの変更。
- フォームへの侵入的な変更。
カスタマイズを拡張ベースにするための異なるアプローチが必要な変更については、拡張機能を有効にするため Microsoft にログ要求をする必要があります。 移行スケジュールを作成するとき、Microsoft からの更新プログラム待ちの遅延を考慮する必要があります。
何がサポートされるか、また何が拡張機能を必要とするか ?
カスタマイズを確認するときは、カスタマイズを拡張機能へ変換するための各種オプションをかならず考慮してください。 フック可能なメソッドかどうか、またはクラス拡張かフォーム イベントかどうかを必ず考慮してください。 使用できる現在使用可能なアプリケーション コードの大部分を確認します。
必要な拡張子を有効にするために、標準アプリケーションへの変更が必要であると結論付ける可能性があります。 この場合は、 拡張機能の要求を記録 する必要があります。 この要求は対処できるように Microsoft のバックログに配置されます。 Microsoft は修正プログラムの機能拡張要求を解放しないので、修正プログラムの要求を開いて、拡張機能の要求をログないでください。
拡張機能の要求には十分なコンテキスト情報を供給してください。 たとえば、インライン デリゲートの要求が、現在のカスタマイズ アプローチから来る可能性があります。 ただし、より適切な拡張を行うため、このカスタマイズにつながなる要求は、標準アプリケーションへの構造的な変更によってより効果的になる可能性があります。 この種のご提案は、アプリケーションをさまざまなカスタマイズを構築するためのより良いプラットフォームに近づけることに役に立ちますのでよろしくお願い致します。
移行の計画
早期にソリューションの移行を計画開始してください。 この計画は、機能拡張要求を識別してログに記録するためのスケジュールに余裕があること、およびこれらの要求が製品リリースで利用可能になるまでの時間の余地があることを確認するのに役立つので重要です。 また、開発者は、新しいスキルをビルドする可能性があることに同意し、移行計画の一部として必要な学習に対応するかどうかを確認してください。
ソリューションに、拡張機能を通じて簡単に対応できない侵入的なカスタマイズが含まれていることがあります。 このようなカスタマイズの業務の値が拡張機能を通じて構築する手間を上回るかどうかを検討してください。 場合によっては、パートナーが拡張機能を通じてパーツを再構築することが困難で、それらのパーツはソリューションにとって重要ではないため、ソリューションのパーツを中止することを決定しました。
アプリケーション全体でカスタマイズする小規模な修正プログラムの一部は、ソリューションのコアでない場合がありますが、関係するユーザーにとって重要です。 そのような場合、標準アプリケーションに類似の機能を実装するよう Microsoft に依頼するほうがよいかどうかを決定する必要があります。 この目的のために拡張性要求を入力することができます。 たとえば、顧客がシステムでの標準の業務プロセスを簡略化する場合、標準のアプリケーションでプロセスの手順を無効にするためのオプションを追加するよう、提案する可能性があります。