1.

DataSpider 開発時の規約
サンプル
◆本資料に関するご質問、お問い合わせは
dstnフォーラムにて投稿をお願いいたします。
◆本資料を無断で複写、複製することを禁じます。
開発手順
DataSpiderの開発開始までの手順
1.
2.
要件定義
処理フローの決定
処理フローの決定とプロジェクト､スクリプトレベルの分類の決定
処理のパーツ化
1.
2.
1.
2.
3.
4.
3.
共通処理､非共通処理
エラー処理
トランザクションの範囲
スクリプト親子関係の決定
命名規約､インターフェースの決定
ネーミング
1.
1.
2.
3.
4.
スクリプト､プロジェクト名
ディレクトリ､ファイル名
引数名､変数名
エラーコード
インターフェース
2.
1.
2.
引数による値引き継ぎ
ファイルによる値引き継ぎ
1. 要件定義と処理フロー
作成するアプリケーションの要件定義と処理フローを洗い出します
要件定義と処理フロー
1.
1.
要件定義

処理の内容洗い出し

処理を機能毎にグルーピング

処理の汎用性を判断･･･処理をパーツ化して再利用するか？

2.
全体の処理のフロー決定
処理の全体の流れ (フロー)の決定
処理のパーツ化の決定
エラー処理の方法の決定



2.
初期化処理､後処理など共通化できる処理か？
処理の要素
トランザクションの制御有無


トランザクションの制御が必要な場合は､トランザクションの範囲を１つのスクリプトにわけると再利用性が高くなる
リカバリ方法


リカバリが必要な場合は､リカバリポイントとなる位置で処理途中のデータをファイルに出力する､等
リカバリ実行用のデータを出力する処理を作成する
エラー処理


エラー処理の方式は？､共通化が可能か､を検討
2.分類の基準
機能から見た分類の単位
1.

DataSpiderの処理の分類の単位
プロジェクト
スクリプト



プロジェクトとは
プロジェクトには複数のスクリプトを登録できる


プロジェクトは複数ユーザで同時に編集し共有できる



関連する処理は１つのプロジェクトにいれる
１アプリケーションを複数の開発者で並行開発する場合､共有して開発する単位をプロジェクトとする
スクリプトとは
開発する処理の最小単位






スクリプトは複数のコンポーネント(部品)で構成される
ひとつの処理フローを1スクリプトにまとめる
処理の目的別にスクリプトを分けて作成する
部品の数が少ない場合やフローがシンプルな場合は1つのスクリプトで1つのアプリケーションを開発する
処理が複雑な場合は､処理の単位を分割してスクリプトを分けて開発し､最後に親スクリプトから複数の子
スクリプトを呼び出し処理を連結する
1つのスクリプトを複数のユーザで同時更新は不可


スクリプト単位でロックがかかる
2.分類の基準
アプリケーションから見た分類の単位
2.


１つの関連する処理

1スクリプトにまとめる(小規模の処理)

1プロジェクト(複数スクリプト)にまとめる(中～大規模の処理)
複数の関連する処理
プロジェクトを複数作成し､相互に連結する


共通する処理
共通処理は共通プロジェクトに登録して呼び出して利用する


初期化､後処理､エラーロジック
トランザクション

リカバリ処理

開発規模から見た分類の単位
2.


処理の規模が小さい場合(連携対象やロジックが少ない､開発者は1～2人)

1プロジェクト=1スクリプト=1アプリケーションからスタート

まずは1スクリプト内に実現したい処理を作成し､徐々に機能を追加しながら作成する

スクリプトの規模が大きくなってきたら､処理を分類する
処理の規模が大きい場合(連携対象が多く､ロジックが複雑､開発者は複数人)



開発開始前に､要件分析を行い開発する単位をプロジェクト､スクリプトに分類
1プロジェクト(複数スクリプト)=1アプリケーションとなるようネーミングや機能を決定
インターフェース規約を開発前に決定し､実装する
小規模開発のパターン

開発の単位


プロジェクト(1つ)=スクリプト(少数)=アプリケーション
適用する処理の規模･内容
連携対象の数が少ない
 ロジックの分岐が少ない
 処理の汎用性を考慮する必要がない


開発者の数


1人が1つのアプリケーションを担当する
実行の単位
プロジェクト→スクリプト
 スクリプト間の連携は不要


例
ETL的な処理･･･ DB→変換→DB→エラー処理
 Web連携･･･ DB→HTML→変数

中～大規模開発のパターン

開発の単位
プロジェクト(複数)=スクリプト(複数)=アプリケーション
 処理の規模･内容

 連携対象の数が多い
 ロジックの分岐が多い
 処理の汎用性(処理の共通化)を考慮する必要がある
 トランザクションが必要

開発者の数
 複数人が1つのアプリケーションを担当する

実行の単位
 プロジェクト→ディレクトリ→スクリプト
 スクリプト間の連携が必要

例:EDI的な処理

前処理(初期化)→入力データチェック→メイン処理
→エラー処理→後処理
SAMPLE
システム開発サンプル
システム名 : サンプル受発注システム
【システム概要】
メールに添付される発注データを元に､受発注システムにデータを登録､更新する｡
また､登録されたデータの参照･更新がWebから実行できる｡
【要件】
 メールで受信した注文情報が､受発注システムに自動登録される
 2種類の注文データ(固定長テキスト､XML)を扱うことができる
 在庫引き当てを行い､在庫がない場合は発注元にお知らせを通知する
 受注が確定したら､メールでお知らせする｡メールには請求書(Excel)を添付する｡
 営業部用に､注文情報を社内ポータルから注文日､顧客コードを条件として検索できるようにする｡営
業マンは売上げをWebで確認できる｡
 注文情報は1時間に1回自動的に受信される
 異常系処理
･注文データに異常値があった場合は発注元にメールでお知らせする
･処理が異常終了した場合は管理者にメールで通知する
SAMPLE
サンプルシステム処理の流れ
処理フロー

メールによる受発注システム
1.
メールで注文情報を受信をスケジュールでチェック

2.
3.
4.
添付データを取り出して､保存する

受信データから添付ファイルを取り出して､所定のディレクトリに保存する

2種類の形式(固定長､XMLファイルの名称)のデータが添付されている可能性がある｡

固定長､XML以外のファイルが受信された場合､添付がない場合は送信元にエラーを通知
添付データを元に受発注システム用RDBを更新する

更新時には在庫引き当てを行い､在庫がない場合は発注元にメールでお知らせを通知する

在庫がない場合は該当発注情報はロールバックする｡
受注が確定したら､メールでお知らせする｡

5.

チェックは30分に1回行う
受注データ更新処理に異常があった場合には管理者にエラーメール通知する
メールには請求書(Excel)を添付する｡
Webからの検索､更新システム


営業部用に､社内ポータルから注文情報や在庫状況を検索できる
製品マスタをWebから更新できる
SAMPLE
処理の分類
 メールによる受発注システム
 メール受信､添付ファイルの保存
などデータ抽出
 基幹DB更新時のデータチェック､マスタ参照､エラーチェック
 エラー処理
 DB更新
 Excel､固定長､XML
 Webからの参照､HTML生成
 WebからのDB更新
SAMPLE
開発単位での分類
 メールによる受発注システム
処理0 エラーメール通知(共通プロジェクト)
 処理1 メール受信､添付ファイルの保存(プロジェクト)

 添付ファイルの取り出し(スクリプト)
 取り出した添付ファイルの命名処理(スクリプト)

処理2 固定長､XML など入力データ判定とデータ抽出(プロジェクト)
 処理対象ファイルの判定(スクリプト)
 固定長抽出(スクリプト)
 XML抽出(スクリプト)

処理3 基幹DB更新時のデータチェック､マスタ参照(プロジェクト)
 マスターチェックとDB更新(スクリプト)

親処理処理1→処理2→処理3を実行する親処理
 処理2
Webからの参照､HTML生成(プロジェクト)
 処理3 WebからのDB更新 (プロジェクト)
SAMPLE
命名規約

プロジェクト名

固定値「 P 」＋シナリオ番号＋「 _ 」＋シナリオ名＋固定値「プロジェクト」
 ex)

スクリプト名

固定値「 S 」＋ 2桁連番＋処理名＋固定値「処理」


処理１の場合
P1_メール受信プロジェクト
2桁の連番は、処理の順序であることが望ましい。
ex) シナリオ３マスターキーチェックを行うスクリプトの場合
S01_マスターチェック処理
変数名

固定値「 V 」＋固定値「 _ 」＋ 2桁連番＋入出力＋処理名＋型
 入出力の規則：「入力用：ＩＮ」・「出力用：ＯＵＴ」・「入出力用：ＩＯ」
 型の規則：「文字列：STR」・「整数：NUM」・「XML：XML」・「日時：DT」・「真偽：BOO」
「バイナリ：BIN」
ex) シナリオ３マスターキーチェックで使用する変換後の製品コード用：入出力用
Ｖ_01_IO製品コード_VAL
SAMPLE
命名規約

トリガー名

固定値「 T 」＋トリガー種別＋シナリオ番号＋「 _ 」＋処理名＋固定値「トリ
ガー」


トリガー種別の規則：「ファイルトリガー：F」・「HTTPトリガー：H」
「スケジュールトリガー：S」・「Webサービストリガー：W」
※ 処理名はスクリプト名で定義した処理名と同じ名前にする事
ex) メール受信処理をスケジュールトリガーで実行する場合
TS1_メール受信トリガー
グローバルデータリソース名

SQL Server







Mail Server




グローバルデータリソース名
：受注DBサーバ
ホスト名
： sampleSRV
接続先DB名
： sampleDB
接続方式
： JDBC
ユーザID・パスワード：共通で、sample
コネクションプーリング
：デフォルト
グローバルデータリソース名
ホスト名
ユーザID・パスワード： sample
：メールサーバ
： mailSRV
固定長アダプタ

グローバルデータリソース名
：受注ファイル
SAMPLE
インターフェース規約

インターフェース
 共通処理
エラーメール通知のインターフェース
インターフェースはCSVによるファイル連携とする
エラー発生時には所定のフォーマットによるCSVファイルを作成し､共
通エラーメール通知処理を実行する
SAMPLE
開発環境

ホームディレクトリ
C:¥EAI（物理ディレクトリ）
 /EAI （論理ディレクトリ）


ドキュメント保管フォルダ
ファイルバックアップ用ディレクトリ
 メール受信添付ファイル保管ディレクトリ
 エラーデータ保管ディレクトリ
 DS環境移行時使用ディレクトリ
 取り込みファイルCSV保管ディレクトリ
 マスターテーブル保管ディレクトリ
 一時ファイル保管ディレクトリ

：
：
：
：
：
：
：
Backup
Download
Error
ImportExport
Maintenance¥Indata
Table
Tmp
 スクリプトの処理上、一時的に作成されるファイルは、該当トランザクションが終
了次第削除すること。但し、マスタテーブルファイルは対象外とする。
 以下記載のフォルダは、本システム環境ホームディレクトリ下に作成する
SAMPLE
規模(小)のサンプル

処理5 Web連携のサンプル
SAMPLE
規模(中)のサンプル

処理0:エラーメール通知(共通処理)
SAMPLE
規模(中)のサンプル

処理1: メールの受信と添付ファイルの保存
SAMPLE
規模(中)のサンプル

処理2:入力データ抽出とチェック
SAMPLE
規模(中)のサンプル

処理3:基幹DB更新時のデータチェック､マスタ参照
ご質問・お問い合わせは
Dstnフォーラムにて投稿をお願いします。
http://dstn.appresso.com

Download Report