ロジックのデバッグ操作（ケース別）

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

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

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

ロジックフローの正常な動作確認：
仕様通りにロジックフローが正しい結果を返しているかを確認します。デバッグツールで入力値を設定し、すべてのパターンで期待通り正しい出力になるかを検証します。
例外処理やエラー発生時の挙動確認：
想定外の入力やエラー発生時に、処理が適切に動作するかを検証します。ロジックフローデバッグログやエンティティ操作ログを活用し、各タスクの入出力値や条件分岐の判定結果、トランザクションの動作状況を確認します。
条件分岐の評価結果チェック：
条件分岐が意図通りに評価され、正しい処理が実行されるかを確認します。デバッグツールで入力値を設定し、変数値に正しく反映されているか、想定外の分岐が発生していないかを検証します。
繰り返し処理の動作確認：
配列を用いた繰り返し処理が正しく動作し、すべての要素に対して意図した結果が取得できるかを確認します。デバッグツールで入力値を変更することで、意図しないデータの混入や型の不一致、データの未取得もあわせて検証します。

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

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

参考

ロジックフローのデバッグに関する基本操作については、「ロジックフローのデバッグ」を参照してください。
ここで紹介するケースは、Accel Studioの「顧客管理」テンプレートをもとに作成した顧客管理アプリケーションを例に説明しています。実際の画面や設定などを確認したい場合は、「Accel Studio テンプレートカタログ - 5.2.5. 顧客管理」を参照し、アプリケーションを生成してください。

(1) ロジックフローが正しい結果を返しているか

仕様通りにロジックフローが正しい結果を返しているかを、デバッグツールで確認します。ここでは、すべての入力パターンで期待通りの出力が得られるかを検証します。
想定シナリオ
顧客管理アプリの登録画面で、ユーザが顧客情報を入力します。入力された顧客情報は、ロジックフロー（登録処理）経由でデータベースに登録されます。登録完了後、一覧画面に遷移しますが、登録データが表示されない場合を想定します。
入力例：
＜会社情報＞
「会社名」入力欄："□□□□株式会社"
「会社検索名」入力欄："□□□□カブシキガイシャ"
「電話番号」入力欄："00-0000-0000"
「郵便番号」入力欄："000-0000"
「住所」入力欄："△△県△△市△△△町1丁目1-16"
「備考」入力欄："訪問の前には必ず○○プロジェクトについての資料を参照してください。"
＜相手先担当者＞
「担当者名」入力欄："生田一哉"
「所属」入力欄："マーケティング本部"
「役職」入力欄："一般社員"
「メールアドレス」入力欄："ikuta@example.com"
「電話番号」入力欄："00-0000-0000"
「備考」入力欄："2022年度からの主担当者様です。"
＜自社担当者＞
［自社担当者を選択する］をクリック："青柳辰巳"を選択
「主担当」："有効"
「備考」入力欄："□□□□株式会社のシステム移行プロジェクトをメインで担当しています。"
コラム
［自社担当者を選択する］をクリックしても何も表示されない場合は、ブラウザのポップアップがブロックされている可能性があります。ブロックを解除した上で、再度操作を行ってください。
処理の流れ
複数件のデータに対し、繰り返し処理を行いながら、1件ずつ検証と登録を実行する処理です。
(1) 共通情報の準備
入力値をもとに登録用データを整形し、新しいcompanyIDを作成します。その後、繰り返し処理に入る前に共通項目のデータチェックを行い、問題がなければ共通情報（親レコードなど）を登録します。
(2) サブフローの呼び出し
相手先担当者を登録するため、別のロジックフローを呼び出してサブ処理を実行します。
(3) 明細データの繰り返し登録
リスト型の入力データを1件ずつ処理し、各アイテムの検証を行ったうえで、検証を通過したデータをデータベースに登録します。すべてのデータ登録が完了すると、繰り返し処理を終了します。
操作手順
登録画面を開き、入力例に従ってデータを登録した後、ロジックフローの入出力値や処理経路を確認します。確認ポイントは以下のとおりです。

