はじめに

OutSystemsでアプリ開発を始めたばかりの方へ。
「動かない…」「どこで止まってるの？」そんなときに頼れるのがデバッガです。
この記事では、OutSystemsのデバッグの基本操作と、ハマりがちな注意点をまとめて紹介します。

動作環境

OutSystems Version: O11
Service Studio Version: 11.55.22
※モジュールは基本的にReactiveWebAppです。

デバッグの基本操作

ブレークポイントの設定

Service Studioで止めたい箇所にブレークポイントを追加します。デバッグを開始した後もブレークポイントを設定することができます。

デバッグの開始

「Debugger」タブ → EntryModuleと好きなブラウザを選択→「Start Debugging」で開始
　 ※EntryModule = デバッグセッションの起点となるモジュール。基本的にエンドユーザーモジュールを設定します。

moduleTypeがReactiveWebAppの場合「Start Debugging」すると自動でブラウザが開かれますが、
TraditionalWebの場合OpenInbrowserにチェックをつけないと開きません。
ブラウザからアプリを操作し、テストしたいアクションを呼び出す

このテストアプリの場合、EmployeeのNameを更新するボタン でOnClickアクションが呼び出されます。

EmployeeのNameを更新するボタン を押下するとOnClickアクションでデバッガが停止しました。

デバッガのタブの詳細については下記を参照してください。
Debuggerタブについて

デバッグ時の注意点まとめ

プロデューサモジュールのデバッグはEntryModuleにコンシューマモジュールを指定したうえで、ブラウザを手動で開くと開始できる

プロデューサモジュール単体でデバッグしたい場合、EntryModuleにコンシューマモジュールを指定したうえで、ブラウザを手動で開く必要があります。

詳細な前提条件については下記を参照してください。
プロデューサモジュールをデバッグする

私は上記の記事を雑に読んでいたのか、割と最近までコンシューマモジュールでもデバッガを起動させないとプロデューサモジュールのデバッグはできないと思い込んでいました。

この記事の「プロデューサモジュールをデバッグする方法」には、
要約するとコンシューマモジュールとプロデューサモジュール両方のブレークポイントで停止させたい場合は、デバッガを両方起動しなさいと書いています。

別にコンシューマモジュールのブレークポイントで止めたくなければ、プロデューサモジュール単体でもデバッグできるのです。

せっかくなのでコンシューマモジュールとプロデューサモジュール、それぞれ単体で起動したらどうなるのか見ていきたいと思います。

エンドユーザーモジュール単体で別モジュールのサーバーアクションをデバッグしようとした場合

スクリーンアクションで別モジュールのサーバーアクション（UpdateEmployees）を呼んでいるところにブレークポイントを置きます。

UpdateEmployeesでデバッガを止めてStep Intoすると下記のエラーが発生しました。

調子が悪いとデバッガが固まって戻ってこなくなるので、コンシューマモジュールのみデバッグしてるときにうっかりStep Intoしないようにしましょう。

プロデューサモジュール単体でサーバーアクション（UpdateEmployees）をデバッグする場合

こちらはプロデューサモジュール（moduleType：Service）のDebbugerタブです。

Open in browser というチェックボックスがあるのでチェックを付けたらいかにもブラウザが開きそうですが、
EntryModuleにコンシューマモジュールを指定し、Open in browser にチェックをつけて「Start Debugging」を押下してもブラウザは開きません。

この状態で、エンドユーザーモジュールから手動でブラウザを開いてみます。

EmployeeのNameを更新するボタン を押下すると、UpdateEmployeesが呼び出されてデバッガを停止させることができました。

moduleTypeがServiceの場合、Open in browser にチェックをつけても今のところブラウザは開かないので、手動でブラウザを開くようにしましょう。今回はエンドユーザーモジュールから開きましたが、URLを指定して開いても同じ挙動になります。

環境次第では自分のデバッグがチームメンバーが操作しているアプリの動作に影響を与えることがある

まず、TraditionalWebアプリにはPesonal AreaとPublic Areaがあり、自分の変更をPublishすることなくデバッグすることができますが、ReactiveWebAppやMobileの場合はPublic Areaしかないので変更をPublishせずにデバッグすることができません。

Publishされていない変更がデバッグ時にどう扱われるかについては下記の「パブリッシュされていない変更」を参照してください。

Debuggerタブについて（パブリッシュされていない変更）

Public Areaというのは、1-Click Publishを使用した場合にモジュールがパブリッシュされる、環境の共有領域だそうです。
Public AreaとPersonal Area

このPublic Areaでデバッグしているので、開発環境によってはチームの誰か一人がデバッグをしていると、同じ環境にいるメンバーにも影響が出ることがあります。

実際に、私がサーバーアクションをデバッグしているとき、チームメンバーがそのサーバーアクションを呼んでいる画面を開くとローディング状態になっていたり、

私がサーバーアクションのデバッグを始めた後に、チームメンバーが同じサーバーアクションのデバッグを開始すると、私のデバッグフローが巻き戻ったりしたことがあります。

詳細については下記の「プロキシシナリオとファーム環境でのデバッグ」のところを参照してみてください。

アプリのデバッグ（プロキシシナリオとファーム環境でのデバッグ）

おわりに

OutSystemsのデバッガは、慣れるまでは戸惑うことも多いですが、煮詰まったときにはとても強力なツールです。

この記事が、OutSystems初心者の方の助けになれば嬉しいです！