次の方法で共有


分割されたモデル

コミュニティの関心グループが Yammer から Microsoft Viva Engage に移りました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、Finance and Operations Viva Engage Community へのアクセスを要求するフォームに入力し、参加するコミュニティを選択します。

この記事では、アプリケーション プラットフォーム、Application Foundation、Application Suite の 3 つの主要なモデルにスタックを分割する方法について説明します。

概要

モジュール コードを開発することは、モデル分割の原動力です。 スタックを複数のモデルに分割すると、コンパイル時間の短縮や運用環境でのパートナー IP の違いなど、多くの利点があります。 3 つの主要なモデルは、 アプリケーション プラットフォームApplication Foundationおよび Application Suite です

Application Platform、Application Foundation、Application Suite を示す 3 つの主要なモデルのスクリーンショット。

アプリケーション プラットフォームは最下位モデルであり、カーネルとやり取りする最下位レベルの要素が含まれています。 アプリケーション オブジェクト サーバー (AOS) は、アプリケーション プラットフォームのみを使用して起動できます。 Application Foundation はアプリケーションプラットフォームの上にあり、すべてのアプリケーションが共有するフレームワーク機能が含まれています。 最後に、アプリケーション スイートアプリケーション基準の上部に位置し、アプリケーションの特定要素を含みます。 付録のモデル内訳表は、これらの各モデルのコンポーネントの例を示します。 各モデルは、下位レイヤー モデル アセンブリへの依存関係を持つ独自のアセンブリにコンパイルされます。 アプリケーション プラットフォームは、他のモデルに依存しません。 この構造体は、モデルをアセンブリに直接マッピングすることを意味します。

モデルからアセンブリへのマッピング図のスクリーンショット。

モジュール スタックで開発することで、アプリケーション スイートで変更を行い、残りのスタックに触れることなくコンパイルすることができます。 新しい変更を加えてモデルをコンパイルするだけで、コンパイル時間が大幅に短縮されます。 詳細については、「モデルの 内訳」を参照してください。

モデルのカスタマイズ

オーバーレイと拡張機能の 2 つの方法を使用してモデルをカスタマイズできます。 オーバーレイでは、下位レベルのモデルの要素を変更またはオーバーレイする複数のレイヤーで変更を行うことができます。 拡張機能では、新しい要素の追加、または要素イベントまたはプラグイン ポイントへのコードのアタッチがサポートされています。 使用するカスタマイズの種類は、モデルのコンパイルとパッケージ化方法に影響します。 1 つ以上のモデルがアセンブリにコンパイルされます。 アセンブリ、そのコード以外のメタデータ、およびコンパイルされた成果物がパッケージを形成します。 パッケージは、独立した配置可能な単位です。 拡張機能のカスタマイズのみを含むモデルを独自のアセンブリにコンパイルし、独自のパッケージに配置できます。 任意のオーバーレイが含まれるモデルは、オーバーレイ モデルに基づいてアセンブリにコンパイルする必要があります。

拡張機能とオーバーレイ パッケージを示すカスタマイズ アセンブリのスクリーンショット。

拡張機能の使用には、以下を含むいくつかの利点があります。

  • アプリケーション ライフ サイクル管理の目的で、拡張コンポーネントのみを管理する必要があります。
  • カスタマイズの構築ではアプリケーション全体を再コンパイルする必要はありません。
  • クラウドで Microsoft はユーザーのカスタマイズに影響を与えずに、インストール、パッチ、アップグレード、および内部 API の変更を行えます。
  • 他のカスタマイズを意識せずに、ソリューションを別々に処理することができます。

現在、システムはコード拡張、テーブル拡張、フォーム拡張、メニュー拡張、および列挙型拡張をサポートしています。 拡張機能とオーバーレイによるカスタマイズと拡張機能によるモデル要素のカスタマイズに関するセクションでは、拡張機能の使用方法について詳しく説明します。 可能な限り、サポートされている要素に拡張機能を使用します。 既存の Microsoft コードを変更する必要がない場合は、拡張機能を使用します。 変更を使用してメソッドの機能を変更するには、オーバーレイを使用する必要があります。 拡張機能がカバーしていない領域や、カスタマイズによって基本機能が変更される場合は、オーバーレイを使用します。 次の図は、2 つのカスタマイズ戦略の違いをまとめたものです。

拡張機能とオーバーレイ戦略を比較するカスタマイズの概要のスクリーンショット。

モデルの内訳

モデル 概念
アプリケーション プラットフォーム アプリケーション ロジックに対応するカーネル機能へのアプリケーション プラットフォーム インターフェイス。 AOS は、このモデルだけで開始することができます。
- AIF 基本オブジェクト
-バッチ
- フォームの基本オブジェクト
- RunbaseSysOperations* 基本オブジェクト
- DictXX オブジェクト
- Appl、Info、Global、ClassFactory
- データ アクセス オブジェクト
- ヘルパー クラス
- ENUM/EDT/Macros/ConfigKey/LicenseCode
アプリケーション基準 - アプリケーション基盤の機能: ディメンション フレームワーク、グローバル アドレス帳、番号シーケンス、OrgModel
- 機能領域: ビジネス インテリジェンス、レポート、アップグレード フレームワーク、セキュリティ、E 署名、データのインポート/エクスポート、ワークフロー
- SYS オブジェクト: ベスト プラクティス、CheckList、Policy、RecordTemplate
- その他: 通貨、測定単位
アプリケーション スイート - サプライ チェーン管理
- 人的資本管理
- プロフェッショナル サービスなど