入力パラメータが画面入力値と一致しているか

例外やエラーメッセージが出力されていないか

出力変数に正しい値が設定されているか

各タスクが想定通りの順序で実行されているか

画面の入力フォームに値を入力し、該当操作を行います。
└ 例：［登録］ボタンを押下した後、「登録処理」のロジックフローが実行されます。

「アプリケーション管理」画面を開き、［ログ］をクリックします。
└ ログ一覧メニューが表示されます。

［ロジックフローデバッグログ一覧］をクリックします。
└ 例：登録処理に関する「デバッグログ一覧」画面が表示されます。

確認したいタスクやイベントの［］をクリックします。
└ サブフローのログも確認できます。

「ログ詳細」ダイアログで、各タスクの入出力値やスタックトレースを確認します。

入力：フォーム入力値がロジックの入力パラメータに正しく反映されているか

出力：登録結果（登録IDや処理ステータス）が想定通りか

例外：スタックトレースにエラーや例外が記録されていないか

「アプリケーション管理」画面から、該当する処理をクリックします。
└ 例：データの新規登録に関わる「登録処理」フローを選択します。

問題が疑われるタスクを選択し、［マッピング設定］をクリックします。
└ マッピング設定の内容を確認します。

［デバッグ］をクリックします。
└ 例：登録処理に関する「ロジックフロー定義のデバッグ」画面が表示されます。

処理を一時停止しながらデバッグを実行するため、［ステップ実行］をクリックします。
└ 「デバッグの実行」ダイアログが表示されます。

デバッグで使用する入力値を設定するため、［JSON入力］をクリックします。
└ 「JSONの入力」ダイアログが表示されます。

JSONを入力し、［決定］をクリックします。
└ 例：想定シナリオに基づく入力例のJSONは以下のとおりです。
{
  "companyName": "□□□□株式会社",
  "companySearchName": "□□□□カブシキガイシャ",
  "zipCode": "000-0000",
  "address": "△△県△△市△△町1丁目1-16",
  "telephoneNumber": "00-0000-0000",
  "notes": "訪問の前には必ず○○プロジェクトについての資料を参照してください。",
  "customerManager": [
    {
      "managerName": "生田一哉",
      "emailAddress": "ikuta@example.com",
      "telephoneNumber": "00-0000-0000",
      "department": "マーケティング本部",
      "post": "一般社員",
      "notes": "2022年度からの主担当者様です。"
    }
  ],
  "inhouseManager": [
    {
      "userCd": "aoyagi",
      "isMain": true,
      "notes": "□□□□株式会社のシステム移行プロジェクトをメインで担当しています。"
    }
  ]
}
［実行］をクリックします。
└ ステップ実行でタスクを進めながら、値の変化を確認します。

異常が見つかった場合、該当するタスクまたはサブフローの編集画面を開き、マッピングや変数名などを修正します。

画面を開き、再度該当する処理を行います。
└ 例：［登録］ボタンを押下した後、「登録処理」のロジックフローが実行されます。

「アプリケーション管理」画面を開き、［ログ］をクリックします。
└ ログ一覧メニューが表示されます。

［ロジックフローデバッグログ一覧］をクリックします。
└ 例：登録処理を実行した後、エラーや想定外の値が解消されているかを検証します。

コラム
一括登録などの重い処理を画面に追加する場合は、予期しない遅延やメモリ不足などが発生しないかを確認します。処理件数が多いケースを想定し、実運用に近い量のテストデータを用意してロジックフローを実行します。デバッグログの出力量や処理時間、メモリ使用状況などを確認し、必要に応じて処理の分割やバッチ化、ログ出力の絞り込みを行うことで、パフォーマンス低下を防ぐことができます。

(2) 例外・異常時のエラーハンドリングが適切か

