サービスの開発

本ページでは、DataSpider Servistaでサービスを実際に開発するにあたって必要となる、実践的な概念や機能について記述します。
本ページの記述は、前項「サービスの基礎知識」を読了し、サービスの基本的な概念やスクリプトの作成方法について理解していることを前提としています。

事前準備

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

開発標準の設定

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

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

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

開発および本番環境

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

ファイルの保管場所

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

命名規約

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

スクリプトのデザイン

その他

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

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

チーム開発

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

リポジトリ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を使用する・しない場合の動作は以下の通りです。

チーム開発機能

チーム開発機能とは、複数人によるサービスの開発をスムーズに行うことができるように用意された拡張機能群です。
統合開発環境(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では、スクリプト内の処理をより柔軟に記述するために、多様な補助系のコンポーネントを用意しています。
ここでは、その中でも使用頻度が高いコンポーネントを説明します。

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

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

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

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

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

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を使用し、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」を参照してください。

Multi-Stream Converter (結合・集計・ソート)

結合処理・集計処理・ソート処理は、Mapperとは別に、専用のコンポーネントが用意されています。

テーブルモデル型に特化したこれらのコンポーネントは、Multi-Stream Converter(マルチストリームコンバータ)という変換処理に特化した高速エンジン上で動作し、大容量データを扱うことに長けています。特にマルチコアCPU上では、リソースを有効に活用して並列で処理し、(従来のMapperと比較して)高速かつ省メモリで動作します。
Multi-Stream Converterの特性は、並列処理をサポートするコンポーネントとの組み合わせにおいて、最大の効果を発揮します。
また、処理ごとに専用のUIが用意され、直感的に操作・設定が可能になっています。

それ以外には、以下の特徴があります。 これらの特徴をよく理解し、適切に使用することで、ビッグデータやIoTなどで使われる大容量データに強いスクリプトを開発できます。

また、状況に応じて、Mapperを使用することも考えられます。以下に、Mapperの同等処理との使い分けをまとめました。

コンポーネント名 Mapperで相当する処理 Mapperを選択するケース
結合処理
  • 1回の処理で三つ以上のデータを結合したい
  • XML型のコンポーネントで結合したい
  • 小さいデータの入出力マッピングを専用のGUIでグラフィカルに定義したい
集計処理
  • XML型のコンポーネントで集計したい
  • Mapperロジックを組み合わせて集計したい
ソート処理
  • XML型のコンポーネントでソートしたい
  • Mapperロジックを組み合わせてソートしたい
  • 文字列順で大文字/小文字の優先順位を指定してソートしたい

グローバルスキーマの活用

グローバルスキーマとは、任意のプロジェクト・スクリプトに含まれるコンポーネントの入出力スキーマを登録し、ドキュメントMapperの入出力スキーマから参照できる機能です。

開発標準を設定し、処理ごとにスクリプトを分割する場合、スクリプト間の結果データの受け渡しにスクリプト入出力変数を使用します。XML型のスクリプト入出力変数や、主にXML型のアダプタでは、Mapperのスキーマを手動で設定する必要があります。
ここで、複数のMapperに同じ構造のスキーマが設定されている場合、入出力データの構造の変更が行われた際に、通常のスキーマ設定では1つ1つ手で設定しなおす必要があります。
また、変更対象の絞り込みのために、どのMapperでどういったスキーマが使われているのか、といった情報を仕様書などで管理しておく必要もあるでしょう。

このような場合、対象のスキーマをグローバルスキーマに登録し、複数のドキュメントMapperから参照することで、通常のスキーマ設定よりも容易に設定できます。構造の変更が行われる際には、登録元のグローバルスキーマを変更して、それを参照するスキーマに一括で反映するといったように、変更の手間も大きく減らすことができます。
また、グローバルスキーマがどういった構造で、どのMapperで使用されているか、といった情報をコントロールパネルの「グローバルスキーマの設定」で一元管理できます。

まとめると、グローバルスキーマの利点は以下の通りです。 グローバルスキーマを活用して、変更に強いスクリプト開発を行うことをお勧めします。

グローバルスキーマは、ドキュメントMapperでのみ使用できます。
グローバルスキーマの概要については、「グローバルスキーマ」も参照してください。

以下で、グローバルスキーマの登録・参照・更新・参照の解除の方法について説明します。

グローバルスキーマの登録

グローバルスキーマは、以下の画面から登録することができます。

スクリプトキャンバスからの登録手順

スクリプトキャンバスでは、特定のコンポーネントからグローバルスキーマを登録することができます。
詳細については、「スクリプトキャンバスからグローバルスキーマを登録できるコンポーネントについて」を参照してください。
Mapperのスキーマは、スクリプトキャンバスからの登録はできません。Mapperエディタから登録してください。

ここでは、CSVファイル読み取り処理を例に説明します。

スクリプトキャンバスにCSVファイル読み取り処理を配置し、[列一覧]を設定します。



配置したCSVファイル読み取り処理の右クリックメニューから[グローバルスキーマ]-[出力スキーマを登録]を選択します。



任意のグローバルスキーマ名を入力し、[次へ]ボタンを押下します。
グローバルスキーマは、グローバルスキーマ名によって参照されます。 グローバルスキーマ名には、DataSpiderServer上で一意な名前を付けてください。



登録元スキーマを確認し、[完了]ボタンを押下します。
新規登録の場合、[登録先グローバルスキーマ]は存在しないため、「(新規登録)」と表示されます。



グローバルスキーマが登録されました。このとき、登録したグローバルスキーマ名を内部プロパティ値として保持するため、CSVファイル読み取り処理に更新アイコンが表示されます。


登録されたグローバルスキーマはコントロールパネルの「グローバルスキーマの設定」で確認することができます。

Mapperエディタからの登録手順

Mapperエディタでは、編集可能な入出力スキーマからグローバルスキーマを登録することができます。
ここでは、入力スキーマを例に説明します。
ドキュメントMapperからのみ登録が可能です。変数MapperおよびマージMapperから登録することはできません。

入力スキーマの「入力データ」直下のノードの右クリックメニューから、[グローバルスキーマ]-[登録]を選択します。



任意のグローバルスキーマ名を入力し、[次へ]ボタンを押下します。
グローバルスキーマは、グローバルスキーマ名によって参照されます。 グローバルスキーマ名には、DataSpiderServer上で一意な名前を付けてください。



登録元スキーマを確認し、[完了]ボタンを押下します。
新規登録の場合、[登録先グローバルスキーマ]は存在しないため、「(新規登録)」と表示されます。



グローバルスキーマが登録されました。このとき、登録したグローバルスキーマ名をプロパティ値として保持するため、ドキュメントMapperに更新アイコンが表示されます。



また、Mapperエディタの「入力データ」直下のノードにはグローバルスキーマのアイコンが表示され、「<ノード名>(<グローバルスキーマ名>)」と表示されるようになります。



これは、グローバルスキーマを参照していることを示します。
Mapperエディタからグローバルスキーマを登録した場合、同時にそのグローバルスキーマを参照している状態になります。
登録されたグローバルスキーマはコントロールパネルの「グローバルスキーマの設定」で確認することができます。

グローバルスキーマの参照

グローバルスキーマは、Mapperエディタから参照することができます。

Mapperエディタからの参照手順

Mapperエディタでは、編集可能な入出力スキーマからグローバルスキーマを参照することができます。
ここでは、入力スキーマを例に説明します。
ドキュメントMapperからのみ参照が可能です。変数MapperおよびマージMapperから参照することはできません。

入力スキーマの「入力データ」直下のノードの右クリックメニューから、[グローバルスキーマ]-[読み込み]を選択します。



任意のグローバルスキーマを選択し、[完了]ボタンを押下します。



グローバルスキーマが読み込まれます。このとき、Mapperエディタの「入力データ」直下のノードにはグローバルスキーマのアイコンが表示され、「<ノード名>(<グローバルスキーマ名>)」と表示されるようになります。



これは、グローバルスキーマを参照していることを示します。
「スキーマの選択」画面で[グローバルスキーマと同期する]のチェックを外してから[完了]ボタンを押下すると、スキーマだけを読み込み、グローバルスキーマを参照しない状態となります。

グローバルスキーマの更新

グローバルスキーマは、以下の画面から更新することができます。

スクリプトキャンバスからの更新手順

スクリプトキャンバスでは、グローバルスキーマの登録と同じメニューからグローバルスキーマを更新することができます。
ここでは、「スクリプトキャンバスからの登録手順」でグローバルスキーマを登録したCSVファイル読み取り処理を例に説明します。

CSVファイル読み取り処理のプロパティを開き、[列一覧]を変更します。



CSVファイル読み取り処理の右クリックメニューから[グローバルスキーマ]-[出力スキーマを登録]を選択します。



[グローバルスキーマ名]には前回登録したグローバルスキーマ名が表示されます。そのまま[次へ]ボタンを押下します。



登録元スキーマと登録先グローバルスキーマとの差分を確認し、問題なければ[次へ]ボタンを押下します。



グローバルスキーマを参照しているコンポーネントの一覧が表示されます。一覧を確認し、すべて問題なければ[実行]ボタンを押下します。
一覧はサーバ上のプロジェクトにもとづいて作成します。チーム開発機能が有効の場合、対象となるプロジェクトはあらかじめサーバにコミットしておく必要があります。



すべてのグローバルスキーマを参照しているコンポーネントのスキーマが更新され、プロジェクトが保存されます。
チーム開発機能が有効の場合、プロジェクトはローカル保存されます。サーバへのコミットは行われません。
多数の参照コンポーネントを更新する場合、クライアントマシンの性能が求められます。詳細については、「参照コンポーネントの更新に求められる性能について」を参照してください。



更新結果を確認し、[完了]ボタンを押下するとグローバルスキーマが更新されます。
このとき、更新対象のプロジェクトをデザイナで開いている場合、そのプロジェクトに含まれるすべてのスクリプトは閉じられます。

Mapperエディタからの更新手順

スクリプトキャンバスでは、グローバルスキーマの登録と同じメニューからグローバルスキーマを更新することができます。
ここでは、「Mapperエディタからの登録手順」でグローバルスキーマを登録した入力スキーマを例に説明します。

入力スキーマを編集してから、入力スキーマの「入力データ」直下のノードの右クリックメニューから、[グローバルスキーマ]-[登録]を選択します。



[グローバルスキーマ名]には前回登録したグローバルスキーマ名が表示されます。そのまま[次へ]ボタンを押下します。



登録元スキーマと登録先グローバルスキーマとの差分を確認し、問題なければ[次へ]ボタンを押下します。



グローバルスキーマを参照しているコンポーネントが存在しない場合、そのことを示すダイアログが表示されます。[OK]ボタンを押下します。
参照コンポーネントが存在する場合、参照コンポーネントのスキーマを更新します。その手順については、「スクリプトキャンバスからの更新手順」と同様です。



その後、[完了]ボタンを押下するとグローバルスキーマが更新されます。

グローバルスキーマの参照の解除

グローバルスキーマは、スキーマの構造を保持したまま参照を解除することができます。
ここでは、入力スキーマを例に説明します。

入力スキーマの「入力データ」直下のノードの右クリックメニューから、[グローバルスキーマ]-[参照の解除]を選択します。



グローバルスキーマの参照が解除されます。



参照が解除されると、グローバルスキーマを参照していない状態となりますが、スキーマの構造はそのまま維持されます。

繰り返し処理のログ設定

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

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

アクセス履歴の記録

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

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

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

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

サービス登録

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

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

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

公開名

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

デプロイ

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

サービス登録の設定手順

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



サービスの登録画面が開きます。
[サービス名]を確認し、[次へ]ボタンを押下します。
サービス名のデフォルト値は、「<ユーザ名>@<プロジェクト名>」です。



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



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


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

トリガー

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

トリガーの種類

トリガー名 説明 備考
スケジュールトリガー 日・週・月・年・インターバルといったスケジュール単位の設定によって発火します。  
HULFT Scriptトリガー HULFTの転送履歴を検知し、条件に一致した場合に発火します。  

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

ScriptRunner

ScriptRunnerとは、Windowsタスクスケジューラや運用監視ツールなどの外部アプリケーションからサービスを実行するための機能です。
設定ファイルを引数とし、実行ファイルを起動することでサービスが実行されます。

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

ScriptRunnerProxy

ScriptRunnerProxyとは、Javaプログラムからサービスを実行するための機能です。
Javaプログラムでアクセスするための専用のJava APIが公開されています。

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

仕様書の生成

スクリプトの内容をHTML形式で仕様書として出力することができます。
処理内容をドキュメント化することで、サービス開発の成果物や引き継ぎ資料、運用時のマニュアルなどに使用することができます。
仕様書はスクリプト単位、プロジェクト単位のどちらでも出力することが可能です。
詳細については、「デザイナ」を参照してください。