サービスの開発

本ページでは、DataSpider Servistaでサービスを実際に開発するにあたって必要となる、実践的な概念や機能について記述します。

本ページの記述は、前項「サービスの基礎知識」を読了し、サービスの基本的な概念やスクリプトの作成方法について理解していることを前提としています。

事前準備

サービスの開発を行う前に必要となる準備について説明します。

開発標準の設定

開発標準の設定

サービスの開発において、開発を始める前に開発標準を設定することは、成果物に一定の統一性をもたらし、品質、生産効率、保守性などの向上を目指す上でとても重要な要素となります。
開発を始める前に、以下の各項目に対してどのように作業するのか決定しておくことを推奨します。

プロジェクトやスクリプトの構成

プロジェクトの処理単位
スクリプトの処理分割単位
プロジェクト間およびスクリプト間の値の受け渡し方法
1スクリプト内のコンポーネントアイコン数

プロジェクト内のスクリプト数が多くなりすぎると、プロジェクトの保存やスクリプトのロードに時間が掛かる場合があります。
そのため、状況に合わせてプロジェクトを分割することをお奨めします。
また、1スクリプト内のコンポーネントアイコン数が多くなると、可読性が落ちてメンテナンスに支障をきたしたり、メモリ使用量が多くなりDataSpiderServerの負担が大きくなる場合があります。
そのため、スクリプト呼び出し処理などを使用して、処理ごとにスクリプトを分割することをお奨めします。1スクリプト内のコンポーネントアイコンの推奨最大数は100個となります。

開発および本番環境

開発および本番稼働の実行時のログレベル
開発および本番稼働時に使用するグローバルリソースの種別

ログレベルの詳細については、「ログレベル」を参照してください。

種別の詳細については、「種別」を参照してください。

ファイルの保管場所

読み込みおよび書き込みを行うファイルの保管場所

ファイルシステムの詳細については、「DataSpiderファイルシステム」を参照してください。

命名規約

プロジェクト名
環境変数名
スクリプト名
スクリプト変数名
コンポーネント名
グローバルリソース名
サービス名
トリガー名

使用禁止文字については、「DataSpider Servista使用禁止文字について」を参照してください。

スクリプトのデザイン

フローのレイアウト
フローは横に流れるように引くのか、縦に流れるように引くのかなどを決定する

コンポーネントのレイアウト
コンポーネント間の配置間隔や、どのグリッドを表示して配置するのかなどを決定する

マッピングキャンバスでのロジックのレイアウト
ロジック間の配置間隔や、どのグリッドを表示して配置するのか、レイヤの分け方などを決定する

その他

例外監視の方法および例外処理時の動作
アプリケーションログの出力メッセージ
コメントおよびメモの表記

例外監視の詳細については、「例外監視処理」を参照してください。

アプリケーションログの詳細については、「アプリケーションログ出力先設定」を参照してください。

その他、プロジェクトに最適な開発標準を適宜設定してください。

チーム開発

チーム開発(複数人によるサービスの開発)において必要となる機能について説明します。

リポジトリDB
チーム開発機能

リポジトリDB

チーム開発を行う際には、リポジトリDBを設定して、ユーザ管理機構を使用する必要があります。

リポジトリDBとは

リポジトリDBは、RDB(リレーショナルデータベース)内に設定したリポジトリ領域にて、サービスやユーザ情報、各種設定データを管理する機構です。
リポジトリDBが未設定の場合、ユーザ管理機構やファイルのアクセスコントロールの機能を使用することはできません。

リポジトリDBの設定

リポジトリDBの設定は、インストール時に行います。設定の変更はコントロールパネルから行います。

インストール時の設定については、PDFドキュメントの「DataSpider Servistaインストールガイド」を、インストール後の設定については、「リポジトリDB管理」を参照してください。

リポジトリDBは、1つのDataSpiderServerにつき1つ用意してください。複数のDataSpiderServerで同一のリポジトリDBに接続することはできません。

リポジトリDBとして使用するデータベースのインスタンスはリポジトリDB専用とし、他システムでの使用は行わないでください。

リポジトリDBの構築

リポジトリDBはリポジトリ領域を設定したデータベースに専用のテーブルを作成し、データを保存します。テーブルの作成はDataSpiderServerの起動時に行われます。
すでに専用のテーブルが存在していた場合は新規に作成せず、既存のテーブルを使用します。

