DISPLAY SETTINGS 各種設定
Q1.あるソフトウェア ベンダーが Dynamics 365 Supply Chain Management 向けの新しいソリューションを構築しています。
このソリューションは、各顧客が自社の実装環境で利用できるように提供されます。
ソリューションに含まれる一部のクラスは、顧客が固有の要件に合わせて別の実装から拡張できるよう設計されています。
あるメソッドについては、ビルド プロセスの実行中に出力ウィンドウへ表示し、他の開発者へその意図を伝える必要があります。
このメソッドに対して適切なステートメントを実装しなければなりません。
何を実装すべきでしょうか。
解答を見る
X++ の属性（アトリビュート）は、クラスやメソッドに付与できるメタデータで、コンパイラやリフレクションから参照して処理できます。
ビルド時に特定のメソッドについて通知や警告を出し、他の開発者へ意図を伝えたい場合は、コメントや info() 関数ではなく 属性による宣言 が適しています。
Supply Chain Management の開発は Finance & Operations アプリ共通の X++ 開発基盤を用いるため、メソッド単位のメタデータ として属性を実装します。
X++ 属性クラス – Finance & Operations | Dynamics 365
Q2.あなたは Dynamics 365 Finance and Operations のカスタム開発を担当しています。
既存のモデルには、メモリ内テーブル、データ プロバイダー クラス、コントローラー クラス、契約クラスに接続するレポートが含まれています。
このレポートは変更できないようロックされています。
モデル内にメモリ内テーブルの拡張を作成し、その拡張へ新しいフィールドを追加する必要があります。
どの 3 つのアクションを、どの順序で実行すべきですか。
アクションの一覧から適切なものを選び、正しい順序で並べてください。
左の「選択肢」から必要な数を右の「回答エリア」へドラッグ（またはタップ）。回答エリア内でドラッグして順序を入れ替えられます。
- モデル内のレポートを複製し、複製したレポート デザインに新しいフィールドを追加します。
- モデル内の既存レポート コントローラー クラスの拡張を作成し、クラス ロジックを更新して新しいレポートを参照させます。
- モデル内の既存データ プロバイダー クラスを複製し、新しく追加したフィールドに値を設定するようクラスを更新します。
- モデル内の既存レポート コントローラー クラスを複製し、クラス ロジックを更新して新しいレポートを参照させます。
- モデル内の既存データ プロバイダー クラスの拡張を作成し、新しく追加したフィールドに値を設定するようクラスを更新します。
- ここへドラッグ
解答を見る
ロックされた標準レポートは直接変更せず、拡張モデル側で対応します。
まず対象レポートのデザインを複製し、追加するフィールドを配置します。
次に レポート コントローラー クラスを拡張 して、実行時に複製した新しいレポートへリダイレクトさせます。
最後にデータ プロバイダー クラスを拡張し、拡張ポイントやイベント ハンドラーを用いて 追加フィールドへ値を設定 します。
複製で置き換えるのではなく拡張を用いる点が、アップグレード耐性の観点で重要です。
アプリケーション スイート レポート データ セットを展開する – Finance & Operations | Dynamics 365
Q3.Dynamics 365 Finance のフォームを開発している状況です。
そのフォームに、ユーザーがレポートを実行できるボタンを追加する必要があります。
解決策: 出力メニュー項目を作成します。
作成した出力メニュー項目をフォーム ボタンに割り当て、レポートをその出力メニュー項目にリンクします。
この解決策は目標を達成できますか。
解答を見る
Dynamics 365 Finance のフォームからレポートを実行させる場合、フォーム ボタンにはメニュー項目を関連付けます。
レポートの起動を目的とする場合は 出力メニュー項目 を使用し、その出力メニュー項目で対象のレポートやレポート デザインを指定します。
したがって、出力メニュー項目を作成してフォーム ボタンに追加し、レポートへリンクする構成は 目標を満たす正しい方法 です。
そのため解決策は「はい」となります。
アプリケーション エクスプローラーのプロパティ – Finance & Operations | Dynamics 365
Q4.クラウド ベースの Dynamics 365 Finance 環境を次のように用意しています。
「開発」環境は Visual Studio ワークスペースが構成され、Azure DevOps ブランチに接続されています。
「ビルド」環境はビルド パイプラインが構成されています。
「標準受け入れテスト」環境はカスタマイズを検証するためのサンドボックスです。
開発者は開発環境でコード拡張を作成し、その変更を Azure DevOps ブランチにチェックインします。
これらのコード変更を標準受け入れテスト環境へデプロイする必要があります。
各手順で何を選択すべきですか。
| 名前 | コメント |
|---|---|
| 開発 | Visual Studio ワークスペースが構成され、Azure DevOps ブランチに接続されています。 |
| ビルド | ビルド パイプラインが構成されています。 |
| 標準受け入れテスト | これはカスタマイズをテストするためのサンドボックス環境です。 |
解答を見る
開発者が Azure DevOps ブランチへチェックインした変更は、開発環境から手動でエクスポートするのではなく ビルド パイプライン で配置可能パッケージとして生成します。
生成したパッケージは Lifecycle Services の アセット ライブラリ に保存します。
標準受け入れテストはサンドボックス環境のため、環境詳細から 「管理」→「更新プログラムの適用」 を選択してパッケージを適用します。
配置可能なモデル パッケージの作成 – Finance & Operations | Dynamics 365
Q5.Dynamics 365 Supply Chain Management 向けのカスタマイズを開発しています。
このカスタマイズのパフォーマンスを最適化する必要があります。
各要件に対して、どの同時実行制御（コンカレンシー制御）オプションを実装すべきですか。
解答を見る
取得した時点で即座にレコードをロックする動作は、他ユーザーの更新を先に排除する ペシミスティック コンカレンシー制御 に該当します。
一方、更新の直前までロックを保持せず、ロック競合やリソース消費を抑えたい場合は オプティミスティック コンカレンシー制御 を使用します。
パフォーマンス最適化では、不要なロックを避けられる OCC の特性 を理解することが重要です。
明細書を選択 – Finance & Operations | Dynamics 365
Q6.あなたは Dynamics 365 Finance and Operations の開発者です。
次の X++ コードがあります（行番号は説明のために付与しているだけです）。
public void tryMethod(int a, int b)
このコードを評価する必要があります。
それぞれの呼び出しに対するメソッドの正しい出力はどれですか。
解答を見る
通常どおり終了する場合は try 内の One、Two の後に finally の Four、続いて Five が出力されます。
0 除算では catch に入り Three が出力され、return しても finally は必ず実行 されます。
a が 2 のときは catch で return するため Five は出力されません。
a が 3 のときは b を 3 に変更して retry で try を再実行 し、retry は try 開始以降の Infolog を消去するため、最終出力は再実行後の成功時の内容になります。
X++ 例外処理 – Finance & Operations | Dynamics 365
Q7.あなたは Dynamics 365 Finance の開発者です。
現在、ユーザーは顧客フォームですべての顧客グループの顧客を閲覧できます。
ユーザーが特定の顧客グループに属する顧客だけを表示できるように制限する必要があります。
どの 4 つのアクションを、どの順序で実行すべきですか。
左の「選択肢」から必要な数を右の「回答エリア」へドラッグ（またはタップ）。回答エリア内でドラッグして順序を入れ替えられます。
- ソリューションをビルドしてブラウザーを更新します。
- クエリを作成します。
- セキュリティ ポリシーを作成し、プライマリ テーブル、クエリ、コンテキスト タイプ パラメーターを設定します。
- 制約付きテーブルをポリシーに追加します。
- ソリューションをビルドし、プロジェクトのデータベース同期を実行します。
- ここへドラッグ
解答を見る
特定の顧客グループだけを表示させるには、レコード単位でアクセスを制限する 拡張可能なデータ セキュリティ を使用します。
まず抽出条件を定義するクエリを作成し、次にそのクエリを使う セキュリティ ポリシー にプライマリ テーブルやコンテキストを設定します。
続いて対象データを制限する制約付きテーブルをポリシーへ追加し、最後に ビルドとデータベース同期 を実行します。
拡張可能なデータ セキュリティ ポリシー – Finance & Operations | Dynamics 365
Q8.あなたは、新任の Dynamics 365 Finance 開発者を指導しています。
同期統合ではなく非同期統合を採用すべき場面について助言する必要があります。
どのシナリオで非同期統合を推奨すべきですか。
解答を見る
非同期統合は、呼び出し元が応答を待たずにバッチなどで後続処理できる統合に適しています。
選択肢 B は販売注文データを 1 時間ごとに受信すればよく、即時応答やユーザーの待機が不要なため バッチ型の非同期統合 が適切です。
A、C、D は「ほぼリアルタイム」や「ジャスト イン タイム」が要件で、即時性の高い同期的な統合 を検討します。
非同期統合は大量データや遅延を許容できる処理に向いています。
非同期統合 – Training
Q9.チーム エクスプローラー（Team Explorer）を使って開発環境を構成しています。
複数の開発者が同じカスタマイズに取り組んでいます。
すべてのコードがチェックインされ、その後に適切なブランチへマージされることを保証する必要があります。
アクションをどの順序で実行すべきですか。
一覧にあるすべてのアクションを正しい順序で並べてください。
左の「選択肢」から必要な数を右の「回答エリア」へドラッグ（またはタップ）。回答エリア内でドラッグして順序を入れ替えられます。
- Microsoft Azure DevOps プロジェクトをローカルの開発者マシンにマップします。
- テスト ブランチを作成します。
- 開発ブランチを作成します。
- Microsoft Azure DevOps プロジェクトに接続します。
- メイン ブランチを作成します。
- ここへドラッグ
解答を見る
Team Explorer で作業を始めるには、まず Azure DevOps プロジェクトへ接続 し、次にローカルの開発マシンへワークスペースをマップします。
その後、ブランチ階層を作成します。
共通の基準となる メイン ブランチ を先に作成し、続いてテスト用ブランチ、開発用ブランチの順に分けます。
これにより開発コードをテストへ昇格し、検証後に適切なブランチへマージできる 分岐戦略 が実現します。
分岐の概要 – Finance & Operations | Dynamics 365
Q10.Dynamics 365 Finance 向けのカスタマイズを開発しています。
このカスタマイズでは、Application Foundation パッケージのオブジェクトを拡張する必要があります。
拡張にあたっては、新しいモデルを作成して構成する必要があります。
どの 2 つのアクションを実行すべきですか。
各選択肢は、解決策の一部を表しています。
解答を見る
Finance and Operations アプリでは、標準オブジェクトを直接変更せず新しいモデルから拡張します。
Application Foundation のオブジェクトを拡張するには、アップグレードや配置を分離できる 独自パッケージのモデル を作成します。
さらに、そのモデルの依存関係として Application Foundation を参照 させる必要があります。
既存パッケージへの追加はレガシ向けで、USR レイヤー指定や拡張クラス作成だけでは要件を満たせません。
モデルとパッケージ – Finance & Operations | Dynamics 365