Web Developer Specializationは2023/3に追加された試験で、ReactiveのProfessional認定の条件の1つ。

試験情報のPDFと一緒にダウンロードできるサンプル問題を解説する。
全部で10問で、この記事では1問目-5問目が対象。

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

サンプル問題は、
https://www.outsystems.com/learn/certifications/
の、「Web Developer Specialist」項目のリンク「Exam Details」でダウンロードできる資料から。「Sample Exam」がついている方のファイルが該当する。
この記事では、zipを展開したときに、ファイルの更新日時が2023/04/05 9:15のものを使って各問題を見ていく。

残念ながら、2023/04/08時点では英語のみ。

Professional Web/Mobile Developer Certification

今回公開された試験で、Reactive Web Appでも、Professionalレベルの認定を受けられるようになった。
条件は、

Associate Reactive Developer
Security Specialization
Web Developer Specialization
Architecture Specialization

の各試験を合格すること。
上記に加えて

Mobile Dev Specialization

も合格すると、Professional Mobile Developer Certificationを受けられる。

Web Developer SpecializationのAnnouncementに体系図が載っているので、参考までに。

1 長時間実行されるTimerのベストプラクティス

問題文の検討

たくさんのデータを外部システムに同期するTimerのロジックで、ベストプラクティスに従っていない部分を指摘するもの。

Action Flowを見ると、Entityで取得したレコードをFor Eachでループ。
各ループで、

Action（おそらく外部システムにアクセス）を呼ぶ
Entity Actionでレコードを作成
CommitTransaction Actionでコミット実施

をしている。
これを見ると気付くのは、

OutSystemsのベストプラクティスタイマーおよびバッチジョブの長期-実行を避けるに違反している（なぜか日本語ページにリンクできなかったので英語のページ）
1レコードごとにCommitTransaction発行するのは頻度が高い

選択肢の検討

A. ×：問題は明らかにある
B. ×：Timeout in Minutesは20分程度にするのがベストプラクティスなのでスクリーンショットにある20より大きい値にするのは推奨されない。同じサーバーのリソースを食いつぶさないためTimerの同時実行数には制限がある（デフォルトではPlatform Serverあたり3）ため
C. ×：CommitTransactionが多いのは事実だが、それがだめかどうかは、各ループで呼んでいる外部処理による。少なくともTimerの最後にループの外でCommitするのはベストプラクティスで推奨されている事項ではない。コミットは、ループ中にIfを置いて一定の回数や経過時間等で行うのがよい。Timerの最後に到達するとOutSystemsが自動的にコミットを行うためその位置で明示的にCommitTransactionを行うのは意味があるとは言えない
D. 〇：これがベストプラクティスに従った実装。こうした実装の例はAsynchronous Processing with Timers - Best Practices on Timersで紹介されている

2 Consume REST APIのInput Parameter

問題文の検討

Consume REST APIエラーに渡すInput Parameter "Phone Number"がある。
実行時に“The PhoneNumber attribute must not be null”というエラーが発生するのでこれを解決する方法を聞かれている。

スクリーンショットを見ると、PhoneNumber項目のSend Default Value=Noが設定されている。この設定をすると、該当Parameterがデフォルト値の場合、「項目自体を省略する」。エラーメッセージと併せて考えると、PhoneNumberが空白の値であるために、API呼び出し時に項目自体を渡さなかったために発生したエラーと思われる。

他の条件として

対象APIは他のInput Parameterを正しく受け取っている -> ネットワークや対象API自体には問題が起きていない
PhoneNumber自体はmandatoryではない -> PhoneNumberを必須にするのは望ましくない

選択肢の検討

A. ×：PhoneNumberのDefault Valueをどんな値にしようとも、たまたまその値が設定された場合、実行時に項目が省略され、同じ問題が発生する。また未指定時に適切なPhoneNumberのデフォルト値があるという情報が与えられていない
B. 〇：これが正解。Send Default Value=Yesにしておけば、未指定の項目も省略されなくなる
C. ×：OnBeforeRequestはConsume REST APIのCallbackで、外部APIを呼ぶ直前に割り込んでHTTP通信の内容を書き換えることができる。よって選択肢に書いた通りのことは実現可能だが、選択肢Bの方が明らかに自然で簡単な方法なので、Bがある以上はこの選択肢は×
D. ×：問題文の検討で見た通りMandatoryにするのは望ましくない

3 Merge

問題文の検討

Publishを行ったときにCompare and Mergeダイアログが表示され、conflictの存在が示されている（背景色が赤い部分）。conflictがある行でどちらも選択しないままMerge and Publishボタンをクリックした。

conflictが残ったままなのでService Studioは自動でマージを行えない。そのため、選択肢Dが正解。

4 Exception HandlerとTransaction

問題文の検討

Consume REST API呼び出し
"UpdateCustomerDB"という名前のAction (名前からしてEntityの更新があるのだろう）呼び出し

で構成されるActionがある。1を終えて、2でエラーが起きて、Exception Handlerに捕捉された。なお、Exception HandlerのAbort Transaction=Yesになっているため、補足された時点でトランザクションはロールバックされる。

選択肢の検討

この問題の状況では、2.のUpdateCustomerDBはロールバックされるが、1.のConsume REST API呼び出し先のトランザクションはロールバックされない。外部サービスはOutSystemsのトランザクション管理から独立しているため。

各選択肢は以下の通り
A. 1, 2共にロールバックされる
B. 1, 2共にコミットされる
C. 1はロールバックされず、2はロールバックされる
D. 1はロールバックされ、2はコミットされる

↑の説明に合うのは、選択肢C。

5 大きいテキストデータやバイナリデータを分離する

問題文の検討

あるEntityにDescriptionという属性がある。この属性のデータ型はTextで桁数が2000を超える。

この状況はベストプラクティスにある大きいテキストデータやバイナリデータを分離するに該当する。日本語のページへのリンクはなぜか機能しないため英語のページへのリンク。

ポイントは

Binary Data型の属性を含むEntityは更新に時間がかかるため、Binary Data型を分離して別のEntityに切り出す
このEntityは元のEntityのIdentifierを自分のIdとして持つ（元のEntityと分離したEntityは1:1の関係にある）
長さが2000を超えるText型属性も背後のRDB内ではBinaryのデータとして扱われるため同じ注意が必要

選択肢の検討

上記ベストプラクティスから、元のEntityと1:1の関係にある新しいEntityを作り、Description属性はそちらに移動することになる。

よって、選択肢Bが正解。