定期的に処理を実行する

運用において、定期的なスケジュールで自動的にプログラムを実行することは非常に有用です。
intra-martでは、定期的な処理の実行に「ジョブ機能」を利用しています。ジョブ機能はバッチ/プログラムを自動で実行するものです。
標準では、以下のようなものが用意されています。

• ジョブ（Task）定義
  • 単一処理単位の定義。Javaクラス・スクリプトなどで処理を実装して登録可能
• ジョブネット（JobNet）
  • 複数ジョブの依存関係・並列・分岐を定義するワークフロー。順序制御や条件分岐を組める
• スケジューリング（定期実行）
  • 日時/繰返し/cron相当での定期実行設定、カレンダー/除外日の設定も可能
• 即時実行API（手動/外部起動）
  • 管理画面の即時実行のほか、JobSchedulerManager#executeやIM-LogicDesignerのREST呼び出しなどで外部から起動可能
• 同時実行制御（スレッド数/キュー）
  • job-thread-count などで同時実行数を制限。待ちキューや優先度制御も運用側で管理
• タイムアウト/リトライ/エラーハンドリング
  • ジョブごとのタイムアウト設定、リトライポリシー、失敗時の分岐設定が可能
• 実行監視・履歴（monitor/ログ）
  • 実行履歴、モニタID を取得して状態追跡。system/exceptionログやジョブ履歴画面で確認
• 完了通知（IM-Propagation）
  • ジョブ/ジョブネット完了をIM-Propagation（PROC_COMPLETEDなど）で通知し、外部連携や後続処理に利用可能
• アクセス制御・実行ユーザ指定
  • ジョブ登録・実行には権限管理。実行に使用するサービスアカウントを指定可能
• 監査・ログ出力設定
  • 実行ログや例外ログの出力、監査ログ（定義変更履歴など）を保持できる

コラム

補足（運用上の注意）
即時実行系APIは非同期で成功/失敗を即時返さない場合が多く、正確な結果判定には monitorIdやIM-Propagationなどの追跡が必要です。 旧バージョン（2018 Spring以前）ではIM-Propagationによるステータス伝播に不具合が報告されているため、正確な完了判定が必要ならバージョン情報確認やmonitorIdベースの実装を推奨します。

ジョブのスケジュール実行は「スケジューラ設定（管理画面）」か「プログラム/APIでの即時起動＋外部スケジューラ（cron など）」のどちらかで実現しますが、このガイドでは、intra-mart Accel Platformのジョブスケジューラ機能、LogicDesigner などを利用するケースを解説します。

ジョブ/ジョブネットをスケジューリングする

intra-mart Accel Platform の「ジョブ/ジョブネット」を定期実行（スケジューリング）する手順を、設計 → 実装 → 運用の観点で整理して説明します。

参考

製品のバージョンや導入形態（IM-LogicDesignerを使うか、管理画面で定義するか など）によって画面位置やAPIパスが異なるため、具体的な画面操作やAPIのURLが必要な場合は、以下のページを参照してください。
「テナント管理者操作ガイド - ジョブを設定する」

全体の流れ（概要）

1. 要件定義：何を・いつ・失敗時の挙動
2. ジョブ/ジョブネットの設計：タスク設計・依存関係・タイムアウトなど
3. ジョブ/ジョブネットの実装・登録：IM-LogicDesigner または管理画面/開発実装
4. スケジュール設定：定期実行の設定・カレンダー
5. 即時実行（テスト）と外部トリガ：即時実行・スケジュール実行の検証
6. 監視・通知・運用ルールの設定：障害の早期検知と即時対応のためのルールの明確化
7. 本番投入・運用監視・保守：運用時の注意点や監視対象など

各項目の詳細を見ていきましょう。

1.要件定義

要件定義は、必須で明確にする項目です。何をいつ、どのように実行するか・失敗時の挙動をどうするか、などを決めておきましょう。

• 実行内容：単一ジョブか複数ジョブのジョブネットか
• 実行頻度：毎分/毎時間/毎日/週次/cron 相当の複雑な条件か
• 実行時間帯：バッチ時間帯、タイムゾーン要件
• 同時実行の可否：同一ジョブの多重実行を許すか
• 失敗時の対応：リトライ回数・通知（メールなど）・代替処理
• 実行結果の確認方法：同期で結果を取得する必要があるか（通常は非同期）
• 外部からの即時起動が必要か：API 連携/外部スケジューラでの起動

2.ジョブ/ジョブネットの設計

• ジョブ（Task）の粒度を決める：一つのジョブは単一機能に絞るのが運用上望ましい
• 各ジョブに対して設定する項目：タイムアウト、リトライ回数、リトライ間隔、失敗時のブランチ（停止/継続）、出力（ログ・戻り値）
• ジョブネットの設計：並列実行や依存関係（先行/後続）を図にして設計。条件分岐や並列ノードを整理
• 外部資源（DB/外部API/ファイルなど）を使う場合：接続情報・接続数上限を考慮する

3.ジョブ/ジョブネットの実装・登録

方法は主に 1. IM-LogicDesigner でモデル定義　2. 管理画面/開発でジョブ定義（Java/スクリプト） のいずれかになります。

1. IM-LogicDesigner を使う場合

• LogicDesigner で新規ジョブ（タスク）を作成し、処理ロジック（スクリプト/呼出し）を定義
• ジョブをジョブネット内に配置して、依存関係・分岐を設定
• ジョブ内で必要な入出力パラメータを定義しておく

2. Java などで実装する場合

• ジョブの処理を Java クラスや製品のタスクインタフェースに合わせて実装し、デプロイ
• 管理画面や開発用の登録画面でそのジョブを登録

権限・ロール

• ジョブ/ジョブネットの登録・編集には管理者ロールが必要。システム上の権限を確認し、運用用サービスアカウントを用意する

4.スケジュール設定

テナント管理 > ジョブ管理 のジョブ設定・ジョブネット設定画面、または LogicDesignerのスケジュール設定画面でスケジュールを作成します。

• 設定項目（代表例）

  • 開始日時/終了日時、繰返し間隔（cron形式が使える場合はcron式）、対象ジョブネットID
  • 実行タイムゾーン、カレンダー（業務日カレンダ、祝日除外）、除外日
  • 優先度、スロット数（同時実行制御）や実行環境（ApplicationRuntime指定など）
  • 実行ユーザ（サービスアカウント）を指定

• 注意点

  • サーバのシステム時刻（NTP設定）とタイムゾーンを必ず合わせる
  • 夏時間やタイムゾーン切り替えの影響を考慮する（cron設定ではずれが出る場合あり）
  • 同時実行を禁止する場合は排他フラグやロック設定を利用する

5.即時実行（テスト）と外部トリガ

管理画面から「即時実行」や「手動実行」で動作確認を行います。

• 外部システムから即時実行する場合の代表的手段

  • IM-LogicDesignerのREST API（認証：Basic/OAuth2など）経由で即時実行タスクを呼ぶ（LogicDesignerでジョブネット起動タスクを用意）
  • Web API Makerでジョブ起動用の REST/SOAPを公開し、外部から呼ぶ
  • Java製のWebサービスを実装し、内部API（JobSchedulerManager.execute　など）を呼ぶ

• 製品API（サーバサイド Java）例

  • JobSchedulerManagerのexecuteメソッドでジョブネットを即時起動するAPIが提供されている（詳細はAPIドキュメント参照）
  • 即時実行APIは非同期実行となり、実行の成否を即座に返さない実装が一般的（モニタIDなどで後追いする方法を取る）

テスト手順（推奨）

• 開発環境でまずは単体テスト（即時実行）、ログ出力・例外ハンドリングを確認
• スケジュールを短い周期で設定してスケジュールの動作を検証（例：数分ごと）
• 失敗シナリオ（DB切断、外部API障害など）を作ってリトライや通知の挙動を確認
• IM-Propagation受信側の分岐（PROC_COMPLETED）で status値が期待通りに渡るか確認
• monitorIdを取得できる場合はそれを用いた後続の結果取得・追跡を動作確認

参考

補足（API 呼び出しの戻り値など）
製品APIの戻り値や取得方法はバージョンによって異なります。executeの戻り値（monitorIdが返るか など）の詳細は、ご利用バージョンのAPIドキュメントをご確認ください。

6.監視・通知・運用ルールの設定

即時実行やスケジュール実行は非同期で動くケースが多く、ジョブネットの「成功/失敗」を即戻りで取得できないことが多い点に注意しましょう。

• 実行結果を得る方法
  • IM-Propagation（PROC_COMPLETEDイベント）を利用してジョブネット完了を通知する（受信側モデルのstatusフィールドで成功/失敗判断）
  • ジョブスケジューラのモニタ画面や履歴テーブルからmonitorIdを使って状態を確認。APIでmonitorIdからログや結果を取得できる場合がある

参考

既知の注意点（バージョン依存）
intra-mart Accel Platform 2018 Spring以前の一部バージョンでは、ジョブネット完了時にDBに接続できないと IM-Propagationの受信側で不正にSUCCESSが渡される不具合が報告されています。
ジョブ実行結果に応じた正確なステータス取得が必要な場合は、2018 Summer以降の修正バージョンにアップデートするか、モニタIDを使ってJobSchedulerManager経由で結果を取得する などの回避策をご検討ください。

7.本番投入・運用監視・保守

本番での同時実行負荷や外部連携の差異によりステージングと挙動が異なることがあるため、段階的に有効化します。

• 事前準備（必須）

  • ステージングでジョブ/ジョブネットの総合試験を完了する（即時実行、スケジュール実行、失敗時挙動の確認）
  • 監視・通知設定（監視対象、閾値、通知先）を本番に合わせて適用
  • ログ出力（ジョブ内ログ・例外ログ）のレベルを本番向けに調整（DEBUGは原則オフ）
  • 実行に使用するサービスアカウント情報、DB接続情報を確認。認証方式（SSOなど）があればバッチ用の代替手段を用意

• リリース手順（例）

  • メンテナンスウィンドウを設定・告知（テナントへ影響有無を明示）
  • 本番へデプロイ（ジョブ定義データ/Javaアーティファクトなどを配置）
  • スケジュールを有効化せずに、まず即時実行で個別ジョブをテスト
  • 問題が無ければスケジュールを順次有効化。最初は短周期で監視を強める（例：初24時間は実行後直ちに確認）
  • 異常が無ければ通常運転へ移行。初期週は日次で状態を確認

ログ監視

障害解析の早期収束は適切なログ収集と保存が前提です。

• 監視対象

  • ジョブスケジューラのジョブ履歴、エラーログ、実行時間、リソース使用状況

• ログ確認場所

  • ジョブネットモニタ一覧画面、ジョブスケジューラの管理画面（履歴・ログ）、サーバログ（アプリケーションログ、例外ログ）、OSレベルのログ

• 監視・アラート

  • 失敗時にメール通知/Webhookなどで即時アラート
  • 予定実行が実行されなかった場合のアラート（タイムスタンプ差分監視）

ログ管理・トレース（取得・保管・分析）

• 取得箇所（必ず収集）
  • intra-martのsystem.log、exception.log、ジョブスケジューラのログ、Resinのログ、Webサーバログ、DBログ
• 保管ポリシー
  • 例：直近30日分は即時検索可能に保持、30日〜180日は圧縮アーカイブ、180日超は長期保管（規約により変更）
  • ログローテーションを自動化（logrotateなど）
• 解析
  • 集約ログ基盤（ELK/Prometheus+Grafana　など）へ連携し、検索・ダッシュボード・アラートを充実させる。特にERRORの傾向分析を定期実施
• 障害時のログ収集テンプレ
  • 該当時刻のsystem.log、exception.log、job schedulerログ、Resinのgc.log、thread dump（JVMのスレッドダンプ）、DBのslow query logを取得して保管

運用時の注意点・ベストプラクティス

• 作業は業務影響の少ない時間に行う（特に本番でのスケジュール変更）
• ライセンスや認証方式（統合認証/SSO）がバッチ実行に与える影響を事前確認する。統合認証環境ではバッチ実行用に別のApplicationRuntime/サービスアカウントが必要になる場合あり
• スケジュール設定は冗長/冗長化を考慮（HA環境ではスケジューラの二重起動防止など）
• ジョブのログは一定期間保持して、障害時に参照できるようにする
• 外部からAPIを叩いて起動する場合はHTTPSと強固な認証（サービスアカウント、OAuth2、APIトークン）を使い、認証情報は安全に保管する。最小権限で運用する
• 定期的に古いジョブ履歴の削除やログローテーションを実施し、ディスク肥大を防ぐ

よくあるトラブルと確認ポイント

• スケジュールされない：ジョブが無効になっている、スケジュールの有効フラグ、サーバ時刻/タイムゾーン、権限不足を確認
• 失敗時に正しいステータスを受け取れない：IM-Propagationの設定・バージョン依存の不具合を疑う。monitorIdでの結果確認を検討
• 外部から起動時に認証エラー：APIの認証方式、対象サービスアカウントの権限、HTTPS証明書やACLを確認
• 同時実行で想定外の競合：排他制御やリソース制限の設定を見直す

外部連携での設計上の推奨

• 外部スケジューラ（cronなど）で時刻管理し、ジョブ実行はintra-martのAPI（LogicDesigner REST/Web API Makerで公開したエンドポイント/カスタムWebサービス）を呼ぶ方式にすると、スケジュール設計が柔軟でログ追跡がしやすい
• ただし、外部から直接DB操作や内部APIにアクセスするのは避け、公開APIをラップして堅牢に制御すること

定期点検・運用作業（保守スケジュール）

定期的な点検で未然防止と継続的改善を図ります。

• 日次
  • 監視アラートの確認、前日分の失敗ジョブ一覧確認、未処理ジョブの確認（待ちジョブ）
• 週次
  • 長時間実行ジョブの分析、失敗傾向のレビュー、必要なスケジュール調整
  • ログ容量の確認、ディスク空きの確認
• 月次
  • ジョブの実行統計（成功率、平均実行時間、ピーク時間帯）レビュー
  • DB 接続プールや JVM ヒープのチューニング案検討
• 四半期
  • バージョン・セキュリティパッチ適用計画、リソース増強計画の検討
  • 運用手順・ランブックの見直しと関係者への教育
• 年次
  • DR（災対）訓練、障害時のフルリカバリ演習、ライセンス・契約の確認（期限・台数）