メインコンテンツまでスキップ

概要

一括伝送は、機関と規定したプロトコル規約に従って、オンライン電文をやり取りしながら、ファイルを送受信するインターフェースである。 代表的なプロトコルには、韓国で多く使用する、金融決済院(CMS)、銀行連合会プロトコルがある。

処理プロセス

一括伝送は、ファイル送信と受信に区分される。

送信

一括伝送の送信処理プロセス

  1. 業務システムで、送信ファイルを送信ディレクトリに保存
  2. ファイルを検知し、て作業ディレクトリにファイルを移動
  3. 送信ファイルを、機関と規定した単位に分離してDBに保存
  4. 機関と規定したプロトコルに応じて、ファイルを送信
  5. バックアップディレクトリに、送信ファイルを移動

受信

一括伝送の受信処理プロセス

  1. 機関から電文受信を受け取って、共通ヘッダー情報をパーシングし、機関と規定したプロトコルを呼び出す
  2. プロトコルによってファイル受信完了後、ファイル作成イベントを発生
  3. 受信したファイルを保存したデータをDBから読み込んで、ファイルを作成
  4. FTPサーバーが存在する場合、FTPプロトコルを利用して、業務システムにファイルを送信

一括伝送ファイル

一括伝送ファイルは、一括伝送でオンライン電文を送受信して作成された最終成果物である。

ファイル伝送データの構造

一括伝送は、伝送データを順序に作成して送受信する。伝送データは、共通ヘッダーと業務データで構成され、業務データは、ファイルを複数のピースに分けたレコードで構成される。

☑ レコード

レコードは、一括伝送ファイルの最小単位で、実際に伝送するファイルデータを含む。 複数のレコードを伝送データ(シークエンス)に入れて、一度に伝送する。

☑ シークエンス

シークエンスは、1つのオンライン電文(伝送データ)である。 共通ヘッダーと業務データで構成され、業務データは、1つの電文内に入れるべき一連のレコードで構成される。

☑ ブロック

ブロックは、シークエンスの集合であり、一般的に100個のシークエンスの集合により、1つのブロックとなる。 シークエンスは伝送後、応答を受けずに連続的に次のシークエンスを伝送する。その後、1ブロックの伝送完了後、データ損失発生有無を確認するために欠番処理を行う。 このように、ブロックという単位は、特定単位で伝送されたデータのうち、失われたデータがあるか否かを確認するために使用される。

ファイル伝送データの構造

ファイルのネーミングルール

ファイル送信は、送信ファイルが送信ディレクトリに保存された時に開始される。 この時、送信対象機関とプロトコルを見つけ出す必要があるが、そのために、定められたネーミングルールでファイルを保存する必要がある。 同様に、機関からファイルを受信して完成したファイルを、業務システムに転送する際にも、送信機関の情報を認識する必要があるが、そのためにも、定められたネーミングルールでファイルを作成しなければならない。

ファイル名は「.」区切り文字で分離して、ファイルID、送受信ファイル名、機関コード、業務コード、基準日付で構成されている。 このうち、送受信ファイル名がファイルIDと同じ場合、省略できる。 基準日付も、ファイル名に含まれない場合は、システム日付を基準日付として使用することができる。

ファイルのネーミングルール

  • ファイルID : Batch Management > File Transmission Informationに登録した情報を識別するための「一括伝送ファイルID」を入力する。
  • 送受信ファイル名 : オンライン電文上に保存され、伝達される情報で、機関と規定したファイル名を入力する。 ファイルIDと同じであれば省略できる。 また、下記のように、スクリプトを利用できる。
    // 形式としてFILE_IDがEA11であり、日付が03月20日ならば送受信ファイル名 'EA110320'となる。
    ${FILE_ID:4}+${MMdd:4}
  • Institution Code : 一括伝送ファイルを伝送する機関の機関コードを入力する。
  • Business Code : 一括伝送ファイルを伝送する機関の業務コードを入力する。
  • 基準日付 : 一括伝送プロトコルに従って、オンライン電文上に保存して伝達される情報で、ファイルを作成したデータの基準日付を意味する。 省略すると、システム日付が設定される。
info

ファイル名について、上記のネーミングルールに従うことができない場合、ユーザープログラムでカスタマイズすることができる。 詳細な設定は、一括伝送ファイル名のカスタマイズを参照する。

ファイル管理

一括伝送は、ディレクトリを区分してファイルを管理する構造を持っている。ディレクトリの位置はSetting > System Parameter Settingで設定する。

ファイル管理

☑ 送信ディレクトリ

  • 送信ディレクトリは、機関にファイルを送信するためにファイルを保存するディレクトリである。 送信ディレクトリにファイルを保存すると、自動的にファイルが読み込まれて、送信作業ディレクトリに移される。
  • システムパラメータはSCAN_DIRECTORY_NAMEである。

☑ 作業ディレクトリ

  • 作業ディレクトリは臨時にファイルを保管するディレクトリで、ファイルの基本検証およびFile to DB作業を行う。 作業が完了すると、当該ファイルはバックアップディレクトリに移される。
  • システムパラメータはWORK_DIRECTORY_NAMEである。
    info

    作業ディレクトリは、システムパラメータのWORK_DIRECTORY_NAMEと相手機関のバッチインスタンスIDでディレクトリを作成する。 例えば、システムパラメータのWORK_DIRECTORY_NAME値が「work」であり、現在のバッチインスタンスのIDが「instance_BAT_01」であれば、作業ディレクトリは「work/instanceBAT01」となる。

☑ 受信ディレクトリ

  • 受信ディレクトリは、機関から受信したデータをDB to Fileで作成し、ファイルを保存するディレクトリである。
  • 作成したファイルはFTP、またはEAIで業務システムに転送できる。
  • システムパラメータはRECEIVE_DIRECTORY_NAMEである。

☑ バックアップディレクトリ

  • バックアップディレクトリは、作業ディレクトリで作業が完了したファイルを保管するためのバックアップディレクトリである。
  • バックアップディレクトリは、送信ディレクトリ(SCAN_DIRECTORY_NAME)の上位ディレクトの下に、「backup」として自動生成される。
    info

    一括伝送は、送信ファイルに対するバックアップ管理機能を提供し、ファイルを消失した場合でも、一括伝送処理を保証する。 バックアップディレクトリの下位に処理日付である「YYYYMMDD」ディレクトリを作成し、当該送信ファイルを「オリジナルファイル名+YYYYMMDDHHmmssSSS」名で保存する。

一括伝送プロトコル

一括伝送プロトコル(以下プロトコル)は、機関と規定した方式で定めたサイズでファイルを分割して、オンラインでファイルを送受信する規約である。 プロトコルを利用して、大量の資料を迅速かつ正確に処理できるように、可能な限り手作業処理を排除し、処理手順を自動化するために使用する。

一般的に使用されるプロトコル手順は、下記のとおりである。

  1. ファイル伝送を開始する前に開始電文を送受信する。
  2. 伝送するファイルに対する情報を送受信する。
  3. ファイルを定められたサイズに分割して、定められたブロック(一般的に100回)分だけ送信する。
  4. データの流失が発生したかを確認するために、ブロック単位で欠番を確認する。
  5. 欠番がない場合には3番から再実行し、欠番が存在する場合には欠番になったデータを再送信する。
  6. 上記のプロセスで、すべてのファイルデータを送信した後、業務終了電文を送信する。

各機関は、基本的には上記の手順に従うが、必要に応じてプロトコルを修正して使用する。

BXIは、下記のように、韓国で汎用的に使用されているプロトコルに対応しており、プロトコルをカスタマイズできる機能を提供する。 これ以外に新しい方式のプロトコルが必要な場合は、パッチで提供する。

プロトコル説明
CMS金融決済院のCMS(Cash Management Service)ファイルを送受信する目的で使用するプロトコルである。
DPT後払い交通機関で使用するプロトコルである。
EDIVAN社でカード内訳をEDI(Electronic data interchange)方式でカード会社に送受信する目的で使用するプロトコルである。
FPD海外のデビットカードで使用するプロトコルである。
KCAカード協会で使用するプロトコルである。欠番処理をしないことが特徴である。
KFB銀行連合会の金融取引情報ファイルを送受信する目的で使用するプロトコルである。
POSPOSデータで使用するプロトコルである。
SKCSK C\&Cで使用するプロトコルである。

プロトコルに関する詳しい説明はプロトコルを参照する。

バッチインスタンス

構造

BXIバッチインスタンスは、機関と規定した一括伝送プロトコルに従ってファイルを送受信するコンポーネント、と内部システムとの間でファイルを送受信するコンポーネントで構成される。 通信プロトコルは、TCP/IPに基づいてプロトコル処理に対応する。

バッチインスタンス - 基本構造

  • Internal Invoker : ユーザーが送信ファイルを指定された伝送ディレクトリに保存すると、ファイルを検知してファイルの情報に従って登録されたプロトコルを呼び出す。
  • External Invoker : 機関で電文を受信すると、電文の共通ヘッダー情報を分析し、共通ヘッダーからファイル情報を取得して登録されているプロトコルを呼び出す。
  • 一括伝送プロトコル処理 : 機関と規定したプロトコルに従って電文を処理する。
  • File Manager : 受信ファイルの作成および送信ファイルのDB化作業を行う。

一括伝送プロトコルコンポーネント間のフローは、下記のとおりである。

バッチインスタンス - 基本構造

バッチ分配インスタンス

一括伝送は、処理するファイルが多くない場合は、1つのバッチインスタンスで十分に処理できる。 1つのバッチインスタンスのみを実行して処理する構成の場合、ファイルの転送は下記のとおりである。

ファイル転送 - 単一バッチインスタンス

ただし、一括伝送で処理するファイルが多く、1つのバッチインスタンスで円滑に処理できない場合は、機関別に分けて複数のバッチインスタンスを実行して処理する。 この際、送信ファイルを保存する送信ディレクトリを、複数のバッチインスタンスが同時に処理するため、問題が発生する。 この問題を解決するために、複数のバッチインスタンスを実行する場合、伝送ファイルを分配するための、Batch Divider Instanceを追加構成する必要がある。

バッチ分配インスタンスを追加構成して処理する場合、ファイルの転送は下記のとおりである。

ファイル転送 - マルチバッチインスタンス

バッチ分配インスタンスが当該作業を実行するためには、送信ディレクトリのScanを行うルーターを、バッチ分配インスタンスに割り当てなければならない。 Flow Management > Router Informationで、ルーターIDがfileScanRouterであるルーターの種類を「バッチ分配インスタンス」に変更する。