リポジトリDB有り/無しの動作

リポジトリDBを使用する・しない場合の動作は以下の通りです。

リポジトリDBを使用する場合(リポジトリDB有り)
- 複数のユーザ・グループの作成、およびアクセス権限の管理が可能
- 各種ファイルのメタ情報をリポジトリ内に保持
- 各種設定をリポジトリ内に保存可能
リポジトリDBを使用しない場合(リポジトリDB無し)
- 1種類のユーザ・グループのみを使用可能
- 各種ファイルのメタ情報や各種設定はOSのファイルシステムに保持

チーム開発機能

チーム開発機能とは、複数人によるサービスの開発をスムーズに行うことができるように用意された拡張機能群です。
統合開発環境(IDE)やバージョン管理システムをベースに作られているため、これらの製品を使用したことがある開発者向けの機能となります。

詳細については、「チーム開発機能」を参照してください。

大容量データの対応

DataSpider Servistaでは、大容量データを扱った際にメモリ不足にならないように、スマートコンパイラと大容量データ処理という2つの機構を用意しています。

デフォルトではスマートコンパイラは有効になっています。スマートコンパイラは理論上データ容量の制限がないパラレルストリーミング処理(以下:PSP)を自動で適用する機能です。
PSPでは、ブロック単位で分割したデータの読み取り・変換・書き込みといった一連の流れをマルチスレッドで処理するため、大容量データを高速に処理することができます。
ただし、PSPは機構の特性上すべての処理が対応しているわけではありません。

PSPの詳細については、「パラレルストリーミング処理」を参照してください。

PSPに対応するコンポーネントについては、「パラレルストリーミング処理で使用できるコンポーネント」を参照してください。

PSPに対応していない処理では、メモリ不足を回避するためには、処理するデータ量に合わせてDataSpiderServerのヒープサイズを変更するか、大容量データ処理を有効にしてください。

DataSpiderServerのヒープサイズの変更方法については、「プロパティリファレンス」を参照してください。

大容量データ処理は、処理に必要な最低限のデータのみをメモリに格納し、他のデータをファイルに保存することで、メモリを大量に使用せずに大容量のデータの処理を実現することができます。
ただし、メモリ不足が発生しない代わりにディスクアクセスが発生するため、処理のパフォーマンスはオンメモリ処理時に比べ劣化します。
パフォーマンスが要求される要件定義では、大容量データ処理を無効にして、オンメモリ処理を行うということも考えられます。

大容量データ処理の設定については、「大容量データ処理」を参照してください。

PSPと大容量データ処理の双方が有効になっている場合、PSPが優先され、大容量データ処理は行われません。
ただし、PSPで実行した読み取り処理の後続で、Mapperを経由してPSPに対応せず書き込む場合、Mapperと書き込み処理の間では大容量データ処理が行われます。

開発支援機能

DataSpider Servistaでは、サービスの開発を円滑に進めることができるように、さまざまな支援機能が用意されています。
ここでは、その中で主な機能について説明します。

メモ
ログレベル
デバッグ実行
ブレークポイント
グリッドとアイコンの整列
変数
検索機能

本項は、「サービスの基礎知識」ページの「スクリプトの作成と実行」で作成したスクリプトを基に説明します。

メモ

メモコンポーネントを活用して処理概要や注意事項などを記述することにより、スクリプトの可読性を上げ、引き継ぎやメンテナンスを円滑に行うことができます。

デザイナのツールパレットの「基本」カテゴリから、「メモ」をスクリプトキャンバスにドラッグ&ドロップして配置します。
メモの大きさや配置位置を決定し、スクリプト自体の説明や各コンポーネントの説明などをメモに入力します。

メモの表示枠をダブルクリックすることで、アイコン表示の状態にすることができます。

メモを対象コンポーネントにマウス右ボタンでドラッグすることにより、関連付けを行うことができます。こうすることで、メモがどのコンポーネントに対する説明を記述しているのかを分かりやすく示すことができます。

ログレベル

デザイナからのスクリプト実行時に出力するログのログ出力レベルを設定します。
ログレベルに応じて出力される内容が異なり、開発時には詳細なログを出力することで、正常処理時の処理内容の把握や、エラー発生時の問題解決に役立てます。