更新対象データの件数が正しく判定され、想定外の更新（0件・複数件更新）が発生した場合でも、ロジックフローが適切に例外処理やロールバックを行うかを確認します。ここでは、すべての入力パターン（正常・異常）で、更新件数の判定やトランザクションの制御、エラーメッセージの出力が仕様通りに動作するかを検証します。
想定シナリオ
顧客管理アプリの編集画面で、2人のユーザが同時に顧客情報を更新します。
操作例：
(1) ユーザA"青柳辰巳"とユーザB"林政義"が顧客Cの編集画面をそれぞれ表示します。
(2) ユーザA"青柳辰巳"は、顧客Cの情報を削除します。
(3) ユーザB"林政義"は、顧客Cの情報を編集・更新します。
処理の流れ
顧客情報を検証・更新し、対象件数に応じて処理が分岐します。

正常条件：更新件数=1件 →thenブランチの処理実行
→エンティティの削除・サブフロー呼び出し・再登録処理が繰り返し実行されます。

異常条件：更新件数=0件または複数件 →elseブランチでエラー終了
→トランザクションがロールバックされます（途中まで行ったデータ操作をすべて取り消され、処理を開始する前の状態に戻します）。

(1) 顧客情報の検証・更新
顧客エンティティのデータを検証し、対象顧客を更新します。更新件数が1件であることを確認し、問題がなければ次の処理へ進みます。
(2) 相手先担当者データの削除とサブフロー実行
対象顧客に紐づく相手先担当者の既存データを削除した後、相手先担当者のデータを登録するため、別のロジックフローを呼び出してサブ処理を実行します。
(3) 自社担当者データの繰り返し登録
自社担当者データを1件ずつ処理し、各アイテムの検証を行ったうえで、検証を通過したデータをデータベースに登録します。すべてのデータ登録が完了すると、繰り返し処理を終了します。
操作手順
2人のユーザアカウントでログインし、それぞれ編集画面を開きます。操作例に従ってデータを操作した後、デバッグログや条件分岐を確認します。確認ポイントは以下のとおりです。

入力パラメータが画面入力値と一致しているか

条件分岐が正しく判定されているか

トランザクションが正しく扱われているか

例外やエラーメッセージが出力されていないか

「アプリケーション管理」画面を開き、［ログ］をクリックします。
└ ログ一覧メニューが表示されます。

［ロジックフローデバッグログ一覧］をクリックします。
└ 例：編集処理に関する「デバッグログ一覧」画面が表示されます。

確認したいタスクやイベントの［］をクリックします。

「ログ詳細」ダイアログで、各タスクの入出力値やスタックトレースを確認します。

入力：フォーム入力値がロジックの入力パラメータに正しく反映されているか

条件分岐：count==1の判定が正しく行われているか

出力：更新結果、サブフローの返却値、繰り返し処理の結果が想定通りか

例外：0件・複数件の更新時にエラーが発生し、処理が停止しているか

「アプリケーション管理」画面から、該当する処理をクリックします。
└ 例：データの更新に関わる「編集処理」フローを選択します。

「フロー設定」にある「トランザクションを使用する」にチェックが入っていることを確認します。
└ サブフロー側のトランザクションも有効になっているかどうか確認してください。

［］をクリックし、「サイトマップ」画面を表示します。

「Repository」から［エンティティ操作ログ一覧］をクリックします。

該当のエンティティを選択します。
└ 例：デバッグログの結果、フローが「相手先担当者データの処理」タスクの前で終了している場合は、「相手先担当者_エンティティ」の操作ログを確認します。

操作ログからデータが更新されていないことを確認します。
└ トランザクションがロールバックされている場合、更新処理を行っても新しいデータは追加されていません。

コラム

データの登録・更新・削除など、状態が変化する処理では、トランザクション制御が正しく行われているかを確認します。データ操作の前後で想定される状態を確認しながら、登録・更新・削除の各処理に対応するロジックフローを実行します。ロールバック発生時の挙動を確認し、トランザクション単位でどの処理まで反映されているか、また意図しないコミット（変更を確定する操作）が発生していないかもあわせて検証します。

