4.3 インタラクティブ処理方式(ダイレクト・インターフェース) 4.3.1 処理方式概要 本処理方式は、NACCS センターサーバで利用者システム向けの電文が発生した際は即時に 電文を送り付ける処理方式となっている。そのため、メール処理方式(ゲートウェイコンピ ュータ)と比較し、処理要求電文に対する応答(レスポンス)が速いという特徴がある。ま た、NACCS センターサーバから送り付ける方式であるため、基本的に利用者システムは常時 稼働している必要があり、利用者システムに高い信頼性が要求される処理方式となっている。 さらに、利用者システム配下のパソコンではパッケージソフトが利用できない処理方式であ るため、NACCS センターサーバと EDI を行うため、利用者システム側に相応の作り込みが必 要となる。 なお、インタラクティブ処理方式(ダイレクト・インターフェース)では、利用者システ ム側にダイレクト・インターフェース用ホストを設置し、専用線接続の場合に限り利用可能 である。 NACCS におけるインタラクティブ処理方式(ダイレクト・インターフェース)の処理方式の 概要を、 図 4-3-1に示 す。 ① X.25 NACCS EDI電文 NACCS EDI電文 ダイレクト・ インターフェース 用ホスト DIサーバ ② NACCS EDI電文 NACCS EDI電文 利用者 システム 図 4-3-1 メイン処理部 X.25 NACCS センターサーバ インタラクティブ処理方式(ダイレクト・インターフェース)の処理方式概要 ① 利用者は、業務において必要とされる項目が格納された NACCS EDI 電文を作成し、利用 者システムから NACCS センターサーバに送信する。 ② メイン処理部では、送信された電文に基づき業務処理を行った後、その処理結果を利用 者システムに対して返信する。 4-3-1 4.3.2 利用者で守るべきインターフェース 利用者は、論理端末名ごとに、処理要求電文をセンターサーバに向け送信し、当該処理要求 電文に対応した全ての処理結果電文(処理結果通知電文または出力情報電文)を受信してから、 次の処理要求電文を送信する、というインタラクティブ処理方式のインターフェースを守らな ければならない。 すなわち、利用者は処理要求電文に入力情報特定番号を設定してセンターサーバへ送信し、 センターサーバからの当該処理要求電文に対応した全ての処理結果電文(処理結果通知電文ま たは出力情報電文)を受信した際、「入力情報特定番号が当該処理要求電文に設定した番号で あること」を確認し、次の処理要求電文を送信しなければならない。 (参考1)処理要求電文に対する処理結果電文の発生パターン(上記方法とする理由) 利用者システムからセンターサーバに処理要求電文を送信し、センターサーバでの業務処 理後、利用者システム向けに出力される処理結果電文の発生パターンを表 4-3-1に示す。全 ての発生パターンにおいて、処理結果通知電文または出力情報電文に処理要求電文に設定し た「入力情報特定番号」が持ち回りされる。 (「入力情報特定番号」の設定詳細は「表 3-5-2 入力情報特定番号、電文引継情報設定内容」 を参照。) 表 4-3-1 ー パ発 タ生 ン 1 処理結果電文 電文の種類 処理結果通知電文 処理結果通知電文 2 出力情報電文 3 処理要求電文に対する処理結果電文の発生パターン 出力情報電文 入力情報特定番号 電文種別 の持回りの有無 [R] ○ 備考 処理結果通知電文[R]の入力情報特定番号 で確認する ※1 出力情報電文[P]、[A]のEXC型電文は入 力情報特定番号を持ち回らない(一部の出 力情報電文は持ち回るものもある)ことか [C]or [C]は○ ら、処理結果通知電文[R]の入力情報特定 [P],[A] [P],[A]は△(※1) 番号で確認する 照会系業務は処理結果通知電文が出力され ないので、出力情報電文の入力情報特定番 [R]or[M] ○ 号で確認する [R] ○ (参考2)3.5.3「継続処理(索引引継情報)」との関係 継続処理対象業務を行う場合には、センターサーバから払い出された出力情報電文の「索 引引継情報」を利用者システムで次の処理要求電文にそのまま設定しなければならないため、 上記のインタラクティブ処理方式のインターフェースを守ることに加え、継続処理を実現す る仕組みも利用者システムで作り込む必要がある。 詳細は「3.5.3 継続処理(索引引継情報)」及び「付表 6-10 出力情報コード一覧」の継続処 理欄を参照。 なお、旧システムで継続処理の為、メールに適さない業務とされていた業務(旧 Air-NACCS EDI 仕様書 付録 10 に掲載されていた業務)については、本システムでは電文長拡大等によ り、継続処理を使用せずに業務処理を可能とすることで、メール処理方式にも適するように 業務仕様の見直しを行っている。 4-3-2 インタラクティブ処理方式(ダイレクト・インターフェース)のインターフェースのイメージを 図 4-3-2に示す。 ① 処理要求電文 * (* は入力情報特定番号) パターン1及び2 で確認する電文 業務処理が終了 ①の処理要求電文に対し、必 ずどちらかの電文がセンター サーバから出力されることか ら、どちらかの電文の入力情 報特定番号が処理要求電文と 同じであることを確認する。 ①' 処理結果通知電文 [R] * INQ型 or ①' 出力情報電文 [M]or[R] * パターン3で 確認する電文 以降、次の処理要求電文の送信が可能となる 次の処理要求電文 の送信が可能 ①の処理要求電文等により業 務によっては発生する場合が ある。(随時受信) ② 処理要求電文 ◇ (◇ は入力情報特定番号) ①'出力情報電文(画面用)[C] * ①'出力情報電文(帳票用)[P],[A] * ①'出力情報電文(帳票用)[P],[A] △ INQ型 INQ型 or EXZ型 EXC型 (△はスペース) 第三者の入力を契機に送信 されてくる処理結果電文は 当該インターフェースには 関係ない。(随時受信) 出力情報電文(帳票用)[P],[A] △ EXC型 ★ (△はスペース) 第三者の入力 を契機に出力 NACCS センターサーバ 利用者システム ※図中の「パターン1」~「パターン3」の各パターンは表 4-3-1を参照 図 4-3-2 インタラクティブ処理方式(ダイレクト・インターフェース)の インターフェースのイメージ 4-3-3 4.3.3 通信プロトコルの詳細 NACCS におけるインタラクティブ処理方式(ダイレクト・インターフェース)の通信プロト コルには、伝送制御手順として X.25(80 年版)を採用する。 4-3-4 4.3.4 電文構造 インタラクティブ処理方式(ダイレクト・インターフェース)では、NACCS EDI 電文、XML 形式電文が利用される。 以降に各形式の電文構造の概要を示す。 (1)NACCS EDI 電文の場合 NACCS EDI電文の概要(インタラクティブ処理方式(ダイレクト・インターフェース)) を図 4-3-3に示す。 NACCS EDI電文 入力(出力) 共通項目 業務個別項目 最大 500,000 バイト(注) (「3.電文方式と構造」参照) 図 4-3-3 NACCS EDI 電文の概要(インタラクティブ処理方式(ダイレクト・インターフェース)) (注)なお、他府省システムとの間で送受信する電文の最大長は、別冊「他府省システム編」 を参照のこと インタラクティブ処理方式(ダイレクト・インターフェース)利用者がNACCS EDI電文をNACCS センターサーバへ送信する際に作成する電文の形態を、図 4-3-4に示す。 NACCS EDI 電文 入力 (出力) 共通項目 … 業務個別項目 C L … R F 図 4-3-4 C L … R F C L … R F C L R F 電文の内容 (参考)上記の電文構造をワープロソフト、エディター等で見た場合、以下のようになる。 XXXXXXXXXXX.....XXX<CRLF> XXXX...XXX<CRLF> XXXX...XXX<CRLF> XXXX...XXX<CRLF> 入力(出力)共通項目 業務個別項目 ※「<CRLF>」については、エディター等により見え方が異なることがある。 4-3-5 NACCS EDI 電文 (2)XML 形式電文の場合 XML形式電文の概要(インタラクティブ処理方式(ダイレクト・インターフェース))を 図 4-3-5に示す。 XML形式電文 XML電文 最大 500,000 バイト (「3.電文方式と構造」参照) 図 4-3-5 XML 形式電文の概要(インタラクティブ処理方式(ダイレクト・インターフェース)) インタラクティブ処理方式(ダイレクト・インターフェース)利用者が XML 形式電文を NACCS センターサーバへ送信する際には、以下の形態で電文を作成すること。 ① 1000 バイトごとに改行すること。改行しない場合はエラーとなる。 ② XML 電文部については、一行ごとに<CRLF>が存在するものとする。 ③ XML 電文部の文字コードは EUC-JP とし、XML ヘッダーの encoding フィールドに EUC-JP を記載すること。 電文構造の詳細については、「付録 X-1」を参照すること。 <参考> XML 形式電文の電文構造をエディターで見た場合の一例を以下に示す。 <?xml version="1.0" encoding="EUC-JP" standalone="no" ?> - <RootElement> - <Header> - <DocumentType> <DocumentTypeCode>XXX</DocumentTypeCode> <DocumentTypeDescription>XX…XXX</DocumentTypeDescription> </DocumentType> - <DocumentIdentification> <MessageFunction> XX…XXX </MessageFunction> <MessageTransferSequenceNo>XX</MessageTransferSequenceNo> </DocumentIdentification> <SenderID> XX…XXX </SenderID> </Header> - <Body> ※XML 電文部 ・ 詳細は付録 X-1 参照 ・ ・ - <AdditionalInformation> <InformationType> XX…XXX </InformationType> </AdditionalInformation> </Body> </RootElement> 4-3-6 4.3.5 業務処理シーケンス (1)ダイレクト・インターフェースにおける業務処理シーケンス インタラクティブ処理方式(ダイレクト・インターフェース)における業務処理シーケン スを、図 4-3-6に示す。 図 4-3-6 電文処理シーケンス ① 利用者側ダイレクト・インターフェース用ホストは、NACCS 接続ルーター(ダイレクト・インタ ーフェース用)に発呼要求(CR)を出し、X.25 パケットレベル接続を行う。 ② X.25 パケットレベルの接続が正常に行われると、NACCS 接続ルーター(ダイレクト・インター フェース用)から利用者側ダイレクト・インターフェース用ホストに接続完了(CC)が通知され る。 ③ 利用者側ダイレクト・インターフェース用ホストはセンター側 DI サーバに X.25 で処理要求電 文を送信する。 ・ 処理要求電文のフォーマットは業務によって異なるので業務仕様書を参照すること。 ・ 処理要求電文の形式は、NACCS EDI 形式、XML 形式である。 ④ センター側 DI サーバは電文のチェックを行った後、メイン処理部に処理要求電文を送信する。 ⑤ メイン処理部は電文のチェックを行った後、業務処理を行う。 ⑥⑦ メイン処理部は処理結果電文(画面用)をセンター側 DI サーバに送信する。 (業務仕様によって、処理結果電文(画面用)が複数発生する場合がある。図 4-3-6は、電 文種別RとCの処理結果電文(画面用)が発生している場合を表している。) 4-3-7 ⑧⑨ センター側 DI サーバは利用者側ダイレクト・インターフェース用ホストに X.25 で処理結果 電文(画面用)を送信する。 ・ 処理結果電文(画面用)のフォーマットは業務によって異なるので業務仕様書を参照するこ と。 ・ 処理結果電文(画面用)の形式は、NACCS EDI 形式、XML 形式である。 ・ 1つの論理端末については①の処理要求電文に対する⑧の処理結果電文(画面用) 「電文種別 がRまたはM」が返ってきてから次の電文を送信することができる。そのため、利用者側ダ イレクト・インターフェース用ホストでは①処理要求電文に対する⑧処理結果電文(画面用) 「電文種別がRまたはM」が返ってきたことの確認処理が必要となる。これにより、1つの 論理端末では複数の電文を同時に送信できないため、センターに同時送信する場合は、論理 端末が複数必要となる。 ⑩ メイン処理部は処理結果電文(帳票用)をセンター側 DI サーバに送信する。 (業務仕様によって、処理結果電文(帳票用)が発生しない場合や複数発生する場合がある。 図 4-3-6は、帳票電文が1電文発生している場合を表している。) ⑪ センター側 DI サーバは利用者側ダイレクト・インターフェース用ホストに X.25 で処理結果電 文(帳票用)を送信する。 ・ 処理結果電文(帳票用)のフォーマットは業務によって異なるので業務仕様書を参照するこ と。 ・ 処理結果電文(帳票用)の形式は、NACCS EDI 形式、XML 形式である。 ⑫ 利用者側ダイレクト・インターフェース用ホストは処理結果電文(帳票用)を受信し、格納で きたら受信完了電文(?A2)を送信する。 ⑬ センター側 DI サーバは電文のチェックを行った後、メイン処理部に受信完了電文(?A2)を送信 する。 ⑭ 利用者側ダイレクト・インターフェース用ホストから NACCS 接続ルーター(ダイレクト・イン ターフェース用)に復旧要求(CQ)を出し、パケットレベルの終了を行う。 ⑮ X.25 パケットレベルの終了が正常に行われると、NACCS 接続ルーター(ダイレクト・インター フェース用)から利用者側ダイレクト・インターフェース用ホストに復旧確認(CF)が通知され る。 (注 1)処理結果電文(画面用)については、 「図 4-3-2 インタラクティブ処理方式(ダイレクト・ インターフェース)のインターフェースのイメージ」に示す通りのパターンがある。電文種別「R」 または[M]の場合のみ、処理要求電文との突き合わせを行う必要がある。 (注 2)⑧⑨⑪の利用者側ダイレクト・インターフェース用ホストへの到着順序は保証されない。 (注 3)EXC型電文、EXZ型電文は、第三者の業務処理を契機として発生するが、図 4-3-6の⑩~⑬ のみのシーケンスとなる。 4-3-8 (2) 交換ファイルに関係した処理シーケンス(図 4-3-7参照) ① 業務処理によって、メイン処理部内の交換ファイルに処理結果電文が格納されることが ある。 ② 交換ファイルに格納された処理結果電文は、「蓄積電文取り出し」業務(REQ)や「障害 電文取り出し」業務(SYG)を送信することで、取り出すことができる。即時型の処理結 果電文の場合には、交換ファイルに格納されたのと同時に、利用者システムに対して送 信される。 ③ 交換ファイルに格納された処理結果電文を利用者システムが正常に受信できた場合には、 受信後に「受信完了電文」(?A2)をセンターサーバに送信する。 ④ メイン処理部は利用者システムから受信完了電文を受け取った後、該当する処理結果電 文を交換ファイル内より削除して処理を終了する。但し、交換ファイルに、取り出す対 象となっている処理結果電文が複数格納されている場合には、メイン処理部が利用者シ ステムから受信完了電文を受け取り、該当する処理結果電文を交換ファイル内より削除 した後、次の処理結果電文を利用者システムに送信する。 利用者システム NACCSセ ンター サ ー バ DIサ ー バ 業務処理 メイン 処 理 部 ①交 換 ファイル に 処 理 結 果 電 文が 格 納 され る ことが あ る 処理要求電文 業務 処理結果電文 電文 ② 蓄 積 電 文 取り出 し業 務 や 障 害 電 文 取り出 し業 務に よる 処 理 要 求 電 文を 送 信す る 電文 処理要求電文 REQ、SYG 処理結果電文 電文 処理結果電文 交 換 ファイル ③ 交 換 ファイルに 格 納 され た処 理 結 果 電 文 を受 信 できた ら、企 業 内 シ ステ ム か ら受 信 完 了 電 文を 送 信 する ② 交 換 ファイル に 格 納 され た 処 理 結 果 電 文が 戻 ってくる 受信完了電文 ?A2 処理結果電文 ④ 交 換 ファイル に 格 納され た複 数 に 渡 る 処 理 結 果 電 文に つ い ては 、メイン処 理 部 が 受 信 完 了 電 文を受 け 取 った ら 次 の 電 文 が 送 信され てくる 図 4-3-7 ! インタラクティブ処理方式(ダイレクト・インターフェース)の処理例 受信完了電文(?A2)と障害通知電文(?A3)について 受信完了電文(?A2)は、電文種別が帳票用[P],[A]、社内インターフェース用[T]、ま たは、蓄積用[U]、の電文を利用者システムが正常に受信した際に送信する。 障害通知電文(?A3)は、電文種別が帳票用[P],[A]、社内インターフェース用[T]、ま たは、蓄積用[U]、の電文を利用者システムが正常に受信できなかった際に送信する。 (注 1)受信完了電文(?A2)と障害通知電文(?A3)の詳細は、「3.8.2」を参照すること。 4-3-9 4.3.6 その他 (1) 障害時の利用者システムでの処理概念 回線や機器の障害時における利用者システムでの処理の基本概念を示す。 このとき、利用者システムから見て、回線障害と通信処理装置障害は同じ事象となる。 ① 利用者システムでは、障害箇所や障害発生タイミングなどのステータス状態を管理し、 それに応じた処理を行うこと。 ② 障害回復の契機は利用者システムで行う。また、NACCS センターサーバとの間で発生し た障害については、障害回復後はコネクション開設処理より始めること。 ③ 交換ファイルに格納されている処理結果電文の受信時に、ダイレクト・インターフェー ス用ホストの部分障害などの通信に関係しない障害が発生し、処理結果電文が正常に受 信できなかった場合は、利用者システムからは NACCS センターサーバに対して受信完了 電文ではなく「障害通知電文」 (?A3)を送信すること。詳細は「3.8 ダイレクト・イン ターフェースにおける制御電文について」を参照のこと。 ④ NACCS センターサーバに対する処理要求電文の送信完了後は、利用者システムで処理完 了待ちのタイマー監視(処理結果通知電文待ち)を行い、障害発生を検知できるように しておかなければならない。タイマー監視により障害を検知した場合には、利用者シス テムでエラー処理を行うこと。タイマー値は2分以上とすること。 (2) 障害時の NACCS センターサーバでの処理概念 回線や機器の障害時における NACCS センターサーバでの処理の基本概念を示す。 ① 利用者システムからの処理要求電文のうち、業務処理の完了していないものは障害箇所 によっては破棄することがある。 ② 利用者システムへの処理結果電文の送信時に回線やセンターサーバに障害が発生した場 合、交換ファイルに格納されていない処理結果電文は破棄する。交換ファイルに格納さ れている処理結果電文については、QST 内にある電文ならば QFL に格納する。また、仮 に送信に成功した場合であっても、センターサーバでは利用者システムからの受信完了 電文待ちのタイマー監視を行っており、受信完了電文待ちの状態で一定時間が経過した 後は、QST 内の電文は QFL に格納する。(システムでは障害と認識する。)交換ファイル については「3.7 交換ファイル及び電文取出し業務について」を参照のこと。 ③ NACCS センターサーバ内にある通信処理装置が障害となったときは、予備の通信処理装 置への切り換えが自動的に行われる。この場合はコネクションが切断されるので、利用 者は次の処理を行うために再度コネクション開設処理を行う必要がある。また、通信処 理装置すべてが障害となった場合は、センターサーバからの応答がなくなるため、これ を検知するために利用者システムで応答待ちのタイマー監視を行うこと。タイマー監視 により障害を検知した場合には、利用者システムで一旦コネクションの閉塞を行い、通 信処理装置復旧後に、利用者システムから再度コネクションの開設処理を行う。タイマ ー値は5分間以上とすること。 4-3-10 ④ NACCS センターサーバ内にあるメイン処理部が障害となったときは、待機系のメイン処 理部への切り換えが自動的に行われ、オンラインを継続運転することができる。この場 合、コネクションは保持されるため利用者システムから再度コネクションの開設処理を 行う必要はない。また、メイン処理部がシステムダウンした場合、正常な業務処理は行 われず、DI サーバから障害通知が返却される。DI サーバから障害通知が来た場合には、 メイン処理部復旧後に業務開始が可能となる。ただし、利用者システムから再度コネク ションの開設を行う必要はない。 (3) 交換ファイルに格納された電文の保存期間 交換ファイル内の処理結果電文については、利用者は速やかに取り出しを行わなければな らない。電文は、利用者が取り出しを行った後に交換ファイル内から削除される。 ただし、利用者が取り出していない処理結果電文については、交換ファイルに登録された 日を含めて、7 日間(土日祝日を含む)は電文を交換ファイル内に保存する。電文の削除は深 夜の一定時刻に行われる。 なお、ゴールデンウィーク、年末年始においては、旧システムと同様に NACCS センターで 別途保存期間の設定変更を行う。 (参考) 交換ファイルに格納された処理結果電文の削除例(仮に一定時刻を午前 0:30 とした場合) 8/1(金)12:30 8/8(金)0:30 | 8/2(土)0:30 | ↓ ↓ 8/3 8/4 8/5 8/6 8/7 ↓ ――――☆―――|―――|―――|―――|―――|―――|―――★―――― | | |←―――――――――電文の保存期間―――――――――→| | | 登録 削除 (4) 旧システム ダイレクト・インターフェースとの主な違い インタラクティブ処理方式(ダイレクト・インターフェース)における、旧システムと本 システムの電文や処理に関する主な違いを以下に挙げる。 ① 業務開始電文(?B1)、業務終了電文(?B2)の廃止について 旧システムにおいては、コネクション開設後、業務を行う前に業務開始電文(?B1)を センターホストに送信する必要があったが、本システムでは業務開始電文を送信するこ となく業務を行うことができる。 また、業務終了時には業務終了電文(?B2)をセンターホストに送信する必要があ ったが、本システムでは業務終了電文を送信することなくコネクションの閉塞を行 うことができる。 利用者システムによっては、?B1、?B2 電文の応答を契機になんらかの処理を行っ ていることが考えられるため、本システムにおいて利用者が旧 NACCS における?B1、?B2 電文をセンター側に送信した場合も、交換ファイル電文数を 0、端末バージョン情報を スペースとした、ダミーの応答電文が返却される。 4-3-11 ② QFL(障害電文キュー)に格納される条件について 旧システムにおいては、一度タイムアウトが発生すると交換ファイルがクローズし、 QST(端末出力型電文キュー)に格納されている帳票電文が QFL(障害電文キュー)に格 納され、それ以降は、QST の電文が発生しても全て QFL へと格納していた。 本システムでは、電文がQSTに何件か格納されている状態で何らかの障害が発生す ると、障害発生時点でQSTに格納されている電文は全てQFLへ格納されるが、それ以降 に発生した帳票はQSTとして処理される。図 4-3-8と図 4-3-9に、旧NACCSと本システ ムのタイムアウト発生時の相違点を示す。 利用者システム NACCSセンターホスト DIサーバ 業務処理 メイン処理部 ①交換ファイルに処理結果電文を1件 格納する。(QSTに1件加算) 処理要求電文 業務 処理結果電文 タイムアウト発生 電文 ②タイムアウトが発生する。 ③交換ファイルがクローズ する。その時点にQSTに格 納されていた電文は、全て QFLに格納される。 処理要求電文 業務 QST 処理結果電文 QEX ④その後、即時型の 電文が発生しても、 全てQFLに格納され る。 ⑤交換ファイルに格納された 旨の処理結果電文が戻ってく る。 電文 QFL 交換ファイル SYG ⑥この状態は一度セッションの再接続をし直すまで続くため、以降の電文は全てSYGにて取得する必要がある。 図 4-3-8 タイムアウト発生時における電文の格納方法(旧システム) 4-3-12 利用者システム NACCSセンターサーバ DIサーバ 業務処理 メイン処理部 ①交換ファイルに処理結果電文を1件 格納する。(QSTに1件加算) 処理要求電文 業務 処理結果電文 タイムアウト発生 電文 ③その時点でQSTに格納 されていた電文は、全て QFLに格納されるが、それ 以降発生した電文につい ては影響が無い。 ②タイムアウトが発生する。 処理要求電文 QST 業務 処理結果電文 QEX ④旧システムと異な り、即時型の電文が 発生した場合でも、 QSTに格納される。 ⑤交換ファイルに格納された 旨の処理結果電文が戻ってく る。 電文 QFL 交換ファイル SYG ⑥SYG業務では、タイムアウト発生時点でQFLに格納し直された電文のみを取得する。 図 4-3-9 タイムアウト発生時における電文の格納方法(本システム) (5) 制限事項 インタラクティブ処理方式(ダイレクト・インターフェース)利用者は、以下の事項につ いて守らねばならない。 ① インタラクティブ処理方式(ダイレクト・インターフェース)利用者は、接続に際して NACCS のセンターサーバの運用に支障がないように配慮すること。センターサーバの運 用に支障を及ぼす場合、利用者システムに仕様の変更を求めることがある。また、利用 者システムの仕様変更等については、事前に NACCS センターまで報告をしなければなら ない。 ② 利用者は蓄積電文取り出し業務(REQ)や障害電文取り出し業務(SYG)を定期的(1日 数回、業務上支障のない範囲で)に行って、NACCS センターサーバにある交換ファイル 内の電文を取り出すこと。ただし、これらの業務を頻繁に行うことは、センターサーバ に負荷をかけるため、目安として30分程度間隔をあけて実施して下さい。 ③ インタラクティブ処理方式(ダイレクト・インターフェース)では、添付ファイル業務 を行うことは出来ない。 4-3-13 (6) その他の注意事項 インタラクティブ処理方式(ダイレクト・インターフェース)利用者は、以下の事項につ いて注意する必要がある。 ① 1 トランザクション内で複数の処理結果電文が発生した場合、利用者システムへのそれら の到着順序は保証されない。そのため、利用者システムでは処理結果通知電文が先に処 理されるような作り込みをしてはならない。 ② 受信完了電文と障害通知電文については、利用者システムに対して処理結果通知電文は 返信されない。 ③ NACCS センターサーバにある交換ファイルを経由する電文は、障害の発生タイミングによ っては、利用者システムで同じ電文を2度取得できてしまうことがある。入力情報特定 番号は入力情報がそのまま処理結果電文に設定されるため、利用者システムの作り込み により2通目の電文を無視することも可能である。(EXC 型電文を除く) ④ システムの高負荷時には、全利用者からの電文の受信を停止する等の運用制限をかける 場合がある。この場合、NACCS センターから利用者に対し電話、FAX 等により連絡を行う。 ⑤ 利用者側ダイレクト・インターフェース用ホストが故障した際、当該利用者コードまた は自社システム用利用者コードに係る障害電文キュー(QFL)に格納している障害電文を パッケージソフトから取り出すことが可能である。当該利用者コード、識別番号を利用 することで、ダイレクト・インターフェース用ホスト向けの障害電文を取り出すことが できる。 ⑥ 大規模災害等で、バックアップセンターにて NACCS が運用される場合には、バックア ップセンター用の DI サーバに接続すること。 ⑦ 接続試験を実施するための環境は、バックアップセンターの一部に構築される。このた め、大規模災害の発生等によりメインセンターに影響があった場合には、バックアップ センターによりシステム運転が実施されるため、接続試験が一部制限される場合がある。 4-3-14 (7) 各種タイマー値 インタラクティブ処理方式(ダイレクト・インターフェース)において規定するタイマー値を 表 4-3-2に示す。また、各タイマーの設定箇所について図 4-3-10から図 4-3-13に示す。 ID T01 T02 T03 T04 表 4-3-2 タイマー値一覧 監視内容 利用者側ダイレクト・インターフェース用ホストが処理要 求電文を送信完了してから、対応する処理結果電文が返却 されるまでの時間。 センターサーバやネットワークに障害が発生し、無応答と なった場合の再送可能時間。 NACCS センターサーバ内で何らかの異常が発生し、センタ ービジーである旨の処理結果通知電文が返ってきた場合 の再送可能間隔。 蓄積電文取り出し業務(REQ)や障害電文取り出し業務 (SYG)を定期的に行う間隔。 T05 タイマー値 2分 5分以上 3分以上 目安として30分程 度間隔をあけて実施 して下さい。 3分 センター側 DI サーバから処理結果電文(帳票用)を送付 し、受信完了電文(?A2)が返却されるまでの時間 (注)タイマー値は現行システムの設定値である。 (注)表 4-3-2のID欄に示すT01~T05 は、図 4-3-10~図 4-3-13に示す各タイマーのIDを示す。 電文種別 R または M のみ監視 図 4-3-10 処理結果電文のタイマー監視 4-3-15 利用者側 ダイレクト・インター フェース用ホスト センターサーバ 処理要求電文 処理結果電文(センタービジー) T03 処理要求電文 処理結果電文(正常) 図 4-3-11 センタービジーの場合のタイマー設定 利用者側 ダイレクト・インター センターサーバ フェース用ホスト 処理要求電文(SYGまたはREQ) 処理結果電文 T04 処理要求電文(SYGまたはREQ) 処理結果電文 図 4-3-12 SYG 業務、REQ 業務のタイマー設定 4-3-16 利用者側 ダイレクト・インター フェース用ホスト センターサーバ 処理要求電文 処理結果電文(帳票用) T05 受信完了電文(?A2) 図 4-3-13 受信完了電文(?A2)のタイマー設定 4-3-17
© Copyright 2024 Paperzz