ログレベルは以下の種類から選択することができます。ログレベルを低くすると、より詳細なログが出力されます。

	ログレベル
↑ 高低 ↓	NOTICE
	INFO
	FINFO
	FINEST
	DEBUG

デザイナからのスクリプト実行時に出力するログレベルを設定するには、[ツール]メニューから、[オプション]を選択します。

オプション設定画面が開きます。
ここでは、もっとも詳細な情報が取得できる「DEBUG」に変更し、[OK]ボタンを押下します。

[XMLログ]の[有効にする]チェックをはずした場合は、ログは出力されません。

ログレベルの詳細については、「ログレベル」を参照してください。

デバッグ実行

デバッグ実行を行うことで、各コンポーネントごとの処理時間やスクリプトの実行ログを確認することができます。
また、ブレークポイントを設定した箇所でスクリプトの処理を一時停止し、その時点で保持されているスクリプト変数の値を確認することもできます。

デバッグ実行を行うには、ツールバーから、[スクリプトのデバッグ実行の開始/再開]ボタンを押下します。

ブレークポイントを設定している場合は、スクリプトの処理がそのコンポーネントの箇所で一時停止されます。

ブレークポイントで一時停止した状態では、処理済みのプロセスフローは赤色で表示されます。

デバッグ実行の場合、通常のテスト実行と以下の動作が異なります。

実行履歴ビューに各コンポーネントごとの処理時間が表示される
実行ログビューの[実行ログ]タブにはスクリプト実行時のログが、設定したログレベルに応じて表示される
実行ログビューの[デバッグ情報]タブにはその時点で保持されているスクリプト変数の値を確認できる

ツールバーから、[スクリプトのデバッグ実行の開始/再開]ボタンを押下すると、処理が再開されます。

ブレークポイント

ブレークポイントとは、デザイナで作成したスクリプトをデバッグ実行した際に、スクリプトの処理を一時停止するポイントのことです。このポイントを設定することで、スクリプト実行途中でのスクリプト変数の値の確認などを行うことができます。
デバッグ実行とブレークポイントを有効的に活用することで、サービスの開発を効率的に進められます。

ブレークポイントの設定は、スクリプトキャンバス上のコンポーネントアイコンの右クリックメニュー[ブレークポイントの設定/解除]から行います。ブレークポイントの設定を行うと、コンポーネントアイコンの上にブレークポイントマークが付与されます。

コンポーネントアイコンの表示	状態
	ブレークポイント設定状態
	ブレークポイント解除状態

ブレークポイントの解除は、設定時と同様に、コンポーネントアイコンの右クリックメニュー[ブレークポイントの設定/解除]から行います。

グリッドとアイコンの整列

スクリプトにグリッドを設定したり、アイコンの整列機能を使用してアイコンの並びを整えることは、スクリプトの可読性を上げ、不具合を未然に防いだりメンテナンス効率を上げる効果があります。
グリッドとアイコンの整列は、スクリプトキャンバス・Mapperエディタの両方で使用できます。

詳細については、「デザイナ」を参照してください。

グリッド

グリッドには以下のサイズが存在します。サービス内で使用するグリッドを統一することで、スクリプトがより見やすくなります。

32*32	16*16	8*8

アイコンの整列

複数のコンポーネントアイコンを選択状態にすると、アイコンの整列が使用できるようになります。
2個以上の選択で、「左揃え」「右揃え」「上揃え」「下揃え」が、3個以上の選択で「左右に整列」「上下に整列」が使用できます。

選択次第では、アイコンの位置が崩れてしまうこともありますが、そのような場合にはUndo/Redoで状態を戻してください。

変数

変数の特性を生かした設計を行うことにより、構成の変更などにも対応できる柔軟なサービスを構築することができます。

スクリプト変数

主にスクリプト内のデータのテンポラリやスクリプト間のデータの受け渡しとして使用します。
ユーザが自由に定義でき、複数のデータ型が用意されています。
スクリプト内での値の格納は、変数MapperやドキュメントMapperで行います。入力フィールドに記述する場合は、文字列と組み合わせて使用することもできます。
もっとも汎用的に使用することができますが、スクリプト単位で定義するため、システム全体で共通に使用したり、運用の中で構成の変更が入りそうな箇所には環境変数を使用することを推奨します。

環境変数

ユーザが自由に定義できます。システム全体で共通に使用することができるため、サービスの運用において変更の可能性がある文字列(たとえばファイルパスやグローバルリソースなど)に使用することを推奨します。
文字列と組み合わせて使用することもできるため、たとえばファイルのディレクトリのみが変更される可能性がある場合は、「%{FILE_DIR}/read_file.csv」のように記述できます。
このように定義しておけば、運用の中で構成の変更が入っても、サービスを修正せずに環境変数の設定のみを変更すれば良いため、柔軟な対応が可能となります。

設定方法については、「環境変数管理」を参照してください。

コンポーネント変数

各アダプタのオペレーションごとに定義されています。処理したデータの数や、エラー内容などのオペレーションの処理結果が格納されています。
ユーザが値を格納することはできません。
スクリプト内での値の取得は、変数MapperやドキュメントMapperで行います。

トリガー変数

各トリガーごとに定義されています。トリガーのさまざまな情報をサービスとやり取りする際に使用します。
ユーザが値を格納することはできません。
トリガーの設定画面でのみ使用可能です。

検索機能

マイプロジェクト、マイトリガー、グローバルリソースの設定、デザイナには、それぞれ専用の検索機能が用意されています。
たとえば、ある程度開発が進んだ段階でサービス名やグローバルリソース名、変数名を変更するといった場合、それらの設定がどこで使用されているかを把握していないと修正による影響範囲が見えません。
マイプロジェクトの「プロジェクトの検索」ではスクリプト上の設定項目を、マイトリガーの「トリガーの検索」ではトリガーの設定項目を、グローバルリソースの設定の「グローバルリソースの検索」ではグローバルリソースの設定項目を、それぞれ条件を細かく指定して検索することができます。
これらの機能を有効活用することによって、修正範囲を把握した上で工数を効果的に削減し、後続のフェーズであるテストや運用への負担を最小限に抑えることが可能です。

以下では、例としてサービス名を変更する場合の検索方法を説明します。

サービス名は、スクリプト呼び出し処理やトリガーで指定されます。
そのため、まずはマイプロジェクトの「プロジェクトの検索」で、条件を「使用しているサービス名」に設定して検索を行います。

次に、マイトリガーの「トリガーの検索」で、条件を「使用しているサービス名」に設定して検索を行います。

検索結果に表示されたコンポーネントやトリガーが、変更による影響範囲ということになります。

多様な補助コンポーネント

DataSpider Servistaでは、スクリプト内の処理をより柔軟に記述するために、多様な補助系のコンポーネントを用意しています。
ここでは、その中でも使用頻度が高いコンポーネントを説明します。

アプリケーションログ出力
例外監視
条件分岐
Mapper

アプリケーションログ出力

スクリプト実行中に発生したエラーや、処理内容のログをアプリケーションログとして出力することができます。
コントロールパネルの「アプリケーションログ出力先設定」画面にて、アプリケーションログ出力の設定を行い、スクリプト中でログを出力したい箇所に「ログ出力」コンポーネントを配置します。

アプリケーションログ出力先の種類

アプリケーションログは、以下の種類から出力先を選択することができます。

Syslog:遠隔のSyslogデーモンへログを送信します。
NTイベントログ:NTのイベントログシステムに追加します。
ローテーションファイル:ログをファイルに出力します。ファイルが[最大ファイルサイズ]に到達した際にロールアップを行い、[バックアップファイル]の指定分のバックアップファイルを保持します。
スケジュールファイル:ログをファイルに出力します。スケジュールに合わせてログファイルをロールアップし、バックアップファイルを保持します。

アプリケーションログ出力先の設定手順

Studioの「コントロールパネル」から、「アプリケーションログ出力先設定」を押下します。

「アプリケーションログ出力先設定」画面にて、[新しいアプリケーションログ出力先の追加]を押下します。

「新しいアプリケーションログ出力先の追加」画面にて、ログの種類に「ローテーションファイル」を選択し、[次へ]ボタンを押下します。

[ログ出力先設定名]に、「アプリケーションログ出力先」と入力します。
[ファイルパス]に、「<任意のパス>/applog.log」と入力します。

[OK]ボタンを押下します。

アプリケーションログ出力先の設定の詳細については、「アプリケーションログ出力先設定」を参照してください。

例外監視

例外監視とは、対象となる処理の例外を監視し、例外処理を行うコンポーネントです。

