サービスの開発

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

事前準備

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

開発標準の設定

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

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

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

開発および本番環境

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

ファイルの保管場所

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

命名規約

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

スクリプトのデザイン

その他

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

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

大容量データの対応

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

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

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

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

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

開発支援機能

DataSpider Cloudでは、サービスの開発を円滑に進めることができるように、さまざまな支援機能が用意されています。
ここでは、その中で主な機能について説明します。 本項は、「サービスの基礎知識」ページの「スクリプトの作成と実行」で作成したスクリプトをもとに説明します。

メモ

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

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



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


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

ログレベル

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

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

  ログレベル
↑
高

低
↓		 NOTICE
INFO
FINFO
FINEST
DEBUG

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



オプション設定画面が開きます。
ここでは、もっとも詳細な情報が取得できる「DEBUG」に変更し、[了解]ボタンを押下します。
[XMLログ]の[有効にする]チェックを外した場合は、ログは出力されません。



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

デバッグ実行

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

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



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


ブレークポイントで一時停止した状態では、処理済みのプロセスフローは赤色で表示されます。
デバッグ実行の場合、通常のテスト実行と以下の動作が異なります。 ツールバーから、[スクリプトのデバッグ実行の開始/再開]ボタンを押下すると、処理が再開されます。

ブレークポイント

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

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



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

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

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

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

グリッド

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

32*32 16*16 8*8

アイコンの整列

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

変数

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

スクリプト変数

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

環境変数

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

コンポーネント変数

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

トリガー変数

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

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

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

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

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

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

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

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

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



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



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



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

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



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

例外監視

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

例外監視の設定手順

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



例外を監視したいコンポーネントを囲むように、「例外監視」コンポーネントを配置してフローを引きます。
ここでは、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ログの出力容量が大きくなります。
ファイル肥大化によってディスク容量が圧迫されると、サーバの動作が不安定になるおそれがあるため、開発段階から運用を想定した対処が必要になってきます。
対応策としては、実行時の「ログレベル」変更といったこともありますが、繰り返し処理のログ設定を行えばスクリプト全体のログレベルを変えることなく、繰り返し処理内のコンポーネントのログレベルだけを変更することが可能です。
低いログレベルを設定したり、XMLログを出力しない設定にしたりした場合、ファイルの容量が抑えられるほかに、副次的な効果としてログ出力のコストが軽減されることによるパフォーマンスの向上も考えられます。

アクセス履歴の記録

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

アクセスログの使いどころとしては、以下のようなことが考えられます。 そのため、開発・運用のフェーズによらず、必要に応じて機能を有効にすることで、有益になりうる情報を記録しておくことができます。
なお、ログファイルは日次でローテーションされ、本日を除く10日分が保持されて、それより過去分は自動で削除されます。必要に応じてバックアップを取得してください。

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

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

サービス登録

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

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

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

公開名

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

デプロイ

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

サービス登録の設定手順

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



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



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



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


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

トリガー

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

トリガーの種類

トリガー名 説明 備考
スケジュールトリガー 日・週・月・年・インターバルといったスケジュール単位の設定によって発火します。  
ファイルトリガー 監視対象のファイルの新規作成・更新・削除を検知し、発火します。  
HTTPトリガー 特定のURLへのアクセスを検知し、発火します。  
DBトリガー 監視対象のテーブルの挿入・更新・削除を検知し、発火します。  
Webサービストリガー 特定のWebサービスへのアクセスを検知し、発火します。  
Amazon Kinesisトリガー 監視対象のAmazon Kinesisストリームへのデータの送信を検知し、発火します。  
SAPトリガー 監視対象のメッセージを検知し、発火します。  
HULFT Scriptトリガー HULFTの転送履歴を検知し、条件に一致した場合に発火します。  

トリガーの設定手順

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

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



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



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

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



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



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



トリガー有効の確認ダイアログが表示されます。
トリガー作成完了と同時に有効化するため、[はい]を押下します。
[いいえ]を選択した場合でも、あとでマイトリガーにて有効化することができます。



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



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



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



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

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

仕様書の生成

スクリプトの内容をHTML形式で仕様書として出力することができます。
処理内容をドキュメント化することで、サービス開発の成果物や引き継ぎ資料、運用時のマニュアルなどに使用することができます。

また、プロジェクト・スクリプトのコンポーネントアイコン数やMapperのロジックアイコン数などの統計情報を出力することで、プロジェクト・スクリプトの規模を把握することが可能です。
これにより、作成したスクリプトが開発標準に従っているかを確認したり、開発工数の見積りの指標として統計の数値を使用したりといったことができます。

仕様書はスクリプト単位、プロジェクト単位のどちらでも出力することができます。
詳細については、「デザイナ」を参照してください。

バージョン比較レポートの出力

バージョン比較レポートとは、スクリプトの二つのバージョンを比較した差分を確認することのできるHTML形式のレポートです。

スクリプトを長期間継続して開発をしていると、過去のある時点から現在までどのような修正を行ったのかの情報が必要になることがあります。
また、本番環境にリリースした後にスクリプトの修正を行う場合、不要な修正を行っていないかを示すために、リリース時からの修正範囲が記述されたドキュメントが求められることもあります。
そのような場合に、手動でスクリプトを過去のバージョンに戻し、比較して調査を行うのは非常に手間がかかる煩雑な作業です。

バージョン比較レポートを使用すれば、そのような手動の比較調査は必要ありません。
自動的に修正前のバージョンと修正後のバージョンの設定内容を比較し、修正した箇所とその内容を見やすい形で出力するため、すぐに差分情報を把握することができます。
また、修正箇所をドキュメント化してエビデンスとして残すことができるため、修正の影響範囲をドキュメントで管理することが可能です。

バージョン比較レポートは、デザイナのスクリプトメニューからスクリプト単位で生成することができます。
プロジェクト単位で出力することはできません。

生成方法の詳細については、「スクリプトメニュー」を参照してください。
バージョン比較レポートの内容については、「バージョン比較レポートの内容」を参照してください。