(3) 分岐処理が意図通りに正しく実行されるか

分岐条件が意図通りに評価され、それぞれの処理が正しく実行されるかを確認します。ここでは、変数値に正しく反映されているか、想定外の分岐が発生していないかを検証します。
想定シナリオ
顧客管理アプリの登録・編集画面で、以下の操作を行った場合を想定します。

新規登録時に相手先担当者を設定した場合
└ 登録処理が実行される
└ managerIdが付与

更新時に相手先担当者を削除した場合
└ 編集処理が実行される
└ managerIdがnull

処理の流れ
相手先担当者の登録情報を登録・更新する際、managerIdの有無に応じて処理が分岐します。条件式が設定されており、managerIdに有効な値が入っているかどうかを判定します。
条件式： ${im_startLoop1.item.managerId!=null&&im_startLoop1.item.managerId!=""}
この式は、managerIdが存在している場合に、thenブランチの処理を実行します。逆に、nullまたは空文字の場合は、elseブランチに進みます。
(1) 変数操作：managerIdが設定されている場合
入力データから得られたmanagerIdの値を、エンティティで使う変数managerIdに代入します。これにより、エンティティ登録タスクで、managerIdを直接参照して使用できます。
(2) 変数操作：managerIdが設定されていない場合
identifier関数で新規IDを生成し、その結果をエンティティで使う変数managerIdに格納します。これにより、エンティティ登録タスクで、managerIdを直接参照して使用できます。
(3) 相手先担当者データの登録
入力データを1件ずつ処理し、各アイテムの検証を行ったうえで、検証を通過したデータをデータベースに登録します。すべてのデータ登録が完了すると、繰り返し処理を終了します。
コラム
上記で説明した「相手先担当者登録処理」フローは、共通の処理として設計されています。
このフローでは、相手先担当者の情報を検証・登録・更新する一連の処理がまとめられており、個別のフローごとに同じ処理を繰り返し実装する必要がありません。実際には、「登録処理」フローや「編集処理」フローからサブフローとして呼び出され、対象データに応じて適切に処理を行います。これにより、共通処理の一元化と保守性の向上を図ることができます。
サブフロー呼び出しの設定方法については、「IM-LogicDesigner チュートリアルガイド - 5.2.4. サブフロー呼び出し」を参照してください。
参考
identifier関数とは、IDの生成に使用するマッピング関数のことです。詳細は「intra-mart Developer Portal - マッピング関数を利用して演算処理を行いたい」を参照してください。
操作手順
「相手先担当者登録処理」フローを開き、入力値を設定して、デバッグを実行します。確認ポイントは以下のとおりです。

分岐条件の評価が正しいか

変数値が正しく設定されているか

登録処理が正しく行われているか

「アプリケーション管理」画面から、該当する処理をクリックします。
└ 例：相手先担当者の新規登録に関わる「相手先担当者登録処理」フローを選択します。

［デバッグ］をクリックします。
└ 例：相手先担当者登録処理に関する「ロジックフロー定義のデバッグ」画面が表示されます。

処理を一時停止しながらデバッグを実行するため、［ステップ実行］をクリックします。
└ 「デバッグの実行」ダイアログが表示されます。

分岐条件が正しく動作することを確認するため、［JSON入力］をクリックして、入力値を以下のように設定します。

thenブランチに進むか確認したい場合：managerIdに任意の値（例：user01）

elseブランチに進むか確認したい場合：managerIdを空文字
managerId以外は、以下のように入力してください。
{
  "customerManager": [
    {
      "managerId": "",
      "managerName": "生田一哉",
      "emailAddress": "ikuta@example.com",
      "telephoneNumber": "00-0000-0000",
      "department": "マーケティング本部",
      "post": "一般社員",
      "notes": "2022年度からの主担当者様です。"
    }
  ],
  "companyId": "company01"
}
［実行］をクリックし、ステップ実行でタスクを進めながら、値の変化を確認します。

thenブランチに進むか確認したい場合：

「コンソール」で、分岐条件の評価結果がtrueであることを確認

「変数情報」で、入力managerIdの値が変数managerIdの値にコピーされていることを確認

elseブランチに進むか確認したい場合：

「コンソール」で、分岐条件の評価結果がfalseであることを確認

「変数情報」で、ID生成後のmanagerIdの値が表示されていることを確認

［］をクリックし、「サイトマップ」画面を表示します。

「Repository」から［エンティティ操作ログ一覧］をクリックします。

該当のエンティティを選択します。
└ 例：「相手先担当者_エンティティ」の操作ログを確認します。

操作ログからデータの登録・更新を確認します。
└ 例：「エンティティデータ manager_id」を確認します。

thenブランチに進んだ場合：managerIdに任意の値（例：user01）が表示

elseブランチに進んだ場合：managerIdにID生成後の一意の値（例：8ht4tl482mz2nqk）が表示

参考

フローが途中で終了する場合、条件分岐の設定内容に誤りがある可能性があります。その場合、「IM-LogicDesigner チュートリアルガイド - 5.2.2. 条件分岐を利用したフロー」を参照し、条件式の定義方法などを見直してみてください。

コラム

デバッグ時にはcompanyIdとmanagerIdに任意の値を入力しましたが、実際のアプリケーション実行時には、システムによって自動生成された一意の値が割り振られます。これらの値は、IM-BloomMakerのデバッグツールの「変数」タブで確認できます。

(4) 繰り返し処理で全要素が正しく処理されるか

繰り返し処理の条件には、式表現や配列の変数を指定できます。ここでは、配列の変数を繰り返し条件として設定することで、すべての要素が正しく処理され、意図した結果を取得できるかを検証します。
想定シナリオ
顧客管理アプリの編集画面では、登録済みの顧客情報が表示されます。
顧客情報には会社情報のほかに、相手先担当者や自社担当者の情報も含まれます。さらに、作成日時・作成者・更新日時・更新者といった履歴情報も紐づけられています。
自社担当者は複数のユーザを設定できるため、ユーザコードの配列に対応するユーザ名を取得する処理を繰り返し実行し、その結果を画面に表示します。
ここでは、この繰り返し処理の動作について確認します。
処理の流れ
「参照処理」フローでは、顧客情報→相手先担当者情報→自社担当者情報の順に対象データを取得します。
自社担当者情報では、「ユーザ名配列取得処理」フローをサブフローとして呼び出します。
サブフローでは、自社担当者のユーザコード配列を受け取り、ユーザコードごとにユーザプロファイルを取得し、取得したユーザ名を配列に格納するという繰り返し処理を行います。
操作手順
「ユーザ名配列取得処理」フローを開き、入力値を設定して、デバッグを実行します。確認ポイントは以下のとおりです。

ループ内で全要素が正しく処理されているか

意図しないデータが混入していないか

型の不一致や未取得はないか

「アプリケーション管理」画面から、該当する処理をクリックします。
└ 例：自社担当者情報の取得に関わる「ユーザ名配列取得処理」フローを選択します。

［デバッグ］をクリックします。
└ 例：ユーザ名配列取得処理に関する「ロジックフロー定義のデバッグ」画面が表示されます。

処理を一時停止しながらデバッグを実行するため、［ステップ実行］をクリックします。
└ 「デバッグの実行」ダイアログが表示されます。

繰り返し処理が正しく動作することを確認するため、［JSON入力］をクリックして、入力値を以下のように設定します。

繰り返し処理1回目：ユーザコード"aoyagi"

繰り返し処理2回目：ユーザコード"hayashi"
{
  "userCds": [
    {
      "userCd": "aoyagi"
    },
    {
      "userCd": "hayashi"
    }
  ]
}
［実行］をクリックし、ステップ実行でタスクを進めながら、値の変化を確認します。

正しいuserCdを入力した場合：

「コンソール」で、繰り返し処理が2回実行されていることを確認

「変数情報」で、2つのユーザコードの入力に対し、2つのユーザ名が出力されていることを確認

入力userCd:"aoyagi"→変数userNames/userName:"青柳辰巳"→出力userProfiles/userName:"青柳辰巳"

入力userCd:"hayashi"→変数userNames/userName:"林政義"→出力userProfiles/userName:"林政義"

その他の操作
配列の場合、要素ごとに値を参照・設定するためのインデックス切替バーが表示されます。［］をクリックして、要素番号を指定することで、配列の各要素にアクセスできます。

処理を一時停止しながらデバッグを実行するため、［ステップ実行］をクリックします。
└ 「デバッグの実行」ダイアログが表示されます。

繰り返し処理が正しく動作することを確認するため、［JSON入力］をクリックして、入力値を以下のように設定します。

繰り返し処理1回目：ユーザコード"000"

繰り返し処理2回目：ユーザコード""（空文字）
{
  "userCds": [
    {
      "userCd": "000"
    },
    {
      "userCd": ""
    }
  ]
}
［実行］をクリックし、ステップ実行でタスクを進めながら、値の変化を確認します。

nullまたは空文字を入力した場合：

「コンソール」で、繰り返し処理が2回実行されていることを確認

「変数情報」で、2つのユーザコードの入力に対し、2つのユーザ名が出力されていることを確認

入力userCd:"000"→変数userNames/userName:"null"→出力userProfiles/userName:"null"

入力userCd:""（空文字）→ユーザ名取得に失敗

参考

複雑な処理の場合、スタックオーバーフローエラーが発生し、処理が際限なく繰り返される可能性があります。その場合、「IM-LogicDesigner チュートリアルガイド - 5.2.3. 繰り返し処理を利用したフロー」を参照し、繰り返し条件の定義方法（回数・条件）などを見直してみてください。

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

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

(1) ロジックフローが正しい結果を返しているか​

想定シナリオ​

入力例：

処理の流れ​

(1) 共通情報の準備​

(2) サブフローの呼び出し​

(3) 明細データの繰り返し登録​

操作手順​

(2) 例外・異常時のエラーハンドリングが適切か​

想定シナリオ​

操作例：

処理の流れ​

(1) 顧客情報の検証・更新​

(2) 相手先担当者データの削除とサブフロー実行​

(3) 自社担当者データの繰り返し登録​

操作手順​

(3) 分岐処理が意図通りに正しく実行されるか​

想定シナリオ​

処理の流れ​

(1) 変数操作：managerIdが設定されている場合​

(2) 変数操作：managerIdが設定されていない場合​

(3) 相手先担当者データの登録​

操作手順​

(4) 繰り返し処理で全要素が正しく処理されるか​

想定シナリオ​

処理の流れ​

操作手順​

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

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

(1) ロジックフローが正しい結果を返しているか

想定シナリオ

処理の流れ

(1) 共通情報の準備

(2) サブフローの呼び出し

(3) 明細データの繰り返し登録

操作手順

(2) 例外・異常時のエラーハンドリングが適切か

想定シナリオ

処理の流れ

(1) 顧客情報の検証・更新

(2) 相手先担当者データの削除とサブフロー実行

(3) 自社担当者データの繰り返し登録

操作手順

(3) 分岐処理が意図通りに正しく実行されるか

想定シナリオ

処理の流れ

(1) 変数操作：managerIdが設定されている場合

(2) 変数操作：managerIdが設定されていない場合

(3) 相手先担当者データの登録

操作手順

(4) 繰り返し処理で全要素が正しく処理されるか

想定シナリオ

処理の流れ

操作手順