発電計画等受領業務ビジネスプロトコル
通信手順及び受信確認メッセージ標準規格(Ver1.4)2023 年 4 月
電力広域的運営推進機関

はじめに
現在、産業界においては、産業の情報化の進展に伴い、業務の迅速化、高精度化、低コスト化を実現するために広く認められた標準を使用して、関係する企業及び業界間でデータの電子的な相互交換を行う EDI(Electronic Data
Interchange)が行なわれており、各業界内だけでなく業際大でもその推進活動が活発化してきている。
そこで、今般、電力広域的運営推進機関(以下、「本機関」という。) は、業務規程に基づき、広く意見募集を実施し系統利用者の意見聴取を行うとともに、全ての一般電気事業者の送配電部門、並びに複数の特定規模電気事業者
及び発電設備設置者と協議の上、通信手順・関係メッセージとして、「発電計画等受領業務ビジネスプロトコル通信
手順及び受信確認メッセージ標準規格」 (以下、「本規格」という。) を規定する。

-1-

[改定履歴]Ver
1.0

制(改)定年月日
2015 年 5 月 19 日

1.1

2015 年 7 月 27 日

1.2

2017 年 3 月 13 日

1.3

2017 年 11 月 22 日

1.4

2023 年 4 月 14 日

制(改)定概要
新規制定「発電計画等受領業務ビジネスプロトコル標準」
Ver.3C「発電計画等受領業務ビジネスプロトコル標準規格(計画値同時同量編)」Ver.3A
へ対応
・発電計画等伝送フロー修正
・誤記修正
・ネガワット取引の開始を受け、需要抑制契約者を対象に含むよう修正・FIT 買取制度の変更に伴い、送配電事業者を対象に含むよう修正・FIT 買取制度の変更に伴い送配電事業者からの計画提出を見直し・字句修正
・地域間連系線の間接オークション導入に伴い、該当箇所を変更
・需要抑制計画等受領業務 BP 規格のシステム対応に伴い、該当箇所を変更
・字句修正
・セキュリティ仕様強化に伴い、TLS1.3 のサポートを追加
・実需同時同量契約の廃止に伴い、各種メッセージおよびコードの削除
・字句修正

-2-

備考

目

次

1.目的 .............................................................................................................................................. - 4 2.システム概要 ................................................................................................................................... - 4 3.通信手順(JX 手順) ........................................................................................................................... - 5 3.1 JX 手順概要............................................................................................................................. - 5 3.1.1 用語説明 ........................................................................................................................... - 5 3.1.2 メソッド概要 ........................................................................................................................ - 5 3.2 JX 手順メッセージ構造 ............................................................................................................... - 6 3.2.1 シンタックスルール............................................................................................................... - 6 3.2.2 シーケンス ....................................................................................................................... - 11 3.2.3 メッセージ交換定義(WSDL)................................................................................................. - 18 3.2.4 JX 手順の動作の全体フロー................................................................................................ - 21 3.3 エラー通知 ............................................................................................................................ - 21 3.3.1 HTTP 通信レベルのエラー ................................................................................................. - 22 3.3.2 SOAP レベルのエラー ........................................................................................................ - 22 3.3.3 業務アプリケーション層のエラー ........................................................................................... - 24 3.4 セキュリティ仕様 ...................................................................................................................... - 24 3.5 運用規則 ............................................................................................................................... - 24 3.6 通信パラメータ協定 ................................................................................................................. - 24 4.業務メッセージ伝送 ........................................................................................................................ - 26 4.1 伝送対象業務メッセージについて .............................................................................................. - 26 4.2 発電計画 BP 標準に規定する標準メッセージの伝送について ......................................................... - 26 4.2.1 伝送フロー ....................................................................................................................... - 26 4.2.2 伝送対象メッセージ ........................................................................................................... - 29 5.業務メッセージの受信確認 .............................................................................................................. - 31 5.1 概要 ..................................................................................................................................... - 31 5.2 受信確認メッセージ ................................................................................................................. - 31 5.3 データ要素 ............................................................................................................................ - 31 5.3.1 データ属性の表記法.......................................................................................................... - 31 5.3.2 受信確認メッセージのデータ要素......................................................................................... - 32 5.4 共通データコード .................................................................................................................... - 33 5.5 構文規則 ............................................................................................................................... - 34 5.5.1 交換構造 ......................................................................................................................... - 34 5.5.2 XML タグ名称付与規則...................................................................................................... - 35 5.5.3 メッセージグループヘッダ ................................................................................................... - 36 5.5.4 メッセージを構成するデータ要素における空等の扱い .............................................................. - 36 5.6 メッセージファイル運用規則 ...................................................................................................... - 37 5.6.1 保存期間 ......................................................................................................................... - 37 5.6.2 メッセージファイル名称付与規則 .......................................................................................... - 37 5.6.3 メッセージの変更・取消の運用 ............................................................................................. - 37 5.6.4 メッセージの分割 ................................................................................................................ - 37 6.業務アプリケーション連係前エラー .................................................................................................... - 37 6.1 概要 ..................................................................................................................................... - 37 6.2 エラーメッセージ ..................................................................................................................... - 37 6.3 対象とするエラー .................................................................................................................... - 38 6.4 メッセージ構造 ....................................................................................................................... - 38 6.5 メッセージファイル運用規則 ...................................................................................................... - 38 6.5.1 保存期間 ......................................................................................................................... - 38 6.5.2 メッセージファイル名称付与規則 .......................................................................................... - 38 6.5.3 メッセージの変更・取消・分割の運用 ..................................................................................... - 39 7.利用文字コ－ド等 .......................................................................................................................... - 39 7.1 利用文字コード ....................................................................................................................... - 39 -3-

1.目的
託送業務に関する、一般送配電事業者(以下、「送配電事業者」という)、小売電気事業者、需要抑制契約者及び FIT
買取を行う送配電事業者(3 者を包含し、以下、「小売電気事業者等」という)、発電事業者、本機関間の EDI によるメッセージ交換に関し、通信手順及び通信結果を確認するための「受信確認メッセージ」の表現方法について規定する。

2.システム概要
インターネット網を介して、小売電気事業者等、発電事業者、送配電事業者、本機関との情報連携を行う。(図 2-1)
なお、Web サーバ(又は、単にサーバ)、Web クライアント(又は、単にクライアント)とは、通信プロトコル上の区別を指し、実際のハードウェアを指す場合は、サーバマシン、クライアントマシンと記述する。

発電事業者

Webクライアント

Webクライアント

送配電事業者

Webサーバ

HTTPS

インターネット網

本機関
WebサーバWebクライアント

図 2-1 システム概要-4-

Webクライアント

3.通信手順(JX 手順)
本章では、通信手順として利用する JX 手順について記載する。本手順は平成 20 年度経済産業省委託事業 流通
システム標準化事業として(財)流通システム開発センターから公開されている「通信プロトコル標準化に関する調査研究
報告書 インターネットを利用した通信プロトコル標準ガイドライン 平成 20 年度第 2.0 版」の「2.3 JX 手順」を元にしている。

3.1 JX 手順概要
業務メッセージを転送するための3つのメソッドより構成されるシンプルな通信プロトコルである。
業務メッセージを転送する仕組みとしてSOAP(Simple Object Access Protocol)-RPC(Remote Procedure Call)を用い、SOAPを転送するプロトコルとしては、HTTP(HyperText Transfer Protocol)を用いる。
3.1.1 用語説明
本章で利用される用語のうち、発電計画等受領業務 EDI 共通規格及び他の標準規格と用語の利用が異なるもの
について記載する。(表 3-1)

用語
メッセージ
業務メッセージ

サーバ企業
クライアント企業

表 3-1 用語とその意味
意味「3.2 JX 手順メッセージ構造」で規定する JX 手順メッセージが該当する。
他の BP 標準で「メッセージファイル」として記載されている XML ファイル、受信確
認メッセージファイル(「5.業務メッセージの受信確認」で規定)及びエラーファイル(「6.業務アプリケーション連係前エラー」で規定)を指す。
本章(通信手順)内では業務メッセージと記載されているものは、引用元ガイドライン
では、ビジネス文書と記載されているものが該当する。引用元ガイドラインでは
SOAP-RPC メッセージ等との記載がされているが、業務メッセージと SOAP-RPC メ
ッセージは異なるものである。
JX 手順サーバを設置する企業を指す。本規格では送配電事業者あるいは本機関。
JX 手順クライアントを利用する企業を指す。本規格では小売電気事業者等、発電事業者、本機関。

3.1.2 メソッド概要
プロトコルモデルは、クライアントを起点としサーバに対して行う以下の 3 つのメソッドにより構成される。(表 3-2)
本規格においては、送配電事業者と本機関をサーバ、小売電気事業者等、発電事業者、本機関、送配電事業者
をクライアントとする。

メソッド
PutDocument
GetDocument
ConfirmDocument

表 3-2 JX 手順を構成する 3 つのメソッド
機能
1 業務メッセージをサーバに送信する機能
サーバにある自分宛ての未取得業務メッセージのうち、古いものから 1 つ取得する機能
取得した業務メッセージの識別 ID をサーバに通知し、取得したことを通知する機能-5-3.2 JX 手順メッセージ構造
3.2.1 シンタックスルール
PutDocument/GetDocument/ConfirmDocument の 3 つのメソッドは、それぞれ HTTP リクエストと HTTP レスポンス
毎に以下の 6 つのメッセージが定義されている。
・PutDocument メッセージ
・PutDocumentResponse メッセージ
・GetDocument メッセージ
・GetDocumentResponse メッセージ
・ConfirmDocument メッセージ
・ConfirmDocumentResponse メッセージ
これらのメッセージの構成は、図 3-1 のようになる。
JX 手順メッセージ
HTTP ヘッダ
HTTP コンテンツ
SOAP エンベロープ
SOAP ヘッダ
メッセージ共通要素
SOAP ボディメッセージ固有要素

図 3-1 メッセージ構成(1) HTTPヘッダの記述形式
JX手順のHTTPへのバインディング仕様では、HTTPヘッダは以下のように規定されている。(表3-3)

HTTPヘッダ要素
POST
Host
Content-Length
Content-type
SOAPAction

表 3-3 HTTP ヘッダの記述形式
説明
クライアント企業、サーバ企業が相互に決めたパス
サーバ企業のドメイン名及びポート番号
メッセージボディの長さ(バイト数)
エンティティボディのメディアタイプ
SOAP-RPC要求の意図

HTTPヘッダの具体例を次に示す。
POST/SOAP-RPC HTTP/1.1
Host:www.sample.co.jp
Content-Length:1024
Content-Type:text/xml;charset=UTF-8
SOAPAction:“http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server/PutDocument”
ここに挙げた以外のHTTPヘッダ要素については、RFC2616 を参照されたい。
-6-

(2) SOAPヘッダの記述形式
SOAPヘッダ内のメッセージ共通の要素にはMessageHeader要素があり、すべてのメッセージは、MessageHeader要素を含む必要がある。(表3-4)
表 3-4 SOAP ヘッダの記述形式
MessageHeader要素
説明
From
メッセージ送信元のURI、又は、メールアドレス、GLN等の企業をユニークに識別できる情報を記載する。
To
メッセージ送信先のURI、又は、メールアドレス、GLN等の企業をユニークに識別できる情報を記載する。
MessageId
メッセージの一意性を保持するための識別子
形式は、“ドメイン内でユニークとなる文字列@ドメイン名”を利用することとする。
ドメイン内でユニークとなる文字列については、タイムスタンプ“YYYYMMDDhhmmssfff”の利用を推奨するが、処理系が高速な場合等で、タイムスタンプでユニークな文字列となることが確保できない場合は、別形式の利用も可能。
ドメイン名については、本機関が設定する事業者コードも利用可能。
Timestamp
メッセージを作成した世界協定時(UTC)による日時
形式は、“YYYY-MM-DDThh:mm:ss”とする。
OptionalFormatType(*1)
GetDocumentメッセージの際、取得対象となる業務メッセージの形式を限定するためのフォーマットタイプを指定する。オプション。
OptionalDocumentType(*1) GetDocumentメッセージの際、取得対象となる業務メッセージの種別を限定するためのドキュメントタイプを指定する。オプション。
(*1)OptionalFormatType要素、OptionalDocumentType要素の使用上の注意
・OptionalFormatType要素、OptionalDocumentType要素の両方を指定するか、両方を省略するかのどちらかである。片方だけの指定は認めない。
・GetDocumentの場合にのみ有効となる。GetDocument以外のリクエストメッセージ、及び、レスポンスメッセージの場合は、これらの要素を無視し、機能上に影響しないものとする。
・両方を省略した場合のGetDocumentは、業務メッセージの形式と種別を指定しないGetDocument仕様となる。
すなわち自企業宛のすべての業務メッセージが対象となる。
(3) SOAPボディの記述形式
SOAPボディ内のメッセージ固有の要素には、以下の要素がありいずれかの要素が含まれる。
・PutDocument要素
・PutDocumentResponse要素
・GetDocument要素
・GetDocumentResponse要素
・ConfirmDocument要素
・ConfirmDocumentResponse要素
主要な要素の説明を以下に記す。
① PutDocument要素
PutDocument要素は、PutDocumentメッセージのSOAPボディ要素に含まれる。下記の要素を含む。(表3-5)-7-表 3-5 PutDocument の要素
PutDocument要素
説明
messageId
送信業務メッセージの一意性を保持するための識別子
重複送信検出に用いる。
形式は、“ドメイン内でユニークとなる文字列@ドメイン名”を利用することとする。
ドメイン内でユニークとなる文字列については、本規格では、タイムスタンプ“YYYYMMDDhhmmssfff”の利用を推奨するが、処理系が高速な場合等で、タイムスタ
ンプだけでユニークな文字列となることが確保できない場合は、別形式の利用も可能。
ドメイン名については、本機関が設定する事業者コードも利用可能。
data
Base64にエンコードされたZIP形式で圧縮された送信業務メッセージ
senderId
業務メッセージ送信元企業の識別子
本規格では「表5-5 共通データコード」の送信者コードを使用する。
receiverId
業務メッセージ受信企業の識別子
本規格では「表5-5 共通データコード」の受信者コードを使用する。
formatType(*)
業務メッセージの形式
本規格では“Mutuality defined”(相互定義の意味)を指定する。(固定)
documentType(*)
業務メッセージの種別
具体的には、「表4-1 発電計画等受領業務関係メッセージ一覧」、「表4-2 発電計画等受領業務関係メッセージに伴う受信確認メッセージ一覧」に記述。
compressType
業務メッセージの圧縮・解凍形式
業務メッセージの圧縮・解凍は、上位アプリケーションで実施する。
本規格では、圧縮形式はZIP形式とし、compressTypeはapplication/zipを指定する。
(*)formatType要素、documentType要素の使用上の注意
・PutDocumentメッセージのformatTypeとdocumentTypeの両要素の値が、サーバ側で登録されているものかを確認する。登録がない場合、SOAP Faultを返す。
本規格では、流通BMS(ビジネスメッセージ標準)以外の業務メッセージを交換するため、双方で業務メッセージの形式と種別の文字列を決定し、サーバに登録しておく。
② PutDocumentResponse要素
PutDocumentResponse要素は、PutDocumentResponseメッセージのSOAPボディ要素に含まれる。下記の要素を含む。(表3-6)

PutDocumentResponse要素
PutDocumentResult

表 3-6 PutDocumentResponse の要素
説明
PutDocumentメソッドの結果
trueかfalseのどちらかを指定する。サーバ側は業務メッセージを正常に受信できた場合、trueを返す。同じmessageIdにより重複受信を検知した場合は、
falseを返す。

③ GetDocument要素
GetDocument要素は、GetDocumentメッセージのSOAPボディ要素に含まれる。下記の要素を含む。(表3-7)

GetDocument要素
receiverId

表 3-7 GetDocument の要素
説明
業務メッセージ受信企業の識別子-8-④ GetDocumentResponse要素
GetDocumentResponse要素は、GetDocumentResponseメッセージのSOAPボディ要素に含まれる。下記の要素を含む。(表3-8)

GetDocumentResponse要素
GetDocumentResult

messageId

data
senderId
receiverId
formatType
documentTypecompressType

表 3-8 GetDocumentResponse の要素
説明
GetDocumentメソッドの結果
trueかfalseのどちらかを指定する。サーバ側は業務メッセージが存在して送信できた場合、trueを返す。業務メッセージが存在しない場合は、falseを返す。
なお、GetDocumentにおける、業務メッセージの形式と種別限定の指定方
法に関しては表下(※)注意を参照。
受信業務メッセージの一意性を保持するための識別子
形式は、“ドメイン内でユニークとなる文字列@ドメイン名”を利用することとする。
ドメイン内でユニークとなる文字列については、タイムスタンプ“YYYYMMDDhhmmssfff”の利用を推奨するが、処理系が高速な場合等
で、タイムスタンプでユニークな文字列となることが確保できない場合は、別形式の利用も可能。
ドメイン名については、本機関が設定する事業者コードも利用可能。
クライアントが業務メッセージを正常に受信出来たことをサーバに通知するために、この識別子をConfirmDocumentによる受信確定通知で用いる。
Base64にエンコードされたZIP形式で圧縮された受信業務メッセージ
業務メッセージ送信元企業の識別子
本規格では「表5-5 共通データコード」の送信者コードを使用する。
業務メッセージ受信企業の識別子
本規格では「表5-5 共通データコード」の受信者コードを使用する。
業務メッセージの形式“Mutuality defined”(相互定義)を指定する。
業務メッセージの種別
具体的には、「表4-1 発電計画等受領業務関係メッセージ一覧」、「表42 発電計画等受領業務関係メッセージに伴う受信確認メッセージ一覧」に記述。
業務メッセージの圧縮・解凍形式
業務メッセージの圧縮・解凍は、上位アプリケーションで実施する。
圧縮形式はZIP形式とし、compressTypeはapplication/zipを指定する。

(※)注意
JX手順クライアント動作:
・取得する業務メッセージの形式と種別を限定する指定をしない場合は、SOAPヘッダ部にOptionalFormatType、OptionalDocumentTypeの両要素のないGetDocumentリクエストメッセージを送信する。
・業務メッセージの形式と種別を限定する場合は、SOAP ヘッダ部のOptionalFormatType、
OptionalDocumentTypeの両要素に、取得したい業務メッセージの形式と種別を指定する。
JX手順サーバ動作:
・SOAPヘッダ部にOptionalFormatType、OptionalDocumentType両要素がない場合は、サーバ側永続記憶に存在する業務メッセージ中で、未受信、かつ、最も登録の古いものを送信する。業務メッセージが存在しない場合は、GetDocumentResult要素でfalseを返す。
・SOAPヘッダ部にOptionalFormatType、OptionalDocumentType両要素が指定された場合は、業務メッセー
ジを蓄えている永続記憶に存在する業務メッセージ中で、指定された業務メッセージの形式と種別を持
つ、未受信、かつ、最も登録の古いものを送信する。指定された業務メッセージの形式と種別を持つ業務メッセージが存在しない場合、GetDocumentResult要素でfalse を返す。
・なお、OptionalFormatType、OptionalDocumentTypeが片方のみの指定の場合、SOAP Faultを応答する。
-9-

・GetDocumentメッセージの、OptionalFormatType、OptionalDocumentTypeの両要素の値が、サーバ側で登録されているものかを確認する。登録がない場合、SOAP Faultを返す。
本規格で利用するメッセージは流通BMS(ビジネスメッセージ標準)と異なるため、形式と種別の文字列については本規格のものをサーバへ登録すること。
⑤ ConfirmDocument 要素
ConfirmDocument 要素は、ConfirmDocument メッセージの SOAP ボディ要素に含まれる。下記の要素を含む。
(表 3-9)ConfirmDocument要素
messageId
senderId
receiverId

表 3-9 ConfirmDocument の要素
説明
GetDocumentメソッドで取得した業務メッセージのmessageIdを指定する。
業務メッセージ送信元企業の識別子
本規格では「表5-5 共通データコード」の送信者コードを使用する。
業務メッセージ受信企業の識別子
本規格では「表5-5 共通データコード」の受信者コードを使用する。

⑥ ConfirmDocumentResponse 要素
ConfirmDocumentResponse 要素は、ConfirmDocumentResult メッセージの SOAP ボディ要素に含まれる。下記の要素を含む。(表 3-10)
表 3-10 ConfirmDocumentResponse の要素
ConfirmDocumentResponse要素
説明
ConfirmDocumentResult
ConfirmDocument メソッドの結果
trueかfalseのどちらかを指定する。サーバ側は正常に受信確定した場
合、trueを返す。同じmessageIdが重複して通知された場合は、falseを返す。
※documentType 要素
documentType 要素については、「4.業務メッセージ伝送」により設定する。
※compressType 要素
業務メッセージの圧縮は、業務アプリケーション(レベル)で実施する。JX 手順では、送信される業務メッセージが圧縮されているか否かを指定する。本規格では業務メッセージを圧縮することとしているため、PutDocument メッセージ等の compressType 要素に次のとおり圧縮形式を指定する。なお、圧縮されていない場合は長さ 0 の文字列を指定する。(ただし本規格では必ず ZIP 圧縮とする)
また、圧縮対象は 1 ファイルのみとする。
圧縮形式(アーカイブ形式)は、IANA(The Internet Assigned Numbers Authority:http://www.iana.org/)によって管理されている公式の MIME メディアタイプを使用して指定する。ここで IANA は、インターネット上のプロトコルに関する様々なパラメタ(数値や記号)を管理する団体である。(表 3-11)

圧縮形式
ZIP

拡張子
.zip

表 3-11 圧縮形式指定の MIME メディアタイプ
説明
MIMEメディアタイプ
Zip形式
Application/zip

なお、ファイルの圧縮に際して、パスワードは設定しない。

- 10 -

3.2.2 シーケンス(1) 階層別のシーケンス
本節では、JX 手順における通信のシーケンスについて述べる。
JX 手順による業務メッセージの送受信は、図 3-2 のようなレイヤ構造になる。なお、SOAP-RPC レベルでは、業務
メッセージの保存や状態変更の業務アプリケーションレベルの内容まで含まれる。

SOAP-RPC

SOAP-RPC レベル

SOAP-RPC

HTTP 通信

HTTP レベルHTTP 通信

図 3-2 JX 手順通信レイヤ構造(a) JX 手順レベルのシーケンス●業務メッセージの送信
JX 手順で規定されている送信の流れを図 3-3 に示す。この例は通信経路上で異常が発生しなかった場合であ
る。

JX 手順
クライアント

業務メッセージ

JX 手順
サーバ①業務メッセージとmessageId=20160620202020200@sam
ple.co.jp の保存②業務メッセージとmessageId=20160620
202020200@sample.co.jp を保存し状態を受信済みに更新PutDocument
永続記憶
messageId=20160620202020200@sample.co.jp

永続記憶
PutDocumentResponse
業務メッセージ③業務メッセージの状態を送信済みに変更④業務メッセージの状態を AP 処理済
みに変更

図 3-3 JX 手順レベルの送信シーケンス
クライアント側は、送信する業務メッセージと messageId を永続記憶に保存(①)し、PutDocument で業務メッセー
ジを送信する。
サーバ側は、受信した業務メッセージと messageId を永続記憶に保存(②)後、業務メッセージの状態を受信済み- 11 -

に更新し PutDocumentResponse を返す。なお、PutDocument に異常があった場合は、PutDocumentResponse の代わりに SOAP Fault を返す。
クライアント側は、PutDocumentResponse により業務メッセージの状態を送信済みに変更する(③)。
サーバ側は、業務メッセージをアプリケーションに渡した後に、業務メッセージの状態をアプリケーション処理済
みに変更する(④)。
JX 手順では、永続記憶を利用した信頼性保証機能を実現している。信頼性保証機能の詳細については、「(2)信頼性保証機能」を参照されたい。
●業務メッセージの受信
JX 手順で規定されている受信の流れを図 3-4 に示す。この例は通信経路上で異常が発生しなかった場合であ
る。

JX 手順
クライアント② 業 務 メ ッ セ ー ジ とmessageId=2016062021212
1210@sample.co.jp を保存し状態を受信済みに更新

JX 手順
サーバ

①業務メッセージとmessageId=20160620212121210@sample.co.jp
を保存し、状態を未送信に更新

業務メッセージ

GetDocument
永続記憶
永続記憶

GetDocumentResponse
messageId=20160620212121210@sample.co.jp

ConfirmDocument
業務メッセージ
messageId=20160620212121210@sample.co.jp

ConfirmDocumentResponse④業務メッセージの状態をAP 処理済みに変更③業務メッセージの状態を送信済みに変更

図 3-4 JX 手順レベルの受信シーケンス
サーバ側は、送信する業務メッセージと messageId を永続記憶に保存し、業務メッセージの状態を未送信にする(①)。
クライアント側より GetDocument で業務メッセージの受信要求を行う。
サーバ側は、未送信の古い業務メッセージから GetDocumentResponse でクライアント側に業務メッセージを渡す。なお、送信業務メッセージが無い場合は、GetDocumentResponse で GetDocumentResult=false を返さなければならない。また、GetDocument に異常があった場合は、GetDocumentResponse の代わりに SOAP Fault を返す。
クライアント側は、GetDocumentResponse により受信した業務メッセージと messageId を永続記憶に保存(②)後、業務メッセージの状態を受信済みに更新し ConfirmDocument で受信確定通知をサーバ側に送信する。サーバ側は、業務メッセージの状態を送信済みに変更(③)し、ConfirmDocumentResponse をクライアント側に返す。なお、
ConfirmDocument に異常があった場合は、ConfirmDocumentResponse の代わりに SOAP Fault を返す。
クライアント側は、業務メッセージをアプリケーションに渡した後に、業務メッセージの状態をアプリケーション処
理済みに変更する(④)。
サーバ側に未送信の業務メッセージが複数あった場合は、GetDocument と ConfirmDocument を交互に呼び出す必要がある。なお、GetDocument 後、ConfirmDocument を実行せずに GetDocument を実行すると前回の- 12 -

GetDocument で受信した業務メッセージが受信される。
JX 手順では、永続記憶を利用した信頼性保証機能を実現している。信頼性保証機能の詳細については、(2)
信頼性保証機能」を参照されたい。
(b) HTTP レベルのシーケンス●業務メッセージの送信
HTTP レベルでの業務メッセージの送信シーケンスを図 3-5 に示す。
JX 手順
クライアント

JX 手順
サーバ

HTTP リクエスト

PutDocument

PutDocumentResponse
HTTP レスポンス

図 3-5 HTTP レベルの送信シーケンス●業務メッセージの受信
HTTP レベルでの業務メッセージの受信シーケンスを図 3-6 に示す。
JX 手順
クライアント

JX 手順
サーバ

HTTP リクエスト

GetDocument

GetDocumentResponse
HTTP レスポンス
HTTP リクエスト

ConfirmDocument

ConfirmDocumentResponse
HTTP レスポンス

図 3-6 HTTP レベルの受信シーケンス- 13 -

(2) 信頼性保証機能
インターネットでは相手システムまでの通信経路の信頼性を保証することができない。そのため、JX 手順では、業務メッセージを確実に送り届けるための仕組みである信頼性保証機能を備えている。そのため、JX 手順レベルの階層で通信の信頼性を保証することができる。
JX 手順で規定されている信頼性保証機能は以下の通りである。(表 3-12)

種別
欠落防止
重複破棄

表 3-12 信頼性保証機能
内容
通信経路上の異常により、送信されたデータが受信側に到達しなかった場合、それを検出して再度データを送信する。
先発のデータと再送したデータの両方が受信側システムに到達した場合に、受信側のアプリケーションに同じデータを渡さない。

(a) 欠落防止●業務メッセージの送信
ク ラ イ ア ン ト 側 は 、 PutDocument で 業 務 メ ッ セ ー ジ を 送 信 後 、 SOAP Fault を 受 け 取 っ た 場 合 や
PutDocumentResponse がクライアントで定める所定時間を過ぎても返って来なかった場合には、PutDocument を再送信しなければならない。なお、再送信はクライアントが定める所定回数リトライを行い、それでも送信できない場
合はリトライオーバとする。(図 3-7)
JX 手順
クライアント

業務メッセージ

JX 手順
サーバ①業務メッセージとmessageId=20160401202020200@sample.co.jpの保存

PutDocument② 業 務 メ ッ セ ー ジ とmessageId=2016040120202
0200@sample.co.jp を 保 存
し状態を受信済みに更新

永続記憶
messageId=20160401202020200@sample.co.jp

PutDocument

永続記憶

messageId=20160401202020200@sample.co.jp

PutDocumentResponse
業務メッセージ③業務メッセージの状態を送信済みに変更④業務メッセージの状態
を AP 処理済みに変更

図 3-7 業務メッセージ送信時の欠落防止- 14 -

●業務メッセージの受信
クライアント側は、GetDocument で業務メッセージの受信要求後、GetDocumentResponse がクライアントで定める所定時間を過ぎても返って来なかった場合には、GetDocument で再受信要求しなければならない。なお、再受信要求はクライアントが定める所定回数リトライを行い、それでも受信できない場合はリトライオーバとする。
サーバ側は GetDocumentResponse 後、ConfirmDocument を受信する前に、GetDocument を受信した場合は前回の業務メッセージを GetDocumentResponse で返さなければならない。(図 3-8)

JX 手順
クライアント

JX 手順
サーバ①業務メッセージとmessageId=20160401212121210@sample.co.jp
を保存し、状態を未送信に更新

業務メッセージ

GetDocument
永続記憶
GetDocumentResponse② 業 務 メ ッ セ ー ジ とmessageId=2016062021212
1210@sample.co.jp を保存し状態を受信済みに更新

messageId=20160401212121210@sample.co.jp

GetDocument

GetDocumentResponse
永続記憶messageId=20160401212121210@sample.co.jp

ConfirmDocument
業務メッセージ

messageId=20160401212121210@sample.co.jp

ConfirmDocumentResponse④業務メッセージの状態をAP 処理済みに変更

図 3-8 業務メッセージ受信時の欠落防止- 15 -③業務メッセージの状態を送信済みに変更

(b) 重複破棄●業務メッセージの送信
クライアント側は、PutDocument で業務メッセージを送信後、PutDocumentResponse がクライアントで定める所定時間を過ぎても返って来なかったため、PutDocument を再送信する。
サーバ側は 1 回目の PutDocument で業務メッセージを既に受信済みのため、2 回目の受信業務メッセージを破棄し、PutDocumentResponse で PutDocumentResult=false を返さなければならない。業務メッセージの重複チェック
は PutDocument の messageId を使用する。
クライアント側は、PutDocumentResponse が PutDocumentResult=false の場合、既に送信済みと見なし、業務メッ
セージの状態を送信済みに変更する。
サーバ側での重複処理のための messageId を保持する期間は「3.5 運用規則」の通りとする。(図 3-9)
JX 手順
クライアント

JX 手順
サーバ①業務メッセージとmessageId=20160401202020200@sam
ple.co.jp の保存

業務メッセージ②業務メッセージとmessageId=20160401
202020200@sample.co.jp を保存し状態を受信済みに更新

PutDocument
永続記憶
messageId=20160401202020200@sample.co.jp

永続記憶
PutDocumentResponse
業務メッセージ
PutDocument
messageId=20160401202020200@sample.co.jp

PutDocumentResponse
PutDocumentResult=false③業務メッセージの状態をAP 処理済みに変更⑤業務メッセージの状態を送信済みに変更

図 3-9 業務メッセージ送信時の重複破棄- 16 -④受信業務メッセージの廃棄●業務メッセージの受信
クライアント側は ConfirmDocument 送信後、サーバ側からの ConfirmDocumentResponse がクライアントで定める所定時間を過ぎても返って来なかったため、ConfirmDocument を再送信する。
サーバ側は 1 回目の ConfirmDocument で業務メッセージは既に送信済みのため、ConfirmDocumentResponse
で ConfirmDocumentResult=false を返さなければならない。なお、ConfirmDocument で指定された messageId が不明(サーバ側からの GetDocumentResponse で返した messageId 以外)な場合は、ConfirmDocumentResponse の代
わりに SOAP Fault を返す。
クライアント側は、ConfirmDocumentResponse が ConfirmDocumentResult=false の場合は、受信確定通知済みと見なし、ConfirmDocumentResponse が正常時と同様の処理を行う。
な お 、 ク ラ イ ア ン ト 側 は 、 GetDocumentResponse に よ り 受 信 し た 業 務 メ ッ セ ー ジ を 永 続 記 憶 に 保 存 後 、ConfirmDocument が完了する前に GetDocument を送信し、サーバ側から前回と同じ業務メッセージが返された場
合は、既に受信済みのため破棄しなければならない。(図 3-10)

JX 手順
クライアント② 業 務 メ ッ セ ー ジ とmessageId=2016040121212
1210@sample.co.jp を保存し状態を受信済みに更新

JX 手順
サーバ
①業務メッセージとmessageId=20160401212121210@sample.co.jp
を保存し、状態を未送信に更新

業務メッセージ

GetDocument
永続記憶
GetDocumentResponse
messageId=20160401212121210@sample.co.jp

永続記憶ConfirmDocument
業務メッセージ

messageId=20160401212121210@sample.co.jp

ConfirmDocumentResponse③業務メッセージの状態を送信済みに変更

ConfirmDocument
messageId=20160401212121210@sample.co.jp

ConfirmDocumentResponse

ConfirmDocumentResult=false⑤業務メッセージの状態をAP 処理済みに変更

図 3-10 業務メッセージ受信時の重複破棄- 17 -④業務メッセージは既に送信済み

3.2.3 メッセージ交換定義(WSDL)WSDL(Web Services Description Language)は、Web サービスを記述するための、XML をベースとした言語仕様である。それぞれの Web サービスがどのような機能を持つのか、それを利用するためにはどのような要求をすればいいのか等を記述する方法が定義されている。
●JX 手順交換手順の WSDL
JX 手順(旧称 SOAP-RPC)の WSDL には、2003 年度版、2004 年度版及び 2007 年度版がある。なお、2003 年度
版と 2004 年度版の互換性は確保されていない。現在、2003 年度版の使用は推奨されていない。2007 年度版は、業
務メッセージの形式(formatType)と種別(documentType)を限定した取得機能を 2004 年度版からの上位互換性を考慮して作成された WSDL である。
本規格では、上述の種別を限定した取得機能を前提とするため、JX 手順の WSDL のうち、2007 年度版を採用する。
2007年度版:<?xml version=“1.0” encoding=“utf-8”?><!-- JX手順 WSDL 2008年3月版 --><definitions xmlns:http=“http://schemas.xmlsoap.org/wsdl/http/”
xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/”
xmlns:s=“http://www.w3.org/2001/XMLSchema”
xmlns:s0=“http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server”
xmlns:soapenc=“http://schemas.xmlsoap.org/soap/encoding/”
xmlns:mime=“http://schemas.xmlsoap.org/wsdl/mime/”
targetNamespace=“http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server”
xmlns=“http://schemas.xmlsoap.org/wsdl/”><types><s:schema elementFormDefault=“qualified” targetNamespace=“http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server”><s:element name=“PutDocument”><s:complexType><s:sequence><s:element minOccurs=“1” maxOccurs=“1” name=“messageId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“data” type=“s:base64Binary” /＞<s:element minOccurs=“1” maxOccurs=“1” name=“senderId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“receiverId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“formatType” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“documentType” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“compressType” type=“s:string” /></s:sequence></s:complexType></s:element><s:element name=“PutDocumentResponse”><s:complexType><s:sequence><s:element minOccurs=“1” maxOccurs=“1” name=“PutDocumentResult” type=“s:boolean” /></s:sequence></s:complexType></s:element><s:element name=“MessageHeader” type=“s0:MessageHeader” /><s:complexType name=“MessageHeader”><s:sequence><s:element minOccurs=“1” maxOccurs=“1” name=“From” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“To” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“MessageId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“Timestamp” type=“s:string” /><s:element minOccurs=“0” maxOccurs=“1” name=“OptionalFormatType” type=“s:string” /><s:element minOccurs=“0” maxOccurs=“1” name=“OptionalDocumentType” type=“s:string” /></s:sequence></s:complexType><s:element name=“GetDocument”><s:complexType><s:sequence>- 18 -

<s:element minOccurs=“1” maxOccurs=“1” name=“receiverId” type=“s:string” /></s:sequence></s:complexType></s:element><s:element name=“GetDocumentResponse”><s:complexType><s:sequence><s:element minOccurs=“1” maxOccurs=“1” name=“GetDocumentResult” type=“s:boolean” /><s:element minOccurs=“1” maxOccurs=“1” name=“messageId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“data” type=“s:base64Binary” /><s:element minOccurs=“1” maxOccurs=“1” name=“senderId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“receiverId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“formatType” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“documentType” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“compressType” type=“s:string” /></s:sequence></s:complexType></s:element><s:element name=“ConfirmDocument”><s:complexType><s:sequence><s:element minOccurs=“1” maxOccurs=“1” name=“messageId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“senderId” type=“s:string” /><s:element minOccurs=“1” maxOccurs=“1” name=“receiverId” type=“s:string” /></s:sequence></s:complexType></s:element><s:element name=“ConfirmDocumentResponse”><s:complexType><s:sequence><s:element minOccurs=“1” maxOccurs=“1” name=“ConfirmDocumentResult” type=“s:boolean” /></s:sequence></s:complexType></s:element></s:schema></types><message name=“PutDocumentSoapIn”><part name=“parameters” element=“s0:PutDocument” /></message><message name=“PutDocumentSoapOut”><part name=“parameters” element=“s0:PutDocumentResponse” /></message><message name=“PutDocumentMessageHeader”><part name=“MessageHeader” element=“s0:MessageHeader” /></message><message name=“GetDocumentSoapIn”><part name=“parameters” element=“s0:GetDocument” /><message name=“GetDocumentSoapOut”><part name=“parameters” element=“s0:GetDocumentResponse” /></message><message name=“GetDocumentMessageHeader”><part name=“MessageHeader” element=“s0:MessageHeader” /></message><message name=“ConfirmDocumentSoapIn”><part name=“parameters” element=“s0:ConfirmDocument” /></message><message name=“ConfirmDocumentSoapOut”><part name=“parameters” element=“s0:ConfirmDocumentResponse” /></message><message name=“ConfirmDocumentMessageHeader”><part name=“MessageHeader” element=“s0:MessageHeader” /></message>- 19 -

<portType name=“JXMSTransferSoap”><operation name=“PutDocument”><documentation>ドキュメントの送信(Client To Server)</documentation><input message=“s0:PutDocumentSoapIn” /><output message=“s0:PutDocumentSoapOut” /></operation><operation name=“GetDocument”><documentation>ドキュメントの受信(Client From Server)</documentation><input message=“s0:GetDocumentSoapIn” /><output message=“s0:GetDocumentSoapOut” /></operation><operation name=“ConfirmDocument”><documentation>ドキュメントの受信確認</documentation><input message=“s0:ConfirmDocumentSoapIn” /><output message=“s0:ConfirmDocumentSoapOut” /></operation></portType><binding name=“JXMSTransferSoap” type=“s0:JXMSTransferSoap”><soap:binding transport=“http://schemas.xmlsoap.org/soap/http” style=“document” /><operation name=“PutDocument”><soap:operation soapAction=http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server/PutDocument style=“document” /><input><soap:body use=“literal” /><soap:header message=“s0:PutDocumentMessageHeader” part=“MessageHeader” use=“literal” /></input><output><soap:body use=“literal” /><soap:header message=“s0:PutDocumentMessageHeader” part=“MessageHeader” use=“literal” /></output></operation><operation name=“GetDocument”><soap:operation soapAction=http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server/GetDocument style=“document” /><input><soap:body use=“literal” /><soap:header message=“s0:GetDocumentMessageHeader” part=“MessageHeader” use=“literal” /></input><output><soap:body use=“literal” /><soap:header message=“s0:GetDocumentMessageHeader” part=“MessageHeader” use=“literal” /></output></operation><operation name=“ConfirmDocument”><soap:operation soapAction=http://www.dsri.jp/edi-bp/2004/jedicos-xml/client-server/ConfirmDocument
style=“document”/><input><soap:body use=“literal” /><soap:header message=“s0:ConfirmDocumentMessageHeader” part=“MessageHeader” use=“literal” /></input><output><soap:body use=“literal” /><soap:header message=“s0:ConfirmDocumentMessageHeader” part=“MessageHeader” use=“literal” /></output></operation></binding><service name=“JXMSTransfer”><documentation>JX手順メッセージ転送サービス</documentation><port name=“JXMSTransferSoap” binding=“s0:JXMSTransferSoap”><soap:address location=“http://XXXX/XXX” /></port></service></definitions>※location 属性の下線部分は、実際のサーバ URI に置き換えて使用される。

- 20 -

3.2.4 JX 手順の動作の全体フロー
図 3-11 に JX 手順の動作の全体フローを示す。
なお、図中のビジネス文書は業務メッセージに読み替えること。

図 3-11 JX 手順動作フロー

3.3 エラー通知
エラーの発生する状況は以下の4層に分けて考えることができる。(図3-12、表3-13)
業務レベルデータ確認
業務 AP 層
宇

4層

業務レベルデータ確認

XML 文書妥当性検証

3層

XML 文書妥当性検証

SOAP-RPC

2層

SOAP-RPC

HTTP 通信

1層

HTTP 通信

図 3-12 階層別エラーの考え方

エラー発生階層
1層:HTTP通信レベル
2層:SOAP-RPCレベル
3層:XML文書妥当性検証
4層:業務レベルデータ確認

表 3-13 階層別エラー状況
エラー検出のタイミング
HTTPプロトコルレベルでのメッセージ交換時
SOAP Envelope内解析時受信したXML業務メッセージの妥当性検証時(字句チェックエラー)
受信側の業務アプリケーションでXML業務メッセージを処理中- 21 -

業務 AP 層宇

3.3.1 HTTP 通信レベルのエラー
HTTPでは、サーバからの応答として3桁の数字によるステータスコードが返される。この値が300台、400台、500台の場合がエラーである。
表3-14に、代表的なHTTPエラーを挙げる。

HTTPステータスコード
401
404
500
503

表 3-14 代表的な HTTP エラーコード
説明
認証に失敗した。
接続先URLに誤りがある。
サーバで何らかのエラーが発生した。
相手先のサーバが一時的に利用できない。

英文標記(例)“Unauthorized”“Not Found”“Internal Server Error”“Service Unavailable”

他のHTTPステータスコードについては、HTTPの仕様(RFC2068)を参照されたい。
3.3.2 SOAP レベルのエラー
JX 手順では、SOAP におけるエラー通知手段である SOAP Fault を使用する。つまり、リクエスト処理中に SOAP エラーが発生した場合、サーバは HTTP レスポンス 500 “Internal Server Error”を発行すると同時に、そのレスポンスは、Body 要素に SOAP 処理エラーを示す Fault 要素を持つ SOAP メッセージを含まなければならない。
Fault 要素は SOAP 本体中に一度しか記述することができない。また、Fault 要素も、Envelope 要素、Header 要素、Body 要素と同じ名前空間に属するため、名前空間接頭辞「soapenv」を用いて修飾する。
Fault 要素の記述ルールは次のとおりである。
・Fault 要素は、Body 要素中に 2 回以上現れてはいけない。
・Fault 要素は以下の子要素から構成される。(表 3-15)

Fault 要素
faultcode(必須要素)
faultstring(必須要素)
faultactor
detail

表 3-15 Fault 要素の子要素
用途・用法
エラー内容をコード(SOAP フォールトコード値)で示す。
エラー内容を説明する記述。エラーの性質についての何らかの説明が必要。
エラーを検出したアプリケーションを示す情報を提供する。この要素は違反の発生元 URI が示される。
Body 要素に関係するアプリケーション固有のエラー情報を伝える。この要素は Body 要素の内容処理が正常終了しなかった場合には存在しなくてはいけない。

- 22 -

Fault 要素の XML 文書記述例を次に示す。
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”/><SOAP-ENV:Header>…
</SOAP-ENV:Header><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>エラーの種類(例、server, client, mustUnderstand, …)</faultcode><faultstring>エラーの内容を表す文字列</faultstring><faultactor>誰がエラーを検出したか(例、URL)</faultactor><detail>エラーの詳細情報</detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>

また、仕様で定義されている違反を記述するときには、下記の faultcode の値が faultcode 要素の中で使われなけ
ればならない。(表 3-16)

faultcode の値
VersionMismatch
MustUnderstandClientServer

表 3-16 SOAP エラー通知(faultcode)
説明
SOAP Envelope 要素に対して間違った名前空間を検出
値“1”の mustUnderstand 属性を含んだ SOAP Header 要素の子要素があり、それが理解出来ないか、意図したように処理されていない。
メッセージが正しく構成されていないか、処理を進める上で適切な情報を含んでいないことを示す。
直接メッセージの内容に起因する原因ではなくメッセージの処理過程に関わる理由
でメッセージを処理することが出来なかったことを示す。

なお、SOAP エラー通知の詳細については、SOAP 1.1 の仕様を参照されたい。

- 23 -

3.3.3 業務アプリケーション層のエラー
本規格では、業務アプリケーション層のエラーについては SOAP Fault を利用しない。
第 3 層の XML 文書妥当性検証に該当する下記のエラーについて、「6.業務アプリケーション連系前エラー」で規定する。
・ファイルが添付されていない。
・ファイルが圧縮されていない、又は圧縮形式が違うため解読できない。
・展開したファイルにファイルネームが存在しない、又は解読できない。
・XML の文法エラーにより、業務システムでデータが解読できない。(業務メッセージのメッセージグループヘッダが解読できないものも含む)
第 4 層の業務アプリケーションレベルのエラー情報については、XML レベルで規定することとし、「5.業務メッセー
ジの受信確認」に記載する。

3.4 セキュリティ仕様
JX 手順におけるセキュリティ技術については、TLS1.2 および TLS1.3 に対応している。
本規格では、通信プロトコルレベルのセキュリティ確保に関して以下を利用する。
・SSL による暗号化通信
・SSL サーバ認証による、提出先サーバのなりすまし防止
・クライアント側電子証明書の認証による、提出元(発信者)のなりすまし防止
上記により、機密性・完全性・サーバ、クライアントの双方の認証を行う。
その他のセキュリティ技術の採用については規定しない。
SSL による暗号化通信について、Port 番号 443 の利用を標準とするが、事前に当事者間で Port 番号を確認しておく。

3.5 運用規則
サーバ側 messageId の保持期間については、1 ヶ月とする。
3.6 通信パラメータ協定
通信パラメータの設定に関しては、下記項目等について、相互で確認を実施する。
なお、調整必要の項目は調整欄◎印とし、空白部分はパラメータ設定値記載の内容を採用するものとする。また、アクセス周期・リトライ間隔は 10 秒以上を設定する。

- 24 -

通信パラメータ情報:JX 手順用
通信パラメータ情報 ： ＪＸ手順用
インターネット EDI プロトコル情報

平成 20 年度 経済産業省委託事業 インターネットを利用した通信プロトコル 利用ガイドライン
インターネットEDIプロトコル情報
SOAP-RPC（流通システム開発センタ発行）(財団法人2004年度版
流通システム開発センター
発行)
改訂版: 平成１８年度 経済産業省委託事業 インターネットを利用した通信プロトコル 利用ガイドライン
1 基本情報パラメータ設定値 (例)↓：当事者間で調整が必要な項目
調整 備考

1 通信プロトコル情報ID

1234567890123-3210987654321-001-ptc◎ EDI通信パラメータ協定シート2-2として相対で調整する

2 PPS側情報

3 卸側情報1 企業(サイト)の識別情報 4xxx
4xxx6

◎ 形式： GLN, URLなど、 senderID/receiverIDに設定する情報

2 マシンの識別情報◎ 形式： URL, メールアドレスなど To/Fromに設定する情報____@____.co.jp

1 企業(サイト)の識別情報 xxxx
100x3

◎ 形式： GLN, URLなど、 senderID/receiverIDに設定する情報

2 マシンの識別情報◎ 形式： URL, メールアドレスなど To/Fromに設定する情報

xxxx.sample.co.jp

2 トランスポート層情報 (Transport)
1 通信プロトコル情報
HTTP1.1
2 セキュリティプロトコ 1 プロトコル名・バージョン TLS1.2、TLS1.3
SSL3.0ル情報
2 サーバ認証
あり

3

調整 備考
HTTPなどのトランスポートプロトコル名・バージョン
SSLなどのセキュリティプロトコル名・バージョン
サーバ認証の有無

3 クライアント認証

あり

クライアント認証の有無；託送業務はSSLクライアント認証

4 ベーシック認証情報なし

ベーシック認証時の有無；クライアント認証必須のためベーシック認証は実施しない。

Mutuality defined

SOAPメッセージのformatType タグの値
託送では標準メッセージを利用しない

ドキュメント形式

4 エンドポイントURI

1 URI

https://____.co.jp:443/____◎ サーバのアクセスURI

2 ＩＰアドレス(オプション)

xxx.xxx.xxx.xxx:PortNo,
xxx.xxx.xxx.xxx:PortNo◎ サーバのIPアドレス（原則利用しない）

3 サブネットマスク(オプション)
255.255.255.252
3 EDI関連通信仕様情報 (DeliveryChannel)
1 同期/非同期応答モード
2 応答要求3 応答への署名
4 重複検出◎ サーバのサブネットマスク（原則利用しない）
調整 備考

同期応答
あり
なし
あり

同期モードで動作受領確認を要求するか受領確認メッセージに署名するか同じメッセージＩＤを持つメッセージは登録できない

4 ビジネスメッセージ特性 (BusinessTransactionCharacteristics)
1 圧縮

GLN(調達側)-GLN(供給側)-連番3桁-ptc

調整 備考

1 メッセージの圧縮あり

圧縮は行う。

2 圧縮形式

ZIP

ZIP形式

5 電子証明書情報（サーバ側企業のみ）
1 証明書の種類
6 電子証明書情報（クライアント側企業のみ）
1 証明書の種類◎：相対で要調整

調整
SSLサーバ証明書
調整
電子証明書

電子証明書運用基準に定めるものを利用すること。

電力広域的運営推進機関で一部項目を修正(2015/05/19)
電気事業連合会により一部項目を修正（2008/06/24）- 25 -

4.業務メッセージ伝送
4.1 伝送対象業務メッセージについて
本規格においては、伝送対象とする業務メッセージは、「発電計画等受領業務ビジネスプロトコル標準規格(計画値
同時同量編)」、「需要抑制計画等受領業務ビジネスプロトコル標準規格」 (以下、「発電計画 BP 標準」という)で規定す
る標準メッセージとする。
4.2 発電計画 BP 標準に規定する標準メッセージの伝送について
4.2.1 伝送フロー
小売電気事業者等、発電事業者、送配電事業者、本機関間で下記(図 4-1、図 4-2)のフローで提出及び通知を行う。小売電気事業者等又は発電事業者から計画を受領した本機関及び通知を受領した小売電気事業者等、発電事
業者は、「3.3 エラー通知」で規定するエラーがある場合を除き、受信確認メッセージを返信する。本機関から計画を受領する送配電事業者及び通知を受領した本機関も同様に、「3.3 エラー通知」で規定するエラーがある場合を除き、受信確認メッセージを返信する。受信確認メッセージのフォーマット等については「5.業務メッセージの受信確認」
で規定する。

- 26 -

小売電気事業者等
発電事業者(特定)送配電事業者(クライアント)

本機関

本機関

(サーバ)

(クライアント)(一般)送配電事業者(クライアント)(サーバ)

定期提出時/初期提出

①②③
①②③

・発電・販売計画
・発電・販売計画(FIT作成用)
・需要・調達計画
・経過措置計画・連系線希望計画
・需要抑制計画

JX手順送信
プロトコル

⑤

①②③

JX手順受信プロトコル⑤
各種受信確認メッセージ⑤①③

・発電・販売計画
・需要・調達計画
・経過措置計画・連系線希望計画

JX手順送信プロトコル
JX手順受信プロトコル

各種受信確認メッセージ・発電・販売計画
・発電・販売計画(FIT作成用)
・需要・調達計画
・経過措置計画・連系線希望計画
・需要抑制計画

JX手順送信プロトコル

JX手順受信プロトコル

各種受信確認メッセージ
JX手順送信プロトコル

発電・販売計画(FIT作成用)
JX手順受信プロトコル⑤

JX手順受信プロトコル①③

各種受信確認メッセージ

発電・販売計画(FIT作成用)

各種受信確認メッセージ

JX手順送信
プロトコル①③ 発電・販売計画(FIT作成用)

JX手順送信プロトコル⑤①③
JX手順受信プロトコル⑤

発電・販売計画

JX手順受信プロトコル

各種受信確認メッセージ⑤

JX手順送信プロトコル

各種受信確認メッセージ

部分供給関係提出④

部分供給通告値

JX手順送信プロトコル④
部分供給通告値⑥

各種受信確認メッセージ

JX手順送信プロトコル⑥

JX手順受信プロトコル

各種受信確認メッセージ

図 4-1 発電計画等伝送フロー(1)- 27 -

JX手順受信プロトコル

(クライアント)(サーバ)
業務処理結果の通知

ABＣE ・経過措置可否判定結果通知

・希望計画送電可否判定結果
通知・各種 不整合通知

FH

各種受信確認メッセージ

ABＣ・経過措置可否判定結果通知
・希望計画送電可否判定結果
通知

JX手順受信プロトコル

JX手順送信プロトコル

F

各種受信確認メッセージ

JX手順送信プロトコル

JX手順受信プロトコル・経過措置可否判定結果通知

ABＣE ・希望計画送電可否判定結果
通知・各種 不整合通知

FH

各種受信確認メッセージ

JX手順受信プロトコル

JX手順送信
プロトコル

混雑処理

D

D

各種 混雑処理通知メッセージ JX手順受信

各種 混雑処理通知メッセージ

JX手順送信プロトコル

各種受信確認メッセージ

JX手順受信
プロトコル

プロトコル

各種受信確認メッセージG

JX手順送信プロトコル

GD

各種 混雑処理通知メッセージ
JX手順受信プロトコル

各種受信確認メッセージG

図 4-2 発電計画等伝送フロー(2)- 28 -

JX手順送信プロトコル

4.2.2 伝送対象メッセージ
以下の業務メッセージの送受に関し、本規格の通信手順を用いて、メッセージの伝送を行う。
通信手順で指定する DocumentType についても表 4-1、表 4-2 に記載する。

表 4-1 発電計画等受領業務関係メッセージ一覧
番号

対象メッセージ

内容(翌日、週間、月間、年間)発電・販売計画メッセージ

左記メッセージの定期提出

発電・販売計画(FIT 作成用)

左記メッセージの定期提出①(翌日、週間、月間、年間)需要・調達計画メッセージ

左記メッセージの定期提出(翌日、週間、月間、年間)需要抑制計画メッセージ

左記メッセージの定期提出

経過措置計画メッセージ

左記メッセージの定期提出②

連系線希望計画メッセージ

左記メッセージの提出③①の計画変更提出、②の変更

計画変更等

④

(翌日、月間)部分供給通告値

左記メッセージの定期提出

A①の経過措置可否判定結果
通知メッセージ

左記メッセージ
の通知

B

C

D

②の送電可否判定結果通知
メッセージ③の送電可否判定結果通知
メッセージ

各種 混雑処理通知メッセージ

左記メッセージの通知

左記メッセージの通知

左記メッセージの通知

送信方向
小売電気事業者・発電事業者・(一般、特定)送配電事業者→本機関
本機関→(一般)送配電事業者
小売電気事業者・(一般、特定)送配電事業者→本機関
本機関→小売電気事業者・(一般)送配電事業者
小売電気事業者・発電事業者・(一般、特定)送配電事業者→本機関
本機関→(一般)送配電事業者
需要抑制契約者→本機関
本機関→(一般)送配電事業者
小売電気事業者・発電事業者→本機関
本機関→(一般)送配電事業者
小売電気事業者・発電事業者・(一般、特定)送配電事業者→本機関
本機関→(一般)送配電事業者
小売電気事業者・発電事業者・(一般、特定)送配電事業者→本機関
本機関→(一般)送配電事業者
小売電気事業者・発電事業者→本機関
本機関→(一般)送配電事業者
本機関→小売電気事業者・発電事業者・(一般、特定)送配電事業者
本機関→(一般)送配電事業者
本機関→小売電気事業者・発電事業者・(一般、特定)送配電事業者
本機関→(一般)送配電事業者
本機関→小売電気事業者・発電事業者・(一般、特定)送配電事業者
本機関→(一般)送配電事業者
本機関→小売電気事業者・発電事業者・(一般、特定)送配電事業者
本機関→(一般)送配電事業者- 29 -

DocumentType△△△△△△_periodic_plans_upload(※)△△△△△△_periodic_plans_upload(※)△△△△△△_periodic_plans_upload(※)△△△△△△_req_mod_plans_upload (※)

octow6_partial_plans_upload△△△△△△_periodic_plans_result_dl_xml(※)△△△△△△_periodic_plans_result_upload(※)△△△△△△_periodic_plans_result_dl_xml(※)△△△△△△_periodic_plans_result_upload(※)△△△△△△_req_mod_plans_result_dl_xml(※)△△△△△△_req_mod_plans_result_upload(※)△△△△△△_congestion_dl_xml(※)△△△△△△_congestion_upload(※)

番号

対象メッセージ
翌日発電・販売計画不整合
通知メッセージ
翌日需要・調達計画不整合
通知メッセージ
E
経過措置計画(不整合通知)
翌日需要抑制計画不整合通知
メッセージ※△△△△△△は以下の通りとする。
計画値同時同量:octow6DocumentType

内容

送信方向

左記メッセージの通知

本機関→小売電気事業者・発電事業者・需要抑制契約者・(一般、特定)送配電事業者

octow6_periodic_plans_dl_xml

表 4-2 発電計画等受領業務関係メッセージに伴う受信確認メッセージ一覧
番号

⑤

⑥

F

G

H

内容

上記①，②，③に対応する
受信確認メッセージ

上記④に対応する受信確認
メッセージ

上記 A，B，Ｃに対応する受信確認メッセージ

上記 D に対応する受信確認
メッセージ

上記 E に対応する受信確認
メッセージ

送信方向
本機関
→小売電気事業者・発電事業者・需要抑制契約者・(特定)送配電事業者
小売電気事業者・(一般)送配電事業者→本機関
本機関→(一般)送配電事業者
本機関→小売電気事業者・発電事業者(一般)送配電事業者→本機関
小売電気事業者・発電事業者・(一般、特定)送配電事業者→本機関(一般)送配電事業者→本機関
小売電気事業者・発電事業者・(一般、特定)送配電事業者→本機関(一般)送配電事業者→本機関
小売電気事業者・発電事業者・需要抑制
契約者・(一般、特定)送配電事業者→本機関※△△△△△△は以下の通りとする。
計画値同時同量:octow6- 30 -

DocumentType△△△△△△_periodic_plans_received(※)△△△△△△_periodic_plans_received(※)△△△△△△_periodic_plans_dl_received(※)△△△△△△_partial_ plans_ received(※)△△△△△△_partial_ plans_ received(※)△△△△△△_periodic_plans_result_dl_received(※)△△△△△△_periodic_plans_result_upload_received(※)△△△△△△_congestion_dl_received(※)△△△△△△_congestion_upload_received(※)△△△△△△_periodic_plans_dl_xml_received(※)

5.業務メッセージの受信確認
5.1 概要発電計画 BP 標準によるメッセージを本規格に定める通信手順により受信した場合で、「3.3.3 業務アプリケーション
層のエラー」に規定するレベルのエラーが無く、業務メッセージを受信した場合は、その結果について、受信確認メッセージとして返信するものとする。
5.2 受信確認メッセージ
本章で規定するメッセージを表 5-1 に示す。

メッセージ名称
受信確認メッセージ

表 5-1 メッセージ一覧
説 明
本規格で規定する通信手順を用いる場合において、受信者が解釈可能な業務処
理メッセージを受信できたか否か送信者に通知するメッセージ

5.3 データ要素
5.3.1 データ属性の表記法
データ属性の表記方法を表 5-2 に示す。

属性

属性表記

半角文字列

X(n)
n:最大文字数

全角文字列

K(n)
n:最大文字数

符号無数値
データ

9(n)
n:整数部桁数
N(n)N(n)V(m)n:整数部桁数
m:小数部桁数

表 5-2 データ属性一覧
説
明
英数字、カナなどの 1 バイト文字で構成される文字列データ要素。
なお、“改行”、“タブ”を含んではならない。また、データ内の XML
予約語(“<”、“>”、“&”、“apos”、“quot”)は、XML の表記に従う。
(例) A+B<C は、A+B&lt;C と表記
カッコ内の文字数に、漢字などの全角文字 1 文字は、2 文字として桁数を表記する。
漢字などの 2 バイト文字で構成される文字列データ要素。
カッコ内の文字数に、漢字などの全角文字 1 文字は、2 文字として桁数を表記する。
「0」～「9」までの数字だけで構成される数値データ要素。

「0」～「9」までの数字、正負符号(「+」及び「-」)及び小数点(「.」)で構成される数値データ要素。
(例) N(10)V(3)→整数部最大桁数 10、小数部最大桁数 3※正負符号及び小数点は桁数に含めない。
「0」～「9」までの数字で構成される年月日データ要素。
年月日
Y(8)
年は、西暦日付で表記する。(YYYYMMDD)(注 1)全角文字と半角文字が混在する場合は、X 属性を用いる。
(注 2)文字コードに UTF-8 を採用しているため、カッコ内の桁数より実際のバイト数が増加する場合がある。
(注 3)小数を扱う場合は、N 属性を用いる。
符号付数値
データ

- 31 -

(注 1)
(注 2)

(注 2)
(注 3)

5.3.2 受信確認メッセージのデータ要素
受信確認メッセージのデータ要素を表 5-3、表 5-4 に示す。
表 5-3 受信確認メッセージのデータ要素
タグ名

データ要素名

JPE55
JPE56
JPE57
JPE58
JPE59
JPE61
JPE62
JPE63
JPE64
JPE65
JPE66
JPE67
JPE68
JPE69
JPE70
JPE71
JPE72
JPE73
JPE74
JPE75

受信したメッセージグ
ループ内のデータ要素の内容を送り返す
エラーフラグ 1
エラーフラグ 2
エラーフラグ 3
エラーフラグ 4
エラーフラグ 5
エラーフラグ 6
エラーフラグ 7
エラーフラグ 8
エラーフラグ 9
エラーフラグ 10
エラーフラグ 11
エラーフラグ 12
エラーフラグ 13
エラーフラグ 14
エラーフラグ 15
エラーフラグ 16
エラーフラグ 17
エラーフラグ 18
エラーフラグ 19
エラーフラグ 20

JPE60

作成日付時刻

JPE51

説明

共通
コード
(注 1)

受信した業務メッセージのメッセージグループ内データ要素について表 5-4 に示す内容のデータをそのまま送り返す。
エラーコードエラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
エラーコード(注 3)
ファイル作成日付時刻
YYMMDDHHMMSS

○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○

使用区分
(注 2)

属性

◎

(表 5-4)

○
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲
▲

X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)
X(2)

○

X(12)

(注 1)○:標準として定める共通コードを示す。コード値については本規格 表 5-5 を参照。
(注 2)◎:必須項目(空欄不可、メッセージを識別するためのキー項目)○:必須項目(空欄不可)▲:任意項目(項目使用、空欄許容)△:任意項目(項目使用如何、空欄許容如何は当事者間で取決め)－:不使用項目(注 3)エラーフラグ 2～20 については、複数エラーが検知された場合に記述する。エラーが無い場合は省略する。エラーフラグの記載順
及び 20 個を超えるエラーを検出した際にどの 20 個のエラーを記述するかについては規定しない。

表 5-4 タグ JPE51 内のデータ要素
タグ名
JPC03
JPC06
JPC09
JPC10
JPC11
JPC12
JPC14
JPC19

データ要素名運用モード
発信者コード受信者コード
BPID機関コード
BPID副機関コード
BPID版
情報区分コード
作成日付時刻

属性
X(1)
X(12)
X(12)
X(4)
X(2)
X(2)
X(4)
X(12)

説明
受信したファイルのメッセージグループヘッダ内容をそのまま返信するため、本規格内では内容について定義しない。
ただし、JPC21(データ要素名:構文規則識別版数)については返信の対象としない。

- 32 -

5.4 共通データコード
共通データコードを表 5-5 に示す。
表 5-5 共通データコード
コード名称

属性

情報区分コード

X(4)

送信者コードX(5)広域的運営推進機関が設定する「事業者コード」を用いる。(注 1)

受信者コードX(5)「送信者コード」と同じコード値を用いる

エラーフラグ 1
(注 2)

X(2)

エラーフラグ 2

X(2)エラーフラグ 3

X(2)エラーフラグ 4

X(2)エラーフラグ 5

X(2)

コード値
9001

意味
受信確認メッセージ

00

エラーなし

01

取り決め以外の情報区分コード(BP で規定された情報区分以外が入力されている等)

04

構文規則識別版数の不正(BP で規定された版数以外が入力されている等)

11

不正データタグ検出(データタグの誤り、BP で登録されていないタグを検出等)

15

データ長が最大値を超えた

17

数値変換のデータ要素の値が数値でない。
(X 要素だが数値以外が入らないところに文字データが入っているものを含む)

20

過大メッセージ長(ファイルサイズが定められたサイズを超過している)

22

負のデータあり(9 型データに負のデータが入力されている)

33

不正文字コードの検出

36

Y 型(日付型)データの不正60

不正なマルチ明細(BP で定義されない明細番号のマルチ明細が入力されている)

61

不正な繰り返し回数(マルチ明細の繰り返し回数が BP の規定と一致していない)

62

不正な XML 構造(XML の構造が BP で定義されたものと異なる)

70

データ整合エラー(ファイル名、メッセージグループヘッダ及びメッセージ内タグの整合)・ファイル名、メッセージグループヘッダ、メッセージ内タグのデータ内容に相違がある。

71

データ整合エラー(BPID 機関、BPID 版)
・BPID 機関コード、副機関コード、BPID 版が正しくないものが記載されている。

72

データ整合エラー(日時)・存在しない日時が指定されている。又は、提出できないタイミングでの計画提出がされている。

73

データ整合エラー(送信者コード/受信者コードエラー)
・存在しない送信者コード、受信者コードが利用されている。
・受信者コードが実際にデータを受信した事業者と異なっている。

74

データ整合エラー(連系線等コード誤り)
・提出先送配電事業者の連系点コードが含まれない、又は事業者コードが異なっている。

75

データ整合エラー(共通コード表以外の値が入力)
・共通コード表に定められた以外の値が入力されている(70～74 でエラーとされるものをのぞく)

78

データ整合エラー(範囲超過)
・数値が入力可能な範囲を超えて入力されている。

79

データ整合エラー(その他)(70～78 以外でデータの整合性にエラーがある場合)

80

ファイル間整合エラー

90

受付不可能な BP の提出(受付期間外、契約未締結 等)

91

必須データ項目未入力
・BP 上入力必須とされたデータ項目が未入力の場合

96

ファイルの中身が存在しない (ファイルサイズ 0)97

ファイル名エラー(XML のファイル名が BP の規格で解釈できない)98

XML の文法エラー(XML の文法エラーによりファイルが解釈できない)

99

その他エラー

エラーフラグ 1 と同じ(ただし‘00’をのぞく)(注 1)(注 1)下記の事業者間において入力する事業者コードは、何れも小売電気事業者等又は発電事業者の事業者コードとする。
・小売電気事業者等又は発電事業者と本機関・本機関と送配電事業者- 33 -

5.5 構文規則
シンタックスルールは、「XML1.0(Ｗ3C 勧告)http://www.w3.org/TR/REC-xml/」を準用する。
5.5.1 交換構造
(1) 論理レコードの種類
XML データを構成する論理レコードを表 5-6 に示す。
表 5-6 論理レコードの種類
論理レコードの種類
1.メッセージグル－プヘッダ－
2.受信確認メッセージ(2) 電文の階層構造
XML 電文の階層構造を図 5-1 に示す。
なお、本規格の受信確認メッセージファイルは、1 つのメッセージグループで構成され、かつ、当該メッセージグル
ープは、1 つのメッセージで構成される。また、マルチ明細、繰返し要素は本受信確認メッセージでは利用しない。
交換単位(メッセージファイル)

XML 宣言メッセージ
グループ

XML 電文
開始タグ

メッセージグループ
メッセージ
開始タグ
グループヘッダ

メッセージ

メッセージ
開始タグ

データ要素

マルチ明細
開始タグ

繰返し
要素

繰り返し要素
開始タグ

XML 電文
終了タグ

メッセージ

メッセージグループ
終了タグ

データ要素

繰返し
要素

データ要素

データ要素開始タグ

マルチ明細

メッセージ
グループ

マルチ明細

データ要素値

データ要素

データ要素終了タグ

図 5-1 XML 電文の階層構造- 34 -

メッセージ
終了タグ

マルチ明細
終了タグ

繰返し要素
終了タグ

5.5.2 XML タグ名称付与規則
本規格 図 5-1 の構成要素とタグ名を表 5-7 に、構成要素の属性を表 5-8 に、本規格における XML 構造の表現
例を図 5-2 に示す。
表 5-7 構成要素とタグ名一覧
タグ名
備 考
SBD-MSGJPMGRP
JPMGH
JPAKM
JPTRM
本規格では使用しない
JPMxxxxx
本規格では使用しない
JPMRxxxxx
本規格では使用しない
JPxxxxx
タグ番号(xxxxx)に“JP”をつけたもの

構成要素
交換単位
メッセージグル－プ
メッセージグル－プヘッダ
受信確認メッセージ
業務メッセージ
マルチ明細
繰返し要素
データ要素

タグ名

SBD-MSGJPMGRP
JPAKM
JPTRM

属性名

桁数

表 5-8 構成要素の属性一覧
説明

BPID
BPIDSUBBPIDVERMSGID
MAPVER
SEQ
SEQ
SEQ

X(4)
X(2)
X(2)
X(4)
X(6)
9(5)
9(5)
9(5)

BPID 機関コ－ド
BPID 副機関コ－ド
適用する各ビジネスプロトコル標準の版
情報区分コ－ドシンタックスルールの版
メッセージグループのシーケンス番号
受信確認メッセージのシーケンス番号
メッセージのシ－ケンス番号

許容値
本規格 表 5-9 参照
本規格 表 5-9 参照
本規格 表 5-9 参照
本規格 表 5-9 参照“1.1-1A”固定
“1”固定
“1”固定
使用しない

XML 宣言<?xml version=“1.0” encoding=“UTF-8”?><!-- ○○○ △△業務ビジネスプロトコル標準 --><SBD-MSG BPID=“xxxx” BPIDSUB=“W3” BPIDVER=“3D” MSGID=“9001” MAPVER=“1.1-1A”><JPMGRP SEQ=“1”><JPMGH>
メッセージグループヘッダ</JPMGH><JPAKM SEQ=“1”><JPE51><JPC03>0</JPC03></JPE51><JPE55>00</JPE55>

交換単位
メッセージグループ
データ
要素

メッセージ

</JPAKM></JPMGRP></SBD-MSG>

図 5-2 本規格における XML 構造の表現例- 35 -（メッセージファイル)5.5.3 メッセージグループヘッダ
メッセージグループヘッダの必須項目に表 5-9 に示す値を設定し、任意項目は省略する。
表 5-9 メッセージグループヘッダのデータ要素
タグ名

データ要素名

属性

JPC03

運用モード

X(1)

JPC06
JPC09

発信者コード受信者コード

X(12)
X(12)

JPC10

BPID 機関コード

X(4)

JPC11

BPID 副機関コード

X(2)

JPC12

BPID 版

X(2)

JPC14

情報区分コード

X(4)

JPC19

作成日付時刻

X(12)

JPC21

構文規則識別版数

X(6)

コード値
説明
1
テストデータ0 or △
通常データ
先頭 5 桁を本機関が設定する「事業者コード(5 桁)」とし、残り 7 桁を“0”とした
12 桁のコードを使用する
FEPC
ビジネスプロトコルを制定した機関名を示す。
OCTO「発電計画等受領業務ビジネスプロトコル標準(計画値同時同量編)」
W6に伴う受信確認メッセージ「需要抑制計画等受領業務ビジネスプロトコル標準」に伴う
W8
受信確認メッセージ
発電計画等受領業務(計画値同時同量編)の版
3Ａ
需要抑制計画等受領業務の版
9001
情報の種類を示す。
メッセージグループの作成日付時刻(YYMMDDHHMMSS)を示す。
(年は西暦の下 2 桁)
1.1-1A
シンタックスルールの版

5.5.4 メッセージを構成するデータ要素における空等の扱い
メッセージを構成するデータ要素は可変長であり、空(入力データがない場合)、文字データにおけるスペース、及び数値データにおけるゼロの扱いについて、以下のとおり規定する。
(1) 空のデータ要素の扱い
空のデータ要素の扱いを表 5-10 に示す。
表 5-10 空のデータ要素の扱い
例

内容

送信側入力値(空)

空の場合は、データ要素を省略する。

データ要素
(省略)

(2) X 属性のデータ要素における半角スペースの扱い
X 属性のデータ要素における半角スペースの扱いを表 5-11 に示す。
表 5-11 X 属性のデータ要素における半角スペース
内容

送信側入力値(1)最も右側にある半角スペース以外の文字よりも更に右側の半角
スペース及び最も左側にある半角スペース以外の文字よりも更に左側の半角スペースを省略する。
(2)すべての桁が半角スペースの場合は、データ要素を省略する。
(注)△は半角スペースを示す。

- 36 -

例(注)
データ要素

△A△

<JPxxxxx>A</JPxxxxx>

△△△

(省略)

(3) 9 属性のデータ要素におけるゼロの扱い
9 属性のデータ要素におけるゼロの扱いを表 5-12 に示す。
表 5-12 9 属性のデータ要素におけるゼロの扱い
内容

送信側入力値(1)最も左側にある 0 以外の数値よりもさらに左側のゼロを省略する。
(2)すべての桁がゼロの場合は“0”とする。

例(注)
データ要素

012

<JPxxxxx>12</JPxxxxx>

000<JPxxxxx>0</JPxxxxx>

5.6 メッセージファイル運用規則
5.6.1 保存期間
受信確認メッセージファイルの保存期間については規定しない。
5.6.2 メッセージファイル名称付与規則
メッセージファイルの名称付与規則を、図 5-3 に示す。なお、拡張子は “.xml”とする。
①受信ファイルが正常に解釈可能な場合。
メッセージファイル名=ACK_受信メッセージファイル名.xml②受信したファイルが解釈不可能な場合。
メッセージファイル名=ERR_受信メッセージファイル名.xml
図 5-3 メッセージファイル名称構成
5.6.3 メッセージの変更・取消の運用
受信確認メッセージについては、変更・取消の方法を規定しない。
5.6.4 メッセージの分割(1)分割されたメッセージを受信した場合は、それぞれに対し受信確認メッセージを作成し返送する。
(2)受信確認メッセージ自身の分割は規定しない。

6.業務アプリケーション連係前エラー
6.1 概要発電計画 BP 標準によるメッセージを本規格に定める通信手順により受信した場合で、「6.3 対象とするエラー」に示
すエラーが発生し、受信確認メッセージとしての返信が出来ない場合、「6.2 エラーメッセージ」に示すエラーメッセージを通信手順により受信確認メッセージに代えて返信する。
6.2 エラーメッセージ
本章で規定するメッセージを表 6-1 に示す。

メッセージ名称
エラーメッセージ

表 6-1 メッセージ一覧
説 明
本規格で規定する通信手順を用いる場合において、受信者が解釈可能な業務処理メッセージ(発電計画 BP 標準に定める標準メッセージ)を受信できなかった場合、送信者に通知するメッセージ- 37 -

6.3 対象とするエラー
受信確認メッセージとしての返信が出来ないエラーとしては主に次のエラーを対象とする。
・ファイルが添付されていない。
・ファイルが圧縮されていない、又は圧縮形式が違うため解読できない。
・展開したファイルにファイルネームが存在しない、又は解読できない。
・XML の文法エラーにより、業務システムでデータが解読できない。(業務メッセージのメッセージグループヘッダが解読できないものも含む)
6.4 メッセージ構造
エラー内容により、次のテキストメッセージ及び文末の改行コードを先頭に含むテキストファイルを作成する。(表 6-2)
改行コード以降は必要により詳細情報を付与することが出来るが、テキストファイルとして表示可能な文字のみ利用可能とし、適切な間隔で改行コードを入れること。
改行コードは CR+LF(16 進 2 バイトで 0x0D0A)とする。
表 6-2 エラーメッセージ一覧
エラー内容

テキストメッセージ
ファイルが添付されていない。
NO_FILE
ファイルが圧縮されていない。又は圧縮形式が違うため解読出来ない。
NO_OR_BAD_COMPRESS_FILE
展開したファイルにファイルネームが存在しない、又は解読出来ない。
NO_OR_BAD_FILENAME
XML の文法エラーにより業務システムでデータが解読出来ない
BAD_XMLその他の致命的なエラー
ANOTHER_FATAL_ERROR(注)本エラーメッセージは例示であり、具体的なエラーをどのように示すか及び詳細情報の記載方法については、当事者間で取り決めることとする。

6.5 メッセージファイル運用規則
6.5.1 保存期間
エラーメッセージの保存期間については規定しない。
6.5.2 メッセージファイル名称付与規則
エラーメッセージの名称付与規則を、図 6-1 に示す。なお、拡張子は“.txt”とする。

メッセージファイル名=FATALERR_タイムスタンプ(注).txt(注)タイムスタンプについては、原則として送信者 SOAP ヘッダ内 Timestamp のデータを利用する。(メッセー
ジを作成した世界協定時(UTC)による日時)
但し形式は YYYYMMDDhhmmss とする。(-と:と T は削除する)
上記データが利用できない場合は、サーバ等のローカルタイム(UTC)を利用する。
その場合の形式は、YYYYMMDDhhmmssLT とする。
図 6-1 エラーメッセージファイル名称付与規則- 38 -

6.5.3 メッセージの変更・取消・分割の運用
本メッセージの変更・取消・分割についてはこれを規定しない。(図 6-2)

クライアント側から 2016/04/01 15:00:00(UTC)のタイムスタンプで提出されたメッセージにファイルが添付されていない場合ファイル名 FATALERR_20160401150000.txt
ファイル内容NO_FILE【CR+LF】(←必須部分)
ファイルがありません【CR+LF】(←任意部分:説明部分)

図 6-2 エラーメッセージの表現例

7.利用文字コ－ド等
7.1 利用文字コード
通信手順、受信確認メッセージともに、使用する文字集合は、JIS-X0201(8 ビット文字)、JIS-X0208(16 ビット文字)とする。受信確認メッセージ、エラーメッセージも含め、通信手順に関する文字コードは、UTF-8(BOM なし)を用いる。
以上- 39 -