【JP1/AJS3】DataSpider Servistaの処理をJP1/AJS3で実行すべき 「3つの理由」

データ連携（EAI）ツールとして4,000社以上に導入されているDataSpider Servista(※)の処理（スクリプト）を実行するために、JP1/AJS3が採用されるケースが増えてきています。そこで本記事では、DataSpiderの処理をJP1/AJS3で実行すべき理由と、実際にJP1/AJS3で設定する場合に注意してほしいポイントを解説します。

(※)
DataSpider Servista (以下、DataSpider)は、異なるシステムのデータやアプリケーションをノンプログラミングで「つくらずにつなぐ」データ連携（EAI）ツールです。

DataSpiderにはスケジューラー機能があるため、単体で実行することも可能ですが、対象が重要なシステムであればあるほど、アシストではJP1/AJS3で実行することをお勧めしています。その理由は大きく3つあります。

①監視が可能
JP1/AJS3から実行することで処理の監視が可能です。失敗した場合に管理者に通知することはもちろん、DataSpider側の障害が発生している場合にはジョブが失敗するため、DataSpiderの障害を早期に検知することにも繋がります。
また、JP1/AJS3には遅延監視機能があるため、想定時間内に処理が開始・終了していない場合にも管理者に通知することができます。特に重要なシステムで早期に障害を検知する必要がある場合はJP1/AJS3での実行・監視をご検討ください。

②処理の全体像の把握が可能
大規模、重要なシステムの場合はDataSpider単体の処理ではなく他システムとの連携が発生する場合がほとんどです。その場合、DataSpiderの処理の前処理、後処理をJP1/AJS3で定義することができます。また、JP1/AJS3 - View画面で、どこまで処理が進んでいるかを把握できます。さらに、メモリ不足などOSの障害でサーバが再起動することになった場合、JP1/AJS3から実行していれば、再起動前にどこまで処理が動いていたか、どこから再実行すべきかを早期に判断できます。

③多重度の制御が可能
DataSpiderではデフォルトで多重実行が100個のため、処理命令があった場合に処理の負荷と無関係に100個まで同時に実行しようと試みます。しかしサーバの能力的に実行できない場合は障害に繋がります。DataSpiderの処理をJP1/AJS3で実行することにより、柔軟な多重実行の制御が可能になります。例えば負荷の軽い処理は多重度を多く、重い処理は多重度を少なく、といった実行方法が実現できるためシステムの安定運用に繋がります。

本章では、実際にDataSpiderの処理をJP1/AJS3で実行する場合に、事前に把握しておくべき注意点や、設定をご紹介します。

①DataSpiderとJP1/AJS3は同じサーバに導入する
DataSpiderのスクリプトはリモートのScriptRunner.exeから実行命令が可能なので、JP1/AJS3とDataSpiderのサーバを分けて導入するケースがあります。その場合、スクリプトが正常に終了していてもScriptRunner.exeに結果が正しく返されず、戻り値が「0」とならないことがあるため、JP1/AJS3のしきい値判定では異常終了というステータスになります。JP1/AJS3が正しい終了判定をするため、DataSpiderの処理をJP1/AJS3から実行する場合は、2製品を同じサーバに導入することをアシストでは推奨しています。

もし、サーバを分ける必要がある場合は、終了判定にはファイル判定をお勧めします。JP1/AJS3で実行ファイル（バッチファイルなど）を実行した場合、その実行ファイルが正常に終了したかを判定する手段は下記の2つがあります。
・終了コードのしきい値
・ファイルの有無

ScriptRunner.exeが正常に終了したかを終了コードを使用して判断させると、前述の通りJP1/AJS3が正しい終了判定を下せないケースがあります。そのため、ScriptRunner.exeから呼び出すスクリプト内で処理終了後に判定用のファイルを作成するようにしておき、そのファイルの存在有無をもってJP1/AJS3で終了判定をさせることで、より正確に判定できます。

②ネットワーク資源は使用しない
JP1/AJS3はネットワーク上の資源（共有フォルダのファイルなど）を扱うことが不得手な製品です。また、処理の安定性の面からもお勧めしていません。そのため、ネットワーク上のファイルを使用する処理はなるべく行わず、事前にローカルにコピーするなどしてローカルのファイルを使用する処理にすると、ジョブ実行がより安定します。

③JP1からScriptRunner.exeの処理は止められない
JP1/AJS3は、実行中のジョブを手動または指定した実行時間で強制終了することはできますが、終了できるのはバッチファイルやScriptRunner.exeのみです。そのためScriptRunner.exeから実行されている実際のDataSpider上の処理は止めることができません。この点を踏まえた運用設計を行ってください。

④パスはフルパスで指定する
ScriptRunner.exeへのパスはインストール時には通っていないため、PATH環境変数を指定しない場合、ScriptRunner.exeへのパスはバッチファイル内でフルパスで指定してください。（JP1/AJS3はユーザ環境変数をジョブ実行時に読み込みません。環境変数を指定する場合はシステム環境変数を使用してください。）

⑤遅延監視を実装する
DataSpiderはEAIツールの特性上、色々なクラウド上のサービスへ接続することができます。
そのため、ネットワークの瞬断等によりクラウドとの通信でレスポンスをうまく受信できず、処理が実行中のまま止まってしまうケースがあるため、遅延監視を設定することをお勧めします。DataSpiderには処理遅延を監視する機能がないため、もし遅延を監視したい場合は作りこみが必要ですが、JP1/AJS3では簡単にGUIで遅延監視を設定しておくことができるため、障害を簡単・早期に検知することが可能です。

⑥ジョブの実装は再実行の単位で行う
何か問題が発生し、ジョブを再実行するケースを想定し、スクリプトの開発、実装を行ってください。具体的には、1つのDataSpiderの処理（スクリプト）に複数の処理をまとめてしまうと、ジョブ再実行はそのスクリプトを最初から実行することになるため、既に正常に実行済みの処理も再度実行することになります。そのため、スクリプトは再実行する単位に分割して作成し、JP1/AJS3でジョブという単位で実装することをお勧めします。これにより、障害発生時には必要な処理単位での再実行が可能になります。下図は、DataSpiderの一連の処理をJP1/AJS3のジョブに分割した例です。

⑦引数を渡す方法
ScriptRunner.exeは実行時に実行対象の定義が記述されている起動定義ファイル(*.xml)の指定が必要です。指定はJP1/AJS3のPCジョブのパラメーター欄に定義します。定義方法は下記の通りです。

今回はJP1のNo.1ディストリビューターであり、Dataspiderの販売、サポート実績No.1であるアシストならではの運用ノウハウをご紹介させて頂きました。JP1とDataSpiderの導入をご検討の場合は是非アシストにご相談ください。

「DataSpider」「DataSpider Servista」、その他関連製品名は株式会社セゾンテクノロジーの登録商標または商標です。

いつもJP1サポート技術者ブログをご覧いただきありがとうございます。

アシストとJP1保守契約を締結されている方は、Webサポートセンター「AWSC」をご利用いただけます。本ブログサイトではご紹介しきれない3,000件以上のFAQを公開していますので、是非ご利用ください。
また、アシストではJP1ユーザ企業様向けの無償セミナーや支援サービスを多数ご提供しています。JP1の潜在リスクを洗い出す診断サービスや、バージョンアップ時のノウハウをご紹介するセミナーなどご用意していますので、貴社の課題解決へとお役立てください。アシストと保守契約を締結されていないお客様にもご参加いただけます。詳細は、下記リンクよりご確認ください。