OutSystems標準のログには、一連のリクエストの入り口となるトップレベルのログと、トップレベルのログと関連付けられるドリルログに分類される。一連の処理を関連付けて調査するためには、トップレベルのログのRequest_Key属性をドリルログのフィルタに使う。
公式ドキュメントで、トップレベルのログに分類されるものについての記述がちょっと古そうなので、動作を整理して、動作確認してみる。
2022/4/10時点でのドキュメント
トップレベルのログによると、
「トップレベル」とみなされるのは以下のログです。
- 画面 - このログのエントリ1つに対し、モバイルデバイスのWebアプリケーションまたはレスポンシブWebアプリケーションへのアクセスが1つマッピングされます。
- 連携（サブタイプが「公開」）- このログのエントリ1つに対し、プラットフォームが公開するWebサービスへのアクセス（SOAPまたはREST）が1つマッピングされます。
- モバイルリクエスト - このログのエントリ1つに対し、モバイルWebアプリケーションのサーバー側ロジックへのアクセスが1つマッピングされます。
- 反復ジョブ - このログのエントリ1つに対し、バッチジョブまたはタイマーによる実行が1つマッピングされます。
とあり、原文（英語）も参照して考えると、Service CenterのMonitoringにある以下のログがトップレベルログであると思われる。
- Traditional Web Requests
- Screen Requests
- Integrations (Type=Exposed)
- Timers
Service Actionsはトップレベルログでは？ とも思うが、この後の動作確認結果を受けると、ドリルログであるらしい。
動作確認
基礎知識
トップレベルログ1レコードごとに一意のRequest_Keyが発行される。
例えば、1つのScreen Requests (Reactive Web App画面のScreen ActionからのServer Action呼出に対応）に紐づく一連のドリルログが持つRequest_Keyが一意。
サーバー処理中でRequest_Keyを取得するには、PlatformRuntime_APIモジュールにあるRequest_GetKey Actionを呼び、そのOutput Parameterを見れば良い。
このあたりは以前にQiitaに書いた。
Request_GetKeyでログの関連付けを見られる
調査用実装
以下のような構成のモジュールとActionを用意した。
処理の流れは、Consumerモジュールでボタンをクリックすると
- Screen Actionで同じモジュールのServer Actionを呼ぶ
- 1のServer Action内でProducer1モジュールのServer Actionを呼ぶ
- 2のServer Action内でProducer2モジュールのServer Actionを呼ぶ
- 2のServer Action内でProducer2モジュールのService Actionを呼ぶ
- 2のServer Action内でProducer2モジュールのExpose REST APIをConsumeして呼ぶ
1-5の各ActionでRequest_GetKey Actionを実行してRequest_Keyを取得し、LogMessage Actionでログ出力する。
確認結果
一連の処理の起点となるのは、Screen Actionから呼ぶServer Action。この情報は、Service CenterのMonitoring > Screen RequestsのログをExport to ExcelボタンでExcelに出力すると、Request_Key列で確認できる。つまり、この場合のトップレベルログはScreen Requests。
確認した結果は「c16feb96-59a5-4644-88cc-d0701b429ab9」だった。
LogMessageで出力したログは、General Logに出力されるので確認してみる。
結果を見ると、1-4までが同じRequest_Keyを持っていて、Expose REST APIだけが別のRequest_Keyを持つということらしい。（Server ActionとService Actionはドリルログで、Expose REST APIはトップレベルのログということになる）
（個人的に）意外にもService Actionは一連のログの一部とみなされるようだった。