カナダのInsumというパートナーさんが、APEX Instant Tipsというタイトルで、ちょっとしたOracle APEXの使い方を紹介しています。
その12回目にオラクルのJoel Kallmanさんが招待され、リモート・デバッグについて紹介していました。
録画はこちらより視聴できます。
Episode 12: How to remote debug a user's session
https://www.insum.ca/apex-remote-debug-user-session/そこで説明されていた内容と、少々デバッグに関する情報を紹介します。
例えば利用者がOracle APEXで作られたアプリケーションにアクセスしていて、何か問題が発生したとします。電話やチャットで開発者にサポートが求められている状況を想定します。
開発者はアプリケーション・ビルダーにサインインすることができます。
開発者は、連絡を受けて最初に利用者の名前を確認するでしょう。
名前、正確にはユーザー名の確認ができれば、そのユーザーのセッションを見つけることができます。
アプリケーション・ビルダーの右上の管理（スパナと人のアイコン）アイコンからメニューを開いて、アクティビティのモニターを実行します。
アクティブ・セッションを開くと、その時点で有効であるセッションの一覧がユーザー名（レポート上は所有者）とともに表示されます。ユーザー名が分かっていれば、セッションが作成（開始）されたタイミングや最新のビューから、どのセッションなのかは大体見当がつけられるでしょう。そのアクティブ・セッションをクリックして開きます。
そのセッションの詳細が表示されます。そのユーザーがOracle APEXのアプリケーションに対して、どのような操作を行ってきたか、ページ・ビューとして一覧されます。
発生しているエラーや、それがどのページの何の処理で発生したのかを確認することができます。利用者にエラーメッセージなどを確認する必要はありません。
エラーが発生している場合は、デバッグIDをクリックして実行ログを確認します。
例えばデバッグ・レベルを情報(LEVEL4)に変更します。変更の適用をクリックします。利用者に問題が発生したオペレーションを再実行してもらえば、より詳細な実行ログを取得できます。
デバッグ・レベルを情報まであげると、ページ・アイテムに設定された値などもログに含まれるようになります。（ちなみにトレース・モードはSQLトレースをファイルに出力するためのオプションで、alter session set sql_trace = trueと同じです。データベース管理者の協力がなければ、ほぼ使うことのない指定です。）
パフォーマンスの問題などで実行計画を確認したい場合は、デバッグ・レベルをAPEX Trace(LEVEL9)まで上げます。
デバッグ・レベルをAPEX Traceまで上げると大量の実行ログが出力されます。その中に実行計画の出力も含まれます。
速度は極端に遅くなるので、必要な情報を取得した後はデバッグ・レベルは下げた方がよいでしょう。
続いて注意点です。アプリケーション定義でデバッグがONになっていると、アプリケーションの利用者によってデバッグを有効にすることが可能になります。
例えばf?p形式のURLの場合は
f?p=アプリケーションID:ページID:セッションID:リクエスト:デバッグ:::
簡易URLの場合は
debug=デバッグ
です。アプリケーションのURLでデバッグが指定されていると、リモートからの設定より優先されます。本番アプリケーションでは、ブラウザからデバッグを有効にできるようになっていると問題があるので、デバッグはOFFにします。
デバッグに関するマニュアルの記載はこちらです。
最後に開発したアプリケーション固有のデバッグ・ログを出力するために、APEX_DEBUGパッケージを使用できます。ERROR、WARN、INFO、TRACEといったデバッグ・ログを出力するプロシージャが含まれています。
プロセスなどに比較的長いコードを記述する場合に、APEX_DEBUG.INFOプロシージャを呼び出して、デバッグを容易にするメッセージを出力することをお勧めします。
今回紹介したアクティビティのモニターには、アプリケーション・エラーという項目もあります。
アプリケーション・エラーを開くと、発生したエラーの一覧を確認できます。
発生しているエラーは、利用者からの報告の有無にかかわらず確認することができます。特に頻繁にアプリケーションを置き換え、利用者に置き換えについて通知しない運用をしている場合に有用です。
セッションやデバッグ・ログを確認するためにアプリケーション・ビルダーにサインインするのは手間であったり、または、サポート要員が確保できていれば、アプリケーションをデバッグするためのアプリケーションを開発することも可能です。
セッションの情報はビューAPEX_WORKSPACE_SESSIONS、ページのアクセスは、ビューAPEX_WORKSPACE_ACTIVITY_LOG、デバッグ・ログはビューAPEX_DEBUG_MESSAGESから取得できます。
アプリケーションが自分自身のセッションのデバッグを有効/無効にするためにAPEX_DEBUG.ENABLE/DISABLEが使えます。異なるセッションの場合はAPEX_SESSION.SET_DEBUGを呼び出します。
Oracle APEXでは、フレームワーク側でセッションの情報、アクセス履歴やエラー・メッセージなどを記録してくれますし、保存されている情報はSQLで取り出すこともできます。ですので、デバッグ用のコードの埋め込みを少なくすることができます。
PL/SQLのコーディングなどを学ぶと、パッケージを使う、例外処理をきちんと書く、ということが推奨されています。確かにそうなのですが、Oracle APEXに埋め込むコードについていえば、例外をトラップしていなければ、アプリケーション・エラーとしてメッセージが記録されます。
APEXにはアプリケーションのデバッグを容易にするための機能が備わっているので、それを活用すると良いのではないかと思います。そうすることで、短期間でとりあえず使えるアプリケーションを作ることができます。
完
