注
コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engageコミュニティに参加し、最新のディスカッションに参加するには、 Finance and Operations Viva Engage Community へのアクセス権フォームに入力し、参加するコミュニティを選択します。
アプリケーション スタックは、プラットフォーム モデルとアプリケーション固有のモデルに分割されます。 プラットフォーム モデルは、アプリケーション プラットフォーム、アプリケーション基準、そして Test Essentials です。 アプリケーション固有のモデルは多数存在します。 いくつかの例として、アプリケーション スイート、元帳、小売、そしてケース管理があります。
概要
アプリケーション スタックとサーバー アーキテクチャは、次の 3 本の主要な柱に対応します。
- 新しいクライアント
- クラウドの準備
- 新しい開発スタック
アプリケーション スタックはいくつかのモデルに分けられます: アプリケーション プラットフォーム、アプリケーション基準、Test Essentials、そしてアプリケーション スイート。 この分離により、Fleet Management サンプル アプリケーションの開発と同様に、基本基盤モデルでの新しいアプリケーション開発が可能になります。 サーバーのアーキテクチャ内の変更に関する次の重要な点に注意してください。
- サーバー上のサービス エンドポイントは、すべてのフォームとコントロールのメタデータとデータをブラウザー ベースのクライアントに返す責任があります。 サーバーとのリモート プロシージャ コール (RPC) ベースの通信はなくなりました。 フォーム オブジェクトは引き続きサーバー上で実行され、レンダリングは、サーバーとクライアント側 (ブラウザー) の投資を通じてブラウザーやその他のクライアント用に最適化されています。
- アプリケーション コード ベースを含むサーバーを、インターネット インフォメーション サービス (IIS) Web アプリケーションに展開します。 クラウドでは、Microsoft Azureサービスとしてのインフラストラクチャ (IaaS) 仮想マシン (VM) にデプロイします。
- Azureでホストされ、インターネット経由でアクセスできます。 ユーザーは、クライアントと資格情報の組み合わせを使用してアクセスできます。 推奨されるプライマリ ID プロバイダーは OrgID であり、ID のストアはMicrosoft Entra ID。 セキュリティ サブシステムは、ユーザーとロールに対して同じ AuthZ セマンティクスを使用します。
- クラウドへのアクセスには、アクティブ クライアントとパッシブ クライアントの 2 種類のクライアントを検討する必要があります。
アクティブなクライアントは、サーバーからの応答に基づいて、アクションをプログラムで開始できます。 アクティブなクライアントは認証用の HTTP リダイレクトに依存しません。 スマート クライアントまたはリッチ クライアントは、アクティブなクライアントの例です。
パッシブ クライアントは、サーバーからの応答に基づいて、アクションをプログラムで開始できません。 パッシブなクライアントは認証用の HTTP リダイレクトに依存します。 Web ブラウザーは、パッシブ クライアントの例です。
現在、Access Control サービス (ACS) では、非対話型認証のメカニズムはサポートされていません。 したがって、アクティブなクライアントが ACS を使用して認証を試みる場合でも、パッシブ クライアント認証を使用する必要があり、パッシブ クライアント認証では、ブラウザーのダイアログ ボックスに、ユーザーに資格情報の入力を求めるプロンプトが表示されます。
- 完全に改良されたメタデータ サブシステムには、新しいコンパイラとMicrosoft Visual Studioベースの開発モデルが組み込まれています。 モデル ストアは、モデルによって編成された一連のフォルダーと XML コンポーネントとして表されます。 XML ファイルは、テーブル、フォーム、クラスなどのモデル要素を表し、メタデータとソース コードの両方が含まれています。
次の図は、アプリケーション スタックを個別のモデルに分割する方法を示しています。 また、主要コンポーネントがサーバーでどのようにスタックされているかも示します。
財務と運用アプリケーションは、エントリ ポイントのセキュリティ モデルを使用します。 フォームへのナビゲーションに使用するメニュー項目に読み取り権限しかない場合、フォームは読み取り専用アクセスを提供します。 ただし、作成アクセス許可、削除アクセス許可、または更新アクセス許可を提供する別のメニュー項目を使用して、同じフォームに移動すると、フォームに対する書き込み操作が許可されます。 開発者は、特定のエントリ ポイントからフォームの動作を指定できるため、この動作は開発の経験を簡素化します。
クラウド アーキテクチャ
クラウド アーキテクチャには、ソフトウェアの展開とプロビジョニング、運用の監視とレポート、およびシームレスなアプリケーション ライフサイクル管理を自動化するサービスが含まれます。 クラウド アーキテクチャは、3 つの主な概念領域で構成されています。
- Microsoft Dynamics ライフサイクル サービス – ライフサイクル サービスは、ライフサイクル関連のさまざまな機能を可能にするマルチテナント共有サービスです。 このリリースに固有の機能には、ソフトウェア開発、顧客プロビジョニング、サービス レベル アグリーメント (SLA) の監視、およびレポート機能が含まれます。
- Finance and operations – ライフサイクル サービスを通じて VM インスタンスをAzure サブスクリプションにデプロイします。 デモ、開発/テスト、高可用性の運用トポロジなど、さまざまなトポロジが利用できます。
- 共有されたMicrosoft サービス – 財務および運用用アプリケーションは、顧客が財務および運用全体、Microsoft 365、その他のオンライン サービスにわたるMicrosoftとのシングル サインイン、サブスクリプション管理、課金関係を一元管理できる「One Microsoft」ソリューションを実現するために、いくつかのMicrosoft サービスを使用します。
Azure プラットフォームの多くの機能、例えば Microsoft Azure Storage、ネットワーク、監視、SQL Azure などを、このアーキテクチャでは活用しています。 共有サービスが運用され、参加者の環境のアプリケーション ライフサイクルが管理および調整されます。 Azure機能とライフサイクル サービスを組み合わせることで、堅牢なクラウド サービスが提供されます。
開発環境
開発環境のアーキテクチャは、クラウド インスタンスのアーキテクチャに似ています。 また、Visual Studio開発ツールやその他のコンポーネントで構成されるソフトウェア開発キット (SDK) も含まれています。 Team Foundation Server または Visual Studio Online を使用したソース管理により、開発者ごとに異なる開発環境を使用する複数の開発者シナリオが可能になります。 ライフサイクル サービスを使用して、開発環境でデプロイ パッケージをコンパイルして生成し、クラウド インスタンスにデプロイできます。 次の図は、主要なコンポーネントが開発環境でどのようにやり取りするかを示しています。