例外監視の設定手順

デザイナのツールパレットの「基本」カテゴリから、「例外監視」をスクリプトキャンバスにドラッグ&ドロップします。

例外を監視したいコンポーネントを囲むように、「例外監視」コンポーネントを配置してフローを引きます。
ここでは、CSVファイルの読み取りと書き込み処理の実行時に発生するエラーを取得します。

デザイナのツールパレットの「基本」カテゴリから、「ログ出力」をスクリプトキャンバスにドラッグ&ドロップします。

新規ログ出力処理のプロパティ設定ダイアログが開きます。

[メッセージ]に「エラーが発生しました。」を入力し、[完了]ボタンを押下します。

例外が発生した場合は、ログを出力するようにフローを引きます。

「/data/inputdata.csv」を一時的にリネームし、CSVファイルの読み取り処理でエラーが発生するようにします。
リネーム後、スクリプトを実行します。

スクリプト終了後、アプリケーションログファイルの出力先「<任意のパス>/applog.log」の内容を確認します。

確認後は、CSVファイルを「/data/inputdata.csv」に戻してください。

例外監視コンポーネントの詳細については、「例外監視処理」を参照してください。

ログ出力コンポーネントの詳細については、「ログ出力処理」を参照してください。

条件分岐

条件分岐を設定することにより、ある条件に合致した場合に処理の内容を変更することができます。

条件分岐の設定手順

デザイナのツールパレットの「基本」カテゴリから、「条件分岐」をスクリプトキャンバスにドラッグ&ドロップします。

新規条件のプロパティ設定ダイアログが開きます。

[追加]ボタンを押下し、以下の条件を設定します。
[条件の種類:]に、「変数と固定値の比較」を選択します。
変数「csv_write:count」が「次の値以上の場合」「1」となるように条件を設定します。

「End」コンポーネントの前に条件分岐するように配置します。

デザイナのツールパレットの「基本」カテゴリから、「end」をスクリプトキャンバスにドラッグ&ドロップします。
「condition」から「End」へフローを引きます。

「End」コンポーネントを選択し、プロパティインスペクタを表示します。
[戻り値]に、「1」を入力します。

「/data/outputdata.csv」にデータが書き込まれない場合は、スクリプトの戻り値が「0」になります。
また、1件以上のデータが書き込まれた場合は、スクリプトの戻り値が「1」になります。

条件分岐コンポーネントの詳細については、「条件分岐処理」を参照してください。

end処理の詳細については、「end処理」を参照してください。

Mapper

Mapperとは、専用のGUIツール(Mapperエディタ)を使用し、あるコンポーネントで読み取ったデータを変換・加工して別のコンポーネントに書き込んだり、変数に代入することができるコンポーネントです。

Mapperの種類

Mapperは、以下の3種類のコンポーネントを含む総称です。

ドキュメントMapper
(処理名:マッピング)
変数Mapper
(処理名:変数代入)
マージMapper
(処理名:マージ)

Mapperの機能

Mapperの主な機能は以下の通りです。

演算/計算
文字の加工
条件抽出
ソート
コード変換
マージ

Mapperの設定手順

Mapperエディタの画面左右に表示された項目を線でつないで入出力のマッピングを指定します。また、マッピングの間にMapperロジックを挟むとロジックの機能に従って、さまざまな演算や加工を行うことができます。

ここでは、ドキュメントMapperを使用し、CSV読み取り処理で読み取ったデータを変換して書き込み処理を行うスクリプトを作成します。
デザイナのツールパレットの「変換」カテゴリから、「マッピング」をスクリプトキャンバスにドラッグ&ドロップします。

「csv_read」から「mapping」へプロセスフローとデータフローを引きます。
同様に「mapping」から「csv_write」へプロセスフローとデータフローを引きます。

「csv_write」をダブルクリックし、CSVファイル書き込み処理のプロパティ設定ダイアログを開きます。

[追加]ボタンを押下し、[列名]入力フィールドに「商品名」を入力します。
もう一度[追加]ボタンを押下し、[列名]入力フィールドに「数量」を入力します。

[完了]ボタンを押下してプロパティ設定ダイアログを閉じます。

「mapping」をダブルクリックし、Mapperエディタを開きます。

左側の入力元コンポーネントのスキーマから、要素「商品名」をマウスでドラッグし、右側の出力先コンポーネントのスキーマの要素「商品名」へドロップします。

要素「商品名」のデータは、変換せずに出力先へ渡します。
要素「数量」のデータは、入力元から読み取ったデータを変換して出力先に渡します。

ツールパレットの「数値」カテゴリから、「数値定数」をマッピングキャンバスにドラッグ&ドロップします。
同様にツールパレットの「数値」カテゴリから、「足し算」をマッピングキャンバスにドラッグ&ドロップします。

配置した数値定数ロジックをダブルクリックし、数値定数ロジックのプロパティダイアログを開きます。
[数値]に「50」を入力します。
[コメント]に「50を加算する」を入力し、[完了]ボタンを押下します。

左側の入力元コンポーネントのスキーマから、要素「数量」をマウスでドラッグし、「足し算」へドロップします。
「数値定数」をマウスでドラッグし、「足し算」へドロップします。
「足し算」をマウスでドラッグし、右側の出力先コンポーネントのスキーマの要素「数量」へドロップします。

スクリプトを保存後、実行します。

スクリプトの実行後、エクスプローラから「/data/outputdata.csv」を開き、書き込んだデータの内容を確認します。

「/data/inputdata.csv」の数量の値が加算され、「/data/outputdata.csv」に書き込まれたことが確認できました。

ドキュメントMapperの詳細については、「Mapper」を参照してください。

変数に保持された値の加工および変換を行うための変数Mapperの詳細については、「Mapper」を参照してください。

複数の入力データを統合するためのマージMapperの詳細については、「マージMapper」を参照してください。

繰り返し処理のログ設定

繰り返し処理(繰り返し処理、繰り返し(条件指定)処理、繰り返し(データ件数)処理)では、個別にログ設定を行うことができます。

繰り返し処理はループごとにログが出力されるため、ループ回数に比例してXMLログの出力容量が大きくなります。
ファイル肥大化によってディスク容量が圧迫されると、DataSpider Servistaはもとより他のシステムへも影響を与えるため、開発段階から運用を想定した対処が必要になってきます。
対応策としては、実行時の「ログレベル」変更や、ログのロールアップといったこともありますが、繰り返し処理のログ設定を行えばスクリプト全体のログレベルを変えることなく、繰り返し処理内のコンポーネントのログレベルだけを変更することが可能です。
低いログレベルを設定したり、XMLログを出力しない設定にした場合、ファイルの容量が抑えられる他に、副次的な効果としてログ出力のコストが軽減されることによるパフォーマンスの向上も考えられます。

アクセス履歴の記録

アクセスログは、DataSpider StudioやDataSpider Studio for Web、CLI Console、ScriptRunner、トリガーなどの各種クライアント/ツールからDataSpiderServerにアクセスした処理を、ログに出力する機能です。
アクセスログを有効にすると、「何がどのユーザにいつどのツールでどう行われたか」という内容のログが専用のログファイルに出力されるようになります。

アクセスログの使いどころとしては、以下のようなことが考えられます。

ユーザの使用履歴を記録し管理する
不正な使用があった場合の監査証跡として残す
障害時の原因究明に役立てる

そのため、開発・運用のフェーズに依らず、必要に応じて機能を有効にすることで、有益になりうる情報を記録しておくことができます。
なお、ログファイルは日次でローテーションされますが、自動で削除はされないため、ディスク容量が圧迫されないように管理する必要があります。

サービス実行ツールの選定

開発が完了したスクリプトはサービスとして登録を行い、各種実行ツールから呼び出します。
要件や処理の特性に合わせて、どの実行ツールを使用するかを選定します。
ここでは、サービスの登録方法から各種実行ツールでの実行方法について説明します。

サービス登録
トリガー
ScriptRunner
ScriptRunnerProxy

サービス登録

DataSpider Servistaでは、開発中のスクリプトと開発が完了したスクリプトとを区別しています。
サービスとして登録されていないスクリプトは、開発中のスクリプトと見なされ、デザイナからのみ実行が可能です。サービスとして登録されているスクリプトはサービスと呼ばれ、トリガーやScriptRunner、外部システムからも実行が可能となります。サービスとして登録されたスクリプトの登録を解除することもできます。

サービスとして登録する単位

サービスとして登録する単位は、プロジェクト単位となります。

公開名

プロジェクトをサービスとして登録すると、DataSpiderServerで外部から呼び出すための一意な公開名をプロジェクトに割り振ります。

デプロイ

プロジェクトをサービスとして登録する際には、プロジェクトに含まれるスクリプトをJavaのクラスとしてコンパイルし、JARファイルとしてモジュール化します。
モジュール化されたJARファイルは、トリガーやScriptRunner、外部システムから呼び出せる領域にデプロイされます。

サービス登録の設定手順

[ファイル]メニューから、[プロジェクトをサービスとして登録]を選択します。

サービスの登録画面が開きます。
[サービス名]を確認し、[次へ]ボタンを押下します。

サービス名のデフォルト値は、「<ユーザ名>@<プロジェクト名>」です。

サービス内容の比較が表示されます。
内容を確認し、[完了]ボタンを押下します。

サービスの登録ダイアログが表示されます。[OK]ボタンを押下します。

以上でプロジェクトがサービスとして登録されました。

トリガー

トリガーとは、ある処理のタイミングが引き金(トリガー)になり、サービスを実行する機能です。
DataSpider Servistaでは、さまざまなタイミングに応じて起動される、複数のトリガーが提供されています。

トリガーの種類

トリガー名	説明	備考
スケジュールトリガー	日・週・月・年・インターバルといったスケジュール単位の設定によって発火します。
ファイルトリガー	監視対象のファイルの新規作成・更新・削除を検知し、発火します。
HTTPトリガー	特定のURLへのアクセスを検知し、発火します。
DBトリガー	監視対象のテーブルの挿入・更新・削除を検知し、発火します。
FTPトリガー	DataSpiderServer上で動作するFTPサーバにアップロードされたファイルを検知し、発火します。
Webサービストリガー	特定のWebサービスへのアクセスを検知し、発火します。
Azure Service Busトリガー	Microsoft AzureにホストされたサービスからMicrosoft Azure Service Bus経由で送信されたメッセージを検知し、発火します。
SAPトリガー	監視対象のメッセージを検知し、発火します。
SAP BCトリガー	SAP Business Connectorで指定したURLへのアクセスを検知し、発火します。

トリガーの設定手順

ここでは、ファイルトリガーを使用し、「/data/inputdata.csv」ファイルが更新されたタイミングでサービスを実行するように変更します。

Studioから、「マイトリガー」をダブルクリックします。

マイトリガーが開きます。[マイトリガーのタスク]から、[新しいファイルトリガーを作成する]を押下します。

ファイルトリガー画面が開きます。
[トリガー名]に、「CSVファイルの書き込み処理」と入力します。
[監視イベント]に、「ファイルのタイムスタンプ更新時」を選択します。
[監視ファイル]に、「/data/inputdata.csv」と入力します。

[参照]ボタンでファイルチューザを起動し、ファイルを選択することもできます。

入力後、[次へ]ボタンを押下します。

実行内容の設定が表示されます。
[サービス]に「root@プロジェクト」、[スクリプト]に「スクリプト」が選択されていることを確認し、[次へ]ボタンを押下します。

実行オプションの設定が表示されます。
[XMLログ]にチェックが入っていて、ログレベルに「INFO」が選択されていることを確認し、[完了]ボタンを押下します。

ログレベルの詳細については、「ログレベル」を参照してください。

トリガー有効の確認ダイアログが表示されます。
トリガー作成完了と同時に有効化するため、[はい]を押下します。

[いいえ]を選択した場合でも、後でマイトリガーにて有効化することができます。

トリガーが発火し、正常にスクリプトが起動することを確認します。
エクスプローラから、「/data/inputdata.csv」ファイルを開き、以下のように修正保存して閉じます。

保存後、トリガーが発火されるまで待ちます。(ファイルトリガーの監視間隔は10秒)
トリガーが発火し、スクリプトの実行が終了した場合は、マイトリガーの[最終実行日時]および[最終実行結果]に日時と結果が表示されます。

エクスプローラから、「/data/outputdata.csv」ファイルを開き、書き込んだデータの内容を確認します。

「/data/inputdata.csv」が修正保存されたタイミングでサービスが起動され、「/data/outputdata.csv」に書き込まれたことが確認できました。

各種トリガーの設定の詳細については、「トリガー」を参照してください。

トリガーの作成方法の詳細については、「マイトリガー」を参照してください。