AWS B2B Data Interchangeが日本で使えそうか考えてみた #AWSreInvent

しばたです。

re:Invent 2023で発表されたマネージドなEDIサービスとなるAWS B2B Data Interchange(以後B2BI)が日本でも使えそうか考えてみました。

https://dev.classmethod.jp/articles/aws-b2b-data-interchange/

本記事を書くにあたりバージニア北部に簡単な環境を作って動作確認をしています。

筆者について

私はクラスメソッドに入社する前にSIerで働いており、スーパーを中心とした小売と卸のEDIに携わった経験があります。
必要最低限の知識は持ち合わせているつもりですが、EDIの歴史、仕組み、業界動向に精通しているわけではありません。
また、残念ながら本記事の主となるANSI X12を取り扱った経験もありません。

本記事の内容はその程度の人間の私見だと予めご承知おきください。

改めて機能概要

最初に改めてB2BIの概要を解説しておきます。

マネージドなEDIサービスという触れ込みのB2BIですが、本日時点ではEDIのうちフォーマット変換に特化した機能を提供しています。

S3の特定のパスにANSI X12で定義されるフォーマットのデータファイルをアップロードするとB2BIがXMLまたはJSONファイルに変換して別のS3バケットに出力するまでがその役割となります。
処理の実行はEventBridgeを使いS3バケット上のオブジェクト作成(Object Created)をトリガーにするのが基本となりますが、APIがあるので任意のタイミングでの実行も可能です。

S3へ入力データをアップロードする部分や出力後データの取り扱い(いわゆる前処理と後処理)は利用者自身で実装する必要があります。

前述のブログやre:Invent 2023のワークショップによれば前処理にTransfer FamilyやAWS CLI、後処理にAmazon AppFlowやAWS Glueを使う例が紹介されていますが、当然他のサービスと組み合わせても構いません。

対応リージョン

本日時点でB2BIが利用可能なリージョンはアメリカの3リージョンとなります。

• バージニア北部 (us-east-1)
• オハイオ (us-east-2)
• オレゴン (us-west-2)

サービスインフラ

サービスのインフラ構成についてはドキュメントに簡単な記述があるだけでした。

• Resilience in AWS B2B Data Interchange

こちらによれば、

AWS B2B Data Interchange supports up to 3 Availability Zones and is backed by an auto scaling, redundant fleet for your connection and transfer requests.

と最大3AZにまたがり「Fleet」と称する処理単位をオートスケーリングで展開しているそうです。
また、

• Availability Zone-level redundancy is built into the service
• There are redundant fleets for each AZ.
• This redundancy is provided automatically

とのことで、実際の実装は不明ですがECS + Fargateの様なイメージで考えておくと良さそうです。
(個人的には「裏でLambdaが動いてるのでは？」って印象を受けてますが...実際のところは謎です)

対応トランザクションセット

B2BIで利用可能なANSI X12のトランザクションセットは以下の様になっていました。
ドキュメントに記述が無かったので実環境でチェックした結果を載せています。

ANSI X12で定義されるすべてのトランザクションセットが使えるわけではなく、そのバージョンも4010、4030、5010の3種となっていました。

• 参考
  • X12 Transaction Sets
  • X12 Release Schedule

また、1トランザクションセット当たりの最大ファイルサイズは5MBとなっています。

• Quotas for AWS B2B Data Interchange

変換処理

ANSI X12からJSON or XMLへの変換処理は「トランスフォーマー」という設定で定義できます。
変換の具体的な流れは以下の通りです。

1. 変換対象となるX12ドキュメントを定義
2. X12 → JSON or XML への変換はAWSが自動で行う
3. AWSが変換したJSON or XMLに対し、利用者がJSONata or XSLTを使い内容を変換する

マネジメントコンソール上は「マッピング」という表記になっていますが「フィルタリング」と言うほうが実体に近いでしょう。

また、最初にAWSが自動で変換を行う際に付けられるJSONのプロパティ名やXMLのタグはAWS独自の模様です。

通信環境と処理手順

EDIといえばファイル交換機能だけでなく通信環境や処理手順も考慮する必要がありますが、AWSを使う以上通信環境としては所謂「インターネットEDI」一択となります。

処理手順についても決まりはなく「何らかの方法でS3にファイルをアップロードすればOK」という形です。
前処理にAWS CLIを使えば「HTTPS」通信と言えるでしょうし、代わりにTransfer Familyを使えば「SFTP」や「AS2」をサポートしてるとも言えます。
B2BIとして特定手順をサポートする事は無く利用者の側で実装が必要な形となります。

私見

ここからサービス仕様と動作確認した結果を踏まえた私見を述べていきます。

サービス全般

まず最初に

• 利用可能リージョンがアメリカのみ
• 変換可能なデータフォーマットはANSI X12の一部のみ

という点から「アメリカ企業向けサービスである。」と断言して良いと思いました。
そして

• 利用可能な機能がデータフォーマット変換のみ
• ANSI X12 → JSON or XMLの片方向の変換のみ可能

という機能に加え、re:Invent 2023でB2BIが発表されたタイミングと同時にAWS Mainframe Modernization関連の新機能も発表されていることから、サービスの建付けも「AWSがフルマネージドでEDIをカバーするためのB2BI」というよりは「Mainframe Modernizationの一環として足りないパーツを補うためのB2BI」という印象です。

将来的にB2BIがどう進化するかは未知数ですが、少なくとも現状においては日本で使えるか以前に「アメリカの特定大型顧客向けのサービスなんだろうな。」というのが率直な気持ちです。

処理の方向

前述の通り「ANSI X12 → JSON or XMLの片方向の変換のみ可能」と片方向であり、逆の「JSON or XML → ANSI X12」への変換はサポートされていません。
ここは本当に「何故？」としか言えず、そうなっている明確な理由を見つけることができませんでした...

一般的にEDIの通信は双方向です。

例えば小売の立場に立って卸へ商品を発注した場合、卸はその発注を受注して小売に出荷、さらに小売は出荷された商品の受領・返品を行い最後に請求まで一連の流れを現物だけではなくデータ上でも繰り返していきます。
前述のX12においても850 : Purchase Order (発注書)に対して応答になる855 : Purchase Order Acknowledgment (発注請書)や856 : Advanced Shipping Notice (事前出荷通知)が定義されています。

X12のデータを送信してくる相手がその応答にX12のデータを期待するのは自然なことでしょう。
いまのB2BIではこの様なケースに対応できず、将来的に対応されるのかこのまま制限事項となるのかは一切不明です。

対応トランザクションセット

B2BIで対応しているトランザクションセットはANSI X12の一部のみであり、詳細は最初に記載した通りです。

私自身X12を実際に扱った事が無いため何故この様な対応状況になっているのかさっぱり分かりませんでした...
特定業種向けという感じでもなさそうですし、汎用的に使われるものだけという感じでも無さそうで、たとえば810 : Invoice (請求書)は非サポートです。

現時点においてはB2BIの採用にあたり必要なトランザクションセットをサポートしているか都度調査する必要があります。

ログとエラーハンドリング

処理のログやエラーハンドリングに関するドキュメントが無かったので動作確認した結果を以下にまとめます。

処理のログはCloudWatch Logsに記録され、

• サービス全体のログ : /aws/vendedlogs/b2bi/default
• 利用者を定義するプロファイルに対するログ : /aws/vendedlogs/b2bi/profile/プロファイルID
• トランスフォーマー毎のログ : /aws/vendedlogs/b2bi/transformer/トランスフォーマー名

の3種類に分けられます。
基本的にはプロファイルに対するログが使われるのですが、特定エラーについてはサービス全体のログにも追加情報が記録される形になっていました。

相手先となる「パートナーシップ」欄で当該パートナーに対するログを抽出して参照できはするのですが、ことエラーメッセージについては検知するのが難しいです。

B2BIを実運用するにはメトリクスフィルターなど別途エラーを検出する仕組みを設けたほうが良さそうです。

ここからは幾つかエラーの実例を紹介します。

1. 空ファイルがアップロードされた場合

S3に空ファイルがアップロードされた場合はエラーとなり出力先には何も生成されません。
サービス全体のログに以下の様なメッセージが残ります。

{
    "eventMessage": "Error in EDI Capability",
    "accountId": "xxxxxxxxxxxx",
    "eventNotes": "File s3://バケット名/ファイル名 has no EDI Transaction Set"
}

2. 矛盾のある内容の場合

定義と異なるトランザクションセットのファイルを投入する、ファイル内のSTヘッダに矛盾する内容を記述した場合もエラーとなり出力先には何も生成されませんでした。

この場合サービス全体のログに

{
    "eventMessage": "Error in EDI Capability",
    "accountId": "xxxxxxxxxxxx",
    "eventNotes": "Error processing request for xxxxxxxxxxxx"
}

{
    "eventMessage": "Error in EDI Capability",
    "accountId": "xxxxxxxxxxxx",
    "eventNotes": "Error attempting to parse file パートナーID/ファイル名 from bucket S3バケット名."
}

プロファイルに対するログに

{
    "eventMessage": "CustomerResponsibleException thrown while executing EDI Capability, see notes for details.",
    "accountId": "xxxxxxxxxxxx",
    "stateStatus": "FAILED",
    "profileId": "プロファイルID",
    "capabilityId": "取引ID",
    "capabilityType": "edi",
    "state": {
        "ediState": "CAPABILITY_MATCHED"
    },
    "tradingPartnerId": "パートナーID",
    "eventNotes": "Error in EDI Capability for: bucket S3バケット名 key パートナーID/ファイル名: Service returned error code InternalFailure (Service: VisbyTransformer, Status Code: 500, Request ID: edcbdd6f-a81e-4ecb-bd5d-ab3af492d961)",
    "transactionId": "s3://バケット名/ファイル名"
}

といった感じの内容が記録されました。

エラーが出ていることは分かるのですが、かなり生な感じであり、もう少し利用者向けのメッセージが欲しいです。
様々な理由により不正なデータが混入してしまうことはよくある話であり、エラー検知のしやすさはEDIにとって重要な要素だと思います。

ちなみに、トランスフォーマー毎のログはAWS CLIから変換を実行した際に記録されました。
AWS CLIで変換処理(aws b2bi start-transformer-job)を実行してエラーになった場合は詳細なメッセージが表示されます。

# SE02 : Set Contorol Numberを不正な値にした場合のエラー
An error occurred (ValidationException) when calling the StartTransformerJob operation: The EDI file could not be parsed. Control number error in SE segment. Expected 5600 instead of 5601 at segment 66, field 3

これくらいのメッセージがCloudWatch Logsにも分かりやすい形で出てほしいところです。

3. ファイル内の文字列長オーバー

X12で定義される文字列長を超える内容のデータを投入した場合はエラーにならずに処理されました。
全項目同様かまではわかりませんが、文字列長のチェックまではしていない様です。

無理やり日本で使えるか？

先に述べた様にB2BIはアメリカ企業向けのサービスですが前処理と後処理であればアメリカ以外のリージョンでも構築可能です。
このため、前処理と後処理を東京リージョンで構築してあたかも日本でB2BIを使えている様に見せることであれば可能でしょう。

B2BIの制限として入力、出力用S3バケットのロケーションは同一リージョンにある必要がありますのでそこだけはご注意ください。

最後に

以上となります。

全体を通してB2BIはアメリカ企業向けという印象を強く受け、また、EDIサービスとしてももう少し機能が欲しい感じです。
「ちょうど今コレが欲しかった！」という方以外はしばらく様子見で構わないと思います。

動作確認自体は非常に簡単にできますので、まずはPoCからはじめて実際のサービスに触れてみることを強くお勧めします。