制限される例
2 つのテーブル (Customer と Order) があり、その関係が 1 対多であるとします。つまり、Customer は多数の注文を持つことができます。
したがって、親テーブル ie(Customer) で、Order テーブルの削除アクション プロパティを「RESTRICTED」に設定するとします。次に、Customer テーブルからレコードを削除するとします。まず子テーブル内のレコードをチェックし、存在する場合は、最初に子テーブルからレコードを削除する必要があることを示す警告プロンプトが表示されます。
不正解:
B: カスケードの例:
2 つのテーブル (Customer と Order) があり、その関係が 1 対多であるとします。つまり、Customer は多数の注文を持つことができます。
したがって、親テーブル ie(Customer) で、Order テーブルの削除アクション プロパティを「CASCADE」に設定するとします。次に、Customer テーブルからレコードを削除するとします。また、Order テーブル内のすべての関連レコードも自動的に削除されます。
C: カスケード + 制限付きの例
3 つのテーブル ( person 、Customer 、 Order) があるとします。 person は Customer テーブルの親であり、 Customer は (1 対多) 関係を持つ Order テーブルの親です。 Person テーブルの削除アクション プロパティを " に設定すると、 customer テーブルの場合は CASCADE"、Order テーブルの CUSTOMER テーブルの削除アクション プロパティを "CASCADE +RESTRICTED" に設定した場合。
したがって、Customerテーブルからレコードを削除すると、最初に子テーブル（注文テーブル）のレコードがチェックされ、存在する場合は、最初に子テーブルからレコードを削除する必要があるという警告プロンプトが表示されます。
ただし、Person テーブルからレコードを削除すると、Customer テーブルのレコードも自動的に削除され、Order テーブルの customer テーブルに関連するすべてのレコードも削除されます。
参照：
https://amazingax.wordpress.com/2013/01/13/microsoft-dynamics-ax-2012example-of-cascaderestricted-and-cascade-restricted-delete-action-property-for-a-table-relation/ 開発者ツールテストレット 1 ケーススタディ これはケーススタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
背景
Wide World Importers は、事務用品、家具、備品を米国全土の顧客に販売しています。
同社には次の拠点があります。
* シアトルの小売店
* シアトルの倉庫
* アトランタのカスタマー サポートおよびコールセンター
* 顧客サイトで家具の設置サービスを提供するフィールド ワーカーのチーム。
Wide World Importers は、Dynamics 365 Finance と Microsoft Azure クラウド プラットフォーム機能を実装する予定です。
現在の環境
顧客は、電子メール、電話、または会社のウェブサイトを使用して注文できます。同社は、Web ベースのアプリケーションを使用してクレジット カード取引を承認および処理します。顧客、在庫、サプライヤー、その他のマスター データとトランザクション データは、レガシー データベースに保存されます。
同社は、電話または会社 Web サイトのフォームを通じて顧客からのフィードバックを収集し、データを Microsoft Excel ブックに保存します。
Wide World Importers は、オンプレミス アプリケーションを実行して給与と労働者補償を管理します。同社には、レポート データベースのデータを表示する一連の Microsoft Power BI ダッシュボードがあります。
会社はライフサイクル サービス (LCS) 実装プロジェクトを作成し、Dynamics 365 Finance のオンボーディングを完了します。
同社は、実稼働、品質保証 (QA)、開発、ユーザー受け入れテスト (UAT)、および構築環境を維持しています。
要件
一般的な
* クラウドベースの Dynamics 365 Finance 開発環境を構成し、更新をサポートするコード拡張機能を有効にする必要があります。
※バージョン管理とビルド環境の設定が必要です。
* すべてのレガシー データを新しいシステムに移行する必要があります。
* X++ コーディング、データ モデル、キャッシュ、セキュリティのベスト プラクティスを実装する必要があります。
* すべての新しいコードは開発環境で単体テストされ、コードがソース管理に追加される前に QA チームによって検証される必要があります。
ビジネスプロセス
* ベンダー取引契約を構成する必要があります。
* 間接コストを節約するために、顧客の所在地に応じて製品はサプライヤーから顧客に直接発送される必要があります。
* ベンダーから直接出荷される製品については、顧客のフィードバックを収集する必要があります。
* コードを運用環境にデプロイする前に、テストのためにコードを UAT 環境にデプロイする必要があります。
* 注文書作成フォームのすべての入力内容を検証する必要があります。
* 顧客が製品を閲覧し、注文し、注文状況を確認できる Web ポータルを開発する必要があります。Web ポータルの製品データは、定期的なバッチとして統合する必要があります。
業務システム
* Dynamics 365 Finance 内でクレジット カードを処理するためのサードパーティ ソリューションをインストールして構成する必要があります。サードパーティ企業は展開可能なパッケージを提供します。
* 労働者補償アプリケーションは、API を呼び出して、Dynamics 365 Finance の労働者補償の詳細を更新できる必要があります。
* 給与仕訳帳をシステムにインポートするプロセスを開発する必要があります。
* 倉庫業務用に倉庫モバイル デバイス ポータルを設定する必要があります。
* Web ポータルの統合をサポートするには、サードパーティのソリューションをインストールする必要があります。ソリューションはソース コード モデル ファイルとして提供されます。
ベンダー除外リスト
顧客と品目の組み合わせごとにベンダー除外リストを管理するには、新しいソリューションを開発する必要があります。
ソリューションは次の要件を満たす必要があります。
* VendExclusions という名前のテーブルを作成して、すべての新しいベンダー除外コードを新しいアセンブリとして分離します。
* 次のフィールドを使用する PrimaryIdx という名前のテーブルのインデックスを作成します: CustAccount、ItemId、VendAccount。
* ユーザーが顧客マスター フォームからベンダー除外リスト レポートを開くことができることを確認します。リストには、顧客アカウント、アイテム ID、およびベンダー アカウントのフィールドが表示される必要があります。
* ベンダー除外リスト フォームの Excel 統合を実装します。
* Dynamics 365 Unified Operations の標準レポート機能を使用してレポートを準備するために、ベンダー除外リストを定期的にエクスポートする機能を提供します。
* 新しいベンダー除外リストの機能とレポートを表示および維持するために必要なセキュリティ権限を開発します。保守権限を持つユーザーは、除外リストを作成、更新、削除できます。
企業のセキュリティ モデルに一致するように、セキュリティ ロールに権限を割り当てる必要があります。
* 他のテーブルとの参照整合性を維持します。
* 除外リストにあるベンダーに対して直接配送の発注書を作成する前に、ユーザーに警告メッセージが表示される必要があります。
* 新しい除外レコードがシステムに追加された場合、営業マネージャーに警告する必要があります。
安全
* レコードを作成したユーザーを識別するには、レコード レベルの監査機能を実装する必要があります。
* Excel を使用してベンダー除外リストを管理する権限を特定のユーザーに付与します。
* 提案された直送発注ベンダーが顧客と製品の組み合わせの除外リストに含まれているかどうかを確認する検証を実装する必要があります。
問題
User1 はシステム内の多くの機能にアクセスできません。User1 に管理者権限を与える必要があります。
営業マネージャーは、ベンダー除外リストにデータ関連の問題があると疑っています。User1 は、参照された除外レコードを作成したユーザーを識別する必要があります。
Developer2 は会社に入社しましたが、開発環境やソース管理にアクセスできません。
User2 は、現在の更新を適用した後に直接配送の注文書を生成するときにパフォーマンスの問題を報告します。
User2 は、新しい機能とレポートにアクセスできないと報告します。

参照：
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/get-started/personalize-user- experience

Explanation:
ボックス 1: はい
キャッシュにより、表示メソッドの不必要な実行が回避されます。
表示メソッドのパフォーマンスを向上させるために、メソッドをキャッシュできます。
ボックス 2: いいえ
ボックス 3: いいえ
ボックス 4: いいえ
参照：
https://docs.microsoft.com/en-us/dynamicsax-2012/developer/using-the-display-method-modifier

説明
グラフィカル ユーザー インターフェイス、テキスト、アプリケーションの説明が自動生成される

参照：
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/analytics/customize-app-suite-reports-with
https://community.dynamics.com/ax/b/dynamics101trainingcenterax/posts/developing-a-ssrs-report-using-the-re

Explanation: