メインコンテンツまでスキップ

画面のデバッグ操作（ケース別）

ここでは、画面のデバッグにおける確認ポイントとケース別の操作例について説明します。

デバッグで確認すべきポイント​

アプリケーション完成後のデバッグで、画面コンテンツに関してよく確認されるポイントは次のとおりです。

  • データの正しいセット確認：
    フォーム入力後や初期表示時に、正しい値が変数にセットされているかを確認します。デバッグツールで変数の現在値を確認し、想定通りの値が格納されているかを検証します。

  • データバインドの動作確認：
    画面上で値を変更した際に、対応する変数の値が更新されるかを確認します。デバッグツールで変数の値を変更し、対応する変数の値が更新されるか（正しく連動しているか）を検証します。

  • 条件分岐や表示制御のテスト：
    表示・非表示や値の切り替えなど、画面コンテンツの条件制御が意図通りに動作しているかを確認します。デバッグツールでは、変数の値を変更して、画面表示や部品の反映状態をチェックします。

  • エラー発生時の原因調査：
    データが完全に表示されない、画面やコンソールにエラーが出ている、または一覧は空なのにデータソースやAPIは正常に動作しているなど、想定外の挙動が発生した場合は、デバッグツールを使って原因を確認します。デバッグツールでは、アクションの設定内容を中心に、変数もあわせて検証します。

コラム

画面コンテンツを正しくデバッグするためには、画面内で使用される「画面変数」や、実行環境に関する「環境情報変数」を理解しておくことが重要です。これらの変数を把握しておくことで、値の受け渡しや表示内容の変化を効率的に確認でき、原因の特定や修正もスムーズに行うことができます。詳細は「画面変数と環境情報の設定」を参照してください。

ケース別のデバッグ操作例​

アプリケーション完成後に行うデバッグの代表的な操作例についてケースごとに紹介します。

参考

(1) データが想定通りにセットされているか​

フォームに入力された値や、ラベル・表示部品にバインドされた値が想定通りになっているかを、デバッグツールで確認します。ここでは、最終的に画面上に表示されているデータが正しいかを検証します。

想定シナリオ​

ToDoアプリの登録画面で、ユーザがタスクを入力し、［登録］ボタンを押下します。

入力例：
  • 「概要」入力欄："ロジックフローのデバッグ"
  • 「詳細」入力欄：
    "エラー発生時のデータ出力を確認し、マッピング設定を修正する。"
  • 「カテゴリ」選択項目："タスク"
  • 「重要度」選択項目："高"
  • 「期限日」選択項目："（本日の日付）"

操作手順​

登録画面を開き、データが想定通りにセットされているかを確認します。確認ポイントは以下のとおりです。

  • フォームやラベルなどの画面表示値を確認
  • 入力した値が変数やデータモデルに格納されているか
  • サーバ通信や処理結果が正しく画面に反映されているか

  1. デバッグツールの［変数］タブをクリックし、［変数］を選択します。
  2. 画面の入力フォームに値を入力し、対応する変数が正しく値を取得しているか確認します。
    └ 例：「概要」入力欄に「ロジックフローのデバッグ」と入力すると、$variable/state配下の変数$titleに同じ値がセットされます。
  3. デバッグツール上で対象変数を選択し、［ ］をクリックします。
    └ 変数値を意図的に書き換えて、画面上の入力欄がリアルタイムで変化するかを確認します。
    └ 例：変数$titleの値を「ロジックフロー」に変更すると、画面の「概要」に「ロジックフロー」と表示されます。
  4. 画面上で該当操作を行い、入力した値が画面やサーバ側の変数に正しく反映されているかを確認します。
    └ 例：［登録］ボタンを押下した後、一覧画面や$variable/endPoint/register配下の変数に値が反映されます。
トラブルシューティング

  • 入力値がデータモデルや変数に反映されない場合：

    • 原因の可能性：入力フォームと変数のバインド設定や、関連するイベント処理に不備がある
    • 対応：バインド設定やイベント処理を見直し、必要に応じてデバッグツールで変数の値を確認する

  • 送信後の登録データが一覧画面などで正しく表示されない場合：

    • 原因の可能性：サーバ連携やマッピング設定の不備
    • 対応：デバッグログやAPI通信内容を確認し、フロー定義やマッピングの設定を修正する

(2) データバインドが正しく動作しているか​

(1)と内容が一部重なりますが、特にデータバインド（UI部品と変数との関連付け）が正しいかどうかを、デバッグツールで確認します。ここでは、画面部品と変数（データモデル）が連動して更新されるかどうかを検証します。

想定シナリオ​

ToDoアプリの一覧画面で、登録済みのタスク情報が表示されています。テーブルには、「概要」「カテゴリ」「重要度」「ステータス」「期限日」が表示されています。上記「(1) データが想定通りにセットされているか」の入力例が表示されています。

操作手順​

一覧画面を開き、ロジックで取得したデータと、画面に表示されるテーブルの内容が一致しているかを確認します。確認ポイントは以下のとおりです。

  • データモデルと画面表示が一致しているか
  • データソースに正しい変数が指定されているか
  • 最新のデータがセットされ、一覧表示に反映されているか

  1. デバッグツールの［変数］タブをクリックし、ロジックで取得したデータモデルを確認します。
    └ 取得されているデータ件数が想定通りか（例：3件登録済みなら、3件のデータがあるか）を確認します。
    └ 各行に格納されている値がそれぞれ正しいかを確認します。
  2. 一覧画面上のテーブルに表示されている値と変数の内容を比較します。
    └ 表示されている値が変数に格納されたデータと一致しているかを確認します。
    └ データの並び順が想定通りかを確認します。
  3. データバインドの設定が正しいかを確認します。
    └ テーブルのデータソースが正しい変数になっているかを確認します。
    └ 各列が正しい項目を参照しているかを確認します。
トラブルシューティング

  • ロジック内で正しくデータが格納されていない場合：

    • 原因の可能性：データ取得処理でSQLやAPIの結果が変数に正しく代入されていない
    • 対応：SQLやAPIの実行結果が想定通り取得できているか、ロジックのデータ取得処理を確認する

  • 表示前にフィルタやソート処理が行われている場合：

    • 原因の可能性：一覧表示前にフィルタやソート処理が追加され、意図せずデータが除外・並び替えられている
    • 対応：ロジック内の処理順を確認し、フィルタ条件やソート設定を一時的に外して全件表示されるかを検証する

  • 画面側で別の変数に再代入している場合：

    • 原因の可能性：テーブルのデータソースが変数ではなく、別の変数を参照しているため、データ更新が同期されていない
    • 対応：画面部品のデータソース設定を確認し、使用変数を統一する

(3) 条件分岐や表示制御のテスト​

ある変数の値によって、部品の表示・非表示や値の切り替えなどが行われる場合、条件分岐が正しく動作しているかをデバッグツールで確認します。ここでは、画面の状態や入力内容に応じて、部品の表示・非表示が意図通りに制御されているかを検証します。

想定シナリオ​

ToDoアプリの登録画面では「ステータス」項目を非表示にし、編集・詳細画面では「ステータス」を表示するようにします。

「ステータス」部品の表示条件として、次の式が設定されています。

= $input.__mode__ != $constant.mode.register

この式は、現在の画面モードが登録モードregister以外の場合、「ステータス」を表示することを意味します。なお、ここではすでに1件のデータが登録されており、そのデータを編集・参照する状況を想定しています。

操作手順​

編集・詳細画面を開き、表示制御が行われているかを確認します。確認ポイントは以下のとおりです。

  • 表示制御に使用されている変数の値を確認
  • 画面の種類に応じて、部品が正しく表示・非表示になっているか
  • 表示制御に使用している条件式が正しい構文で記述されているか

  1. 一覧画面から［ ］をクリックし、編集画面を開きます。
    └ デバッグツールを表示している場合は、ブラウザを再読み込みしてください。
  2. デバッグツールの［変数］タブをクリックし、［入力］を選択します。
    └ $input.__mode__に、編集画面を示すeditという値が表示されています。
  3. 画面上に「ステータス」項目が表示されていることを確認します。

  1. 一覧画面に戻り、［ ］をクリックし、詳細画面を開きます。
    └ デバッグツールを表示している場合は、ブラウザを再読み込みしてください。
  2. デバッグツールの［変数］タブをクリックし、［入力］を選択します。
    └ $input.__mode__に、詳細画面を示すreferという値が表示されています。
  3. 画面上に「ステータス」項目が表示されていることを確認します。
注意

画面を切り替えても、デバッグツールは自動で更新されません。最新の状態を反映するため、ブラウザを再読み込みしてください。

トラブルシューティング

  • 表示条件が意図通りに動作しない場合：

    • 原因の可能性：表示条件に設定された式が誤っている、または比較対象の値が想定と異なっている
    • 対応：入力変数や定数の値を確認し、モード値が正しく設定されているかを確認する

  • 表示・非表示が切り替わらない場合：

    • 原因の可能性：条件式が常に同じ結果を返している、または再描画処理が行われていない
    • 対応：式の演算子（==, !=など）を見直し、想定する真偽値が得られているか確認する

  • 変数値の変更が画面に反映されない場合：

    • 原因の可能性：対象部品が条件式で参照している変数と異なる変数にバインドされている
    • 対応：部品のプロパティ設定を確認し、条件式で参照する変数とバインド変数を一致させる

(4) エラー発生時の原因調査​

データが完全に表示されない、画面やコンソールにエラーが出ている、または一覧は空なのにデータソースやAPIは正常に動作しているなど、想定外の挙動が発生した場合は、デバッグツールを使って原因を確認します。ここでは、アクションの設定内容が正しく動作しているかを中心に検証します。

想定シナリオ​

ToDoアプリの登録画面で、ユーザがデータを登録します。通常であれば、［登録］ボタンをクリックすると一覧画面に遷移しますが、ここではエラーが表示され、画面遷移が行われない状況を想定します。

操作手順​

登録画面でアクションの実行状況を確認した後、一覧画面に遷移し、一覧再取得のアクションが正常に動作しているかを確認します。確認ポイントは以下のとおりです。

  • アクションが正しく実行されているか（フロント送信）：登録画面で確認
  • ロジックでデータが正しく処理されているか（バックエンド処理）：登録画面で確認
  • 登録後に一覧再取得処理が行われているか（画面更新）：一覧画面で確認
登録画面のデバッグ​

登録画面を開き、［登録］ボタン押下時のアクション設定と実行状況を確認します。あわせて、サーバ側での処理内容や、リクエスト送信後にロジックフローが正常に実行されているかを確認します。

  1. Chromeの開発者モード画面で、［コンソール］タブをクリックします。
  2. エラーの種類、アクション名、スタックトレースなどを確認します。
    └ 例：「IM-LogicDesignerフロールーティング〇にリクエストを送信する」アイテムでエラーが発生していることがわかります。

  1. Chromeの開発者モード画面で、［BloomMaker］タブをクリックします。
  2. デバッグツールの［変数］タブをクリックし、［変数］を選択します。
  3. 変数やデータモデルを確認します。
  • 空配列やnullの場合：取得処理（アクション）の問題が考えられます。
  • データ値が入っているが、画面表示されない場合：バインドや画面側の問題が考えられます。

  1. デバッグツールの［アクション］タブをクリックし、［アクションが呼ばれたとき］タブを選択します。
  2. 該当するアクションアイテムの［ ］をクリックし、ブレークポイントを設定します。
    └ アイコンがブレークポイントを示す に切り替わります。
  3. 画面上で該当操作を行い、処理が一時停止した状態で以下の内容を確認します。
  • 入力値（変数）がアクションに正しく引き渡されているか
  • サーバへの通信（API呼び出し）が正常に行われているか
  • ロジックフロー内でデータが正しく処理・格納されているか
入力値（変数）を確認する場合：

(1) デバッグツールの［変数］タブを開き、アクションで使用される変数の値を確認します。
└ 値が空配列やnullの場合は、入力フォームのプロパティ設定を見直します。

(2) 必要に応じて変数の値を手動で修正し、再度アクションを実行してみます。
└ 正しい値をセットした状態で処理が進むかを確認することで、原因が値の受け渡しか処理ロジックかを切り分けることができます。

(3) デバッグツールの［アクション］タブを表示し、ブレークポイントを外して、正常の動作状態で再度検証します。
└ 値の修正後に問題が再現しない場合は、フロント側の入力値設定に原因があると判断できます。

サーバ側の処理を確認する場合：

(1) Chromeの開発者モード画面で、［ネットワーク］タブをクリックします。

(2) 該当操作時に通信（POST/PUT）が発生しているかを確認します。
　- 正しいURL・メソッドでリクエストが送信されているか
　- リクエストデータ（body）に入力内容が含まれているか
　- レスポンスが正常（200）か、またはエラーや警告（4xx, 5xx）で返っていないか

(3) 通信が発生していない場合は、アクション設定を見直します。

ロジックフローを確認する場合：

(1) デバッグツールの［アクション］タブを表示し、該当アクションの詳細を確認します。
└ リクエスト内容（ルーティング・パラメータ・HTTPメソッドなど）が正しいかを確認します。

(2) デバッグログを確認し、該当フローが実行されているか、またはエラー出力がないかを確認します。
└ フローの途中でエラーが発生している場合は、該当タスクやデータマッピングを修正します。

(3) ルーティングやパラメータが誤っている場合は、アクション設定を修正し、ブレークポイントを外して正常の動作状態で再度検証します。

参考

デバッグログの確認方法については、「デバッグログの確認」を参照してください。

一覧画面のデバッグ​

一覧画面を開き、登録画面から一覧画面への遷移に関するアクション設定と実行状況を確認します。あわせて変数やデータモデル、フィルタや並び順も確認します。

  1. デバッグツールの［アクション］タブをクリックし、［アクションが呼ばれたとき］タブを選択します。
  2. 画面の初期表示時に実行されるアクションの設定を確認し、イベントに正しく登録されているかを確認します。
    └ プロパティ設定のイベントを確認し、「初期表示時」アクションを設定します。
  3. 一覧データを取得するアクションの設定を確認します。
    └ アクションが非アクティブになっていないか、または条件付きで実行される設定になっていないかを確認します。

  1. デバッグツールの［変数］タブをクリックし、［変数］を選択します。
  2. 一覧データを格納している配列やオブジェクトを確認します。
    └ 最新の登録データが含まれていない場合は、再取得アクションの呼び出し漏れやロジックフローでの返却データ不備が考えられます。

  1. 検索条件によって、登録データが表示対象外になっていないかを確認します。
  2. 並び順（ソート条件）の影響で、新しいデータが下位に隠れていないかを確認します。
トラブルシューティング

  • ボタンを押してもAPIが呼ばれない場合：

    • 原因の可能性：イベント設定またはアクション割り当ての不備により、登録処理が実行されていない
    • 対応：画面のイベント設定とアクション一覧を確認し、ボタンに正しいアクションが設定されているかを見直す

  • APIやロジックフローは成功しているが一覧に反映されない場合：

    • 原因の可能性：一覧再取得アクションが実行されていない、一覧データのバインド名が不一致、またはキャッシュが残っている
    • 対応：登録後に一覧再取得処理が設定されているか確認し、一覧部品のバインド名と出力変数名を照合する。必要に応じてキャッシュをクリアして再表示を確認する

  • サーバ側でエラーが発生している場合：

    • 原因の可能性：APIまたはロジックフロー内で入力値エラーや例外が発生している
    • 対応：IM-LogicDesignerのデバッグログやAPIレスポンスを確認し、エラー箇所・入力値・例外メッセージをもとに修正する
参考

「IM-LogicDesignerフロールーティング○にリクエストを送信する」アクションや「カスタムスクリプトで実行する」アクションのデバッグ方法については、「Low-Code HANDBOOK - アクションのデバッグ - IM-BloomMaker」を参照してください。