[OutSystems]Web Developer Specialization (ODC)のサンプル問題について解説 2/2 (#6-#10)

全部で10問で、この記事は6問目-10問目が対象。
1問目-5問目

6 Asynchronous Processes

OutSystemsのベストプラクティスとして、長時間実行されるTimerについては、

• 処理対象を一定件数ごとに区切る
• 一定件数の処理が終了したら、処理対象のEntityに終了を示す変更を行う
• 処理対象が残っているなら次の一定件数を処理する
• この時、事前に定めた一定時間以上過ぎていたら、一旦そのTimerは終了させ、自分自身をWake Timerで実行させる

実装をとる。この問題はそのベストプラクティスに照らして合わない部分を訊かれている

Actionのフローを追うと、RegistrationというEntityが処理対象データを持つEntity。
Aggregateで一定件数のデータを取得し、結果をループで処理している。ループの最後でUpdateRegistrationを呼んで、そのレコードは処理済みであるというマークをつけている。

ところが、ループを終えた後でCommitTransactionを呼んでいないために、例外やタイムアウト発生時には、それまでに行われた処理が反映されず、次回のTimer実行時に同じ対象を処理することになる。

という点を指摘している選択肢4が正解。

7 Screen and Block Lifecycle

Screen and block lifecycle events - ODC Documentationで解説されている、Screenが備えているEventについての問題。

この問題について訊かれているOnInitializeについては

Occurs after checking the permission of the user to access the Screen, but before navigating to the Screen and fetching data. In Blocks, it occurs after the navigation. You can use it to initialize the Screen or Block by setting its default data.

とある。つまり

• 権限チェックが行われた後、実際の画面遷移とデータ取得前に発生
• データの初期化に使う

もの。この前提で選択肢を見ていく。

1. ×：DOM要素へのListner追加には使えない。なぜならOnInitialize時点ではDOM要素の準備は終わっていない。その用途では、OnReadyを使う
2. ×：OnInitializeで時間がかかる処理を行うと、描画を遅延させる可能性はあるとドキュメントに書かれている(it may delay the rendering of the Screen or Block)
3. ○：↑の説明通り
4. ×：データ取得より前に動くので、画面中で取得するデータにはアクセスできない

8 Troubleshooting

画面から参照されているService Actionをデバッグするときに、どこで操作を行うか、という問題。

選択肢3, 4では、Entry appを指定する、という操作が含まれる。
Debugging apps - ODC Documentationによると、

Stepping into a Service Action from a consumer app isn't supported.

であるからこの操作は、Service Actionには行えない。
よって、素直にService Actionを含むEmployees Appでデバッグを開始する、としている選択肢1が正解。

9 Best Practices - Queries

MakerというマスタEntityと、それを参照するCarというEntityがある。
このMakerが持っている名前を含めてCarの一覧をExcelに出力したい。

Actionフローを見ると明らかに非効率な実装をしているので、これを改善する選択肢を選ぶ問題。

フロー中では、MakerをAggregateで取得→ループして各MakerごとにCarを取得→取得したCarをリストに貯める、という実装を取っている。
ループ中でEntityを取得に行くのはベストプラクティス違反。この場合は、MakerとCarをジョインした上で1回のAggregate呼び出しにまとめれば良い。

これを素直に表している選択肢3が正解。

10 REST APIs

1. ○：Consume REST APIの定義を作成するときに、対象APIのサンプルリクエスト・レスポンスからInput・Output Parameterへの自動マッピング（Structureが作成される）可能
2. ○：Consume REST API実行時に、リクエスト・レスポンスから事前に定めたOutSystems型へのマッピングは自動で行われる
3. ×：GETメソッドの場合、Input ParameterのSend in=Bodyを設定すると、「Invalid HTTP Method Input parameters with Send In property set to 'Body' are not allowed for GET methods. 」というエラーになる
4. ○：Consume REST API作成時の標準的な作業手順。指定したアドレスとパラメータでテスト実行し、レスポンスを使ってOutSystems上の対応Structureを自動作成する

問題は、「できないこと」を聞いているので選択肢3が正解。