主な機能
- セキュアで信頼性の高いB2B 文書交換
- 署名、暗号化、圧縮を含む完全なセキュリティサポート
- 自動リトライおよび再送を伴う同期および非同期のMDN レシート処理
- ストリーミングおよびリスタート機能による非常に大きなメッセージのサポート
- トレーディングパートナーとの関係に対する包括的な証明書管理
- AS2 信頼性やFDA 拡張のパースなどの高度な機能
- Drummond Group による認定
概要
AS2 接続は2か所で設定します。AS2 プロファイルページで、ローカルAS2 識別子、プライベート証明書、およびすべてのAS2 接続に共通するその他の情報を設定します。次に、個々のAS2 コネクタを、特定のトレーディングパートナーに固有の接続設定で設定します。インプットファイルがAS2 コネクタで処理されると、パッケージ化されて指定されたトレーディングパートナーに送信されます。 がAS2 経由でファイルを受信すると、そのファイルを特定のAS2 コネクタにルーティングしようとします。本アプリケーションはAS2 メッセージ内のAS2 識別子を使用して、どのAS2 コネクタがファイルを受信すべきかを判断します。ファイルがAS2 コネクタにルーティングされると、そのコネクタのトランザクションタブに配置されるか、フロー内の次のコネクタに渡されます。 AS2 コネクタは、AS2 を人気のあるプロトコルにしているすべてのセキュリティおよび信頼性のメカニズムをサポートします。詳細については、AS2 プロトコル交換の説明およびAS2 セキュリティで使用される証明書の説明を参照してください。ビデオ資料
この短いビデオを視聴して、AS2 コネクタを素早くセットアップする方法を学んでください。これは、エンドツーエンドのB2B 統合の各ステップ（マネージドファイル転送（AS2 を例として使用）、バックエンド統合、EDI 変換およびマッピング）を扱う3部構成のビデオシリーズの第1部です。シリーズの他の部分へのリンクは以下のとおりです。- 第2部： におけるバックエンド統合—アプリケーションとデータベース
- 第3部： におけるEDI マッピングと統合
プロファイルの設定
個々のAS2 コネクタとの接続を確立する前に、AS2 プロファイルを設定する必要があります。navbar でプロファイルをクリックします。AS2 プロファイルタブ
Personal Id
ローカルプロファイルを識別するための設定。Personal Certificate
プライベートな復号および署名証明書に関連する設定。Application URLs
パブリックWeb から にアクセスすることに関連する設定および表示される値。Miscellaneous
コネクタの設定
グローバルなAS2 プロファイル設定を行ったら、フローページで各トレーディングパートナー用に個々のAS2 コネクタを作成して設定します。Settings タブ
Trading Partner Info
特定のAS2 トレーディングパートナーを識別して接続するための設定。Connection Info
指定したトレーディングパートナーの接続パラメータに関連する設定。MDN Receipts
AS2 メッセージを送信する際のMDN の要求に関連する設定。Trading Partner Certificates
トレーディングパートナーから提供される公開鍵証明書に関連する設定。Public Profile
トレーディングパートナーがアクセスできるパブリックエンドポイントに公開されるAS2 プロファイル設定の詳細。このエンドポイントはプロファイルページで設定します。Advanced タブ
Very Large Message Support (VLM)
大きなAS2 メッセージの送信をサポートするために使用される設定。すべてのAS2 システムがこの機能をサポートしているわけではありません。
Reliability
AS2 プロトコルのReliability 機能に関連する設定。Alternate Local Profile
この特定のAS2 コネクタに対して、プロファイルページのAS2 設定を上書きする設定。代替のローカルプロファイルを設定すると、特定のトレーディングパートナーに対して異なるローカル証明書や識別子を使用できます。TLS Client Authentication
双方向TLS 認証が必要な場合のクライアント認証に関連する設定。HTTP Authentication
HTTP クライアント認証に関連する設定。Custom Headers
送信メッセージに含めるカスタムヘッダーのセット。Advanced Settings
前述のカテゴリに含まれない設定。Proxy Settings
Message
Logging
Miscellaneous
Automation タブ
Automation Settings
コネクタによるファイルの自動処理に関連する設定。Performance
Alerts タブ
SLAs タブ
接続の確立
トレーディングパートナーは、新しいAS2 コネクタを設定する際に必要となる接続詳細の一部を提供する必要があります。最低限、これらの詳細には次が含まれます：- AS2 Identifier
- Partner URL
- Partner Certificates
AS2 Identifier
トレーディングパートナーは、AS2 トランザクションにおいて自身のAS2 識別子によって識別されます。送信リクエストを送る際には、AS2 識別子がリクエストのヘッダーで受信者を示すために使用されます。 AS2 セルフテストを確立するには、識別子をプロファイルページのAS2 Identifier と同じ値に設定する必要があります。この値は大文字・小文字を区別します。
Partner URL
Partner URL は、トレーディングパートナーがAS2 送信を受信するエンドポイントです。送信AS2 メッセージはこの対象エンドポイントに送信され、これはトレーディングパートナーごとに一意である必要があります。Web ブラウザでPartner URL をテストして、ネットワークや接続の問題を確認できます。 AS2 セルフテストを確立するには、対象URL をプロファイルページのReceiving URL と同一またはほぼ同一にする必要があります。プロファイルページのドメイン名をループバックアドレスlocalhost に置き換えることで、AS2 トランザクションをローカルネットワーク内に保つことができます。ローカルセルフテストURL の例はhttp://localhost:8001/pub/Receive.rsb です。
ドメイン名をlocalhost に置き換えない場合、AS2 メッセージはローカルネットワークの外部にルーティングされます。これを使用して、ネットワーク設定を確認し、メッセージがファイアウォールを通過して に到達できることを確認できます。
トレーディングパートナーは、Receiving URL と非同期MDN 用のURL という複数のURL を提供する場合があります。この場合、設定する必要があるのはReceiving URL（Partner URL）だけです。本アプリケーションは、受信AS2 送信から非同期MDN URL を読み取ることができます。
Partner Certificates
各AS2 コネクタは、対象のトレーディングパートナーの公開鍵証明書を設定する必要があります。トレーディングパートナーは、相手とやり取りされるAS2 メッセージの暗号化と検証に必要な証明書を提供します。 はX.509 公開鍵証明書（.cer、.der、または.pem 拡張子のファイル）を受け入れます。 通常、トレーディングパートナーは単一の証明書を提供し、これはEncryption Certificate フィールドで設定する必要があります。 トレーディングパートナーが複数の証明書を提供する場合は、各証明書の目的を明確にする必要があります。パートナーが（商用の認証局から取得した）完全な証明書チェーンを提供する場合、設定する必要があるのはリーフ証明書（チェーンの最後の証明書）だけです。まれに、パートナーのデジタル署名を検証するために別の公開鍵証明書が必要になる場合があります。この場合、署名検証証明書をAdvanced タブ > Advanced Settings > Partner Signing Certificate で設定します。ファイルの送受信
AS2 プロファイルとパートナー固有のAS2 コネクタを設定したら、ファイルを安全に送受信できます。ファイルの送信
AS2 コネクタでは、トランザクションタブに、対象のトレーディングパートナーに送信されるファイルが表示されます。オートメーションタブで送信オートメーションが有効化されている場合、コネクタのトランザクションタブに到達したファイルは自動的にパッケージ化されて送信されます。送信されたファイルに関連付けられた行を展開することで、すべての送信のログファイルにアクセスできます。 テストファイルを作成ボタンを使用すると、トレーディングパートナーに送信するシンプルな一連のテストファイルを生成できます。再送とリトライ
AS2 再送は、トレーディングパートナーが非同期MDN を返すことが期待されているにもかかわらず、Resend Interval の期間（デフォルトでは60分）内にそれを行わない場合にトリガーされます。本アプリケーションは送信を再送しようとします。本アプリケーションは、MDN が受信されるかMax Attempts (async) が尽きるまでメッセージの再送を続けます。 リトライは、トレーディングパートナーからのHTTP 応答が、サーバーが送信を受信していないことを示す（応答が肯定的な200 OK ステータスでない）場合にトリガーされます。これは、ネットワークや接続の問題を示している可能性があり、多くの場合一時的なものです。本アプリケーションは、送信が受信されるかMax Attempts が尽きるまで、Retry Interval 分ごとに送信を再試行します。ファイルの受信
AS2 コネクタでは、トランザクションタブに、本アプリケーションが受信して（受信AS2 メッセージに含まれるAS2 識別子に基づいて）コネクタにルーティングしたファイルが表示されます。各ファイルの行を展開すると、その送信で利用可能なログのリストが表示されます。 これらのファイルはコネクタのトランザクションタブで利用できます。コネクタがフロー内の他のコネクタに接続されている場合、ファイルはAS2 コネクタのトランザクションタブからフロー内の次のコネクタのトランザクションタブに自動的に移動されます。 AS2 プロトコルは、トレーディングパートナーからファイルを能動的にプルすることを許可しません。AS2 コネクタは、トレーディングパートナーがファイルを送信するのを受動的に待つことしかできません。ファイル受信のトラブルシューティング
AS2 メッセージの受信時に発生する問題は、ファイルの送信時に発生する問題よりも追跡が難しい場合があります。ファイルの_送信_ 中にエラーが発生した場合、そのエラーはAS2 コネクタのトランザクションタブとアクティビティページに即座に報告されます。ファイルを_受信_ する場合、エラーやその他のデバッグ情報は複数の場所に表示される可能性があります。 がAS2 メッセージを受信すると、コネクタに設定されたAS2 Identifier（および受信メッセージに含まれるAS2 識別子）に基づいて、そのメッセージを特定のAS2 コネクタにルーティングしようとします。このルーティング操作が成功するかどうかに応じて、ログ情報を確認できる場所は3つあります：- がメッセージを正常にルーティングできた場合、（このトレーディングパートナー用に設定された）AS2 コネクタのトランザクションタブにエラーログがあります。
- がメッセージを正常にルーティングできなかった場合、アプリケーションログにエラーログがあります。
- AS2 コネクタ_または_ アプリケーションタブのどちらにもログが存在しない場合、AS2 メッセージはそもそも に到達していません。
AS2 交換で行われること
そのアプリケーションの複雑さにもかかわらず、AS2 は2つの基本的な部分に集約されます。文書は、Web のバックボーンとして機能する非常に柔軟なクライアント・サーバープロトコルであるHTTP を介して、AS2 送信者からAS2 受信者に送信されます。受信者は、送信者にレシートを提供することで転送を確認応答します。 次の図は、これらの手順をさらに詳しく示しています。
ステップ1：EDI 文書の準備
テキストファイルからPDF まで、あらゆる種類の文書をAS2 交換で送信できます。ただし、ほとんどのトレーディングパートナーは、特定の文書タイプに対する標準を実装しています。 最も一般的な文書タイプは、電子データ交換（EDI）X12 文書（.x12 または.edi ファイル）、Electronic Data Interchange for Administration, Commerce and Transport（EDIFACT）文書（.edifact ファイル）、またはXML ファイル（.xml ファイル）です。文書の準備は、AS2 通信が始まる前に行われます。 EDI は、トレーディングパートナー間の文書転送と、それに準拠する標準を指す一般的な用語です。これは、EDI over the Internet（EDIINT）とも表されます。ステップ2：AS2 パッケージング
AS2 文書が送信用に準備されます。これは3種類の文書変換から構成されます：- 文書が圧縮可能なデータ（つまり、バイナリデータではない）で構成されている場合、転送されるデータのサイズを削減するために、文書をzlib 圧縮アルゴリズムを使用して_圧縮_ できます。
- データは通常、文書の作成者としての送信者の身元を保証するために、送信者の秘密鍵を使用して_署名_ されます（通常はSHA-1 署名アルゴリズムを使用）。
- 最後に、トレーディングパートナーだけがデータを読み取れるように、受信者の公開鍵を使用してデータを_暗号化_ できます（通常は3DES 暗号化アルゴリズムを使用）。HTTPS などのセキュアな転送メカニズムでデータが配信される場合、このステップはスキップできます。
ステップ3：HTTP/S 配信
準備された文書は、インターネット経由でHTTP またはHTTPS プロトコルを使用してトレーディングパートナーのWeb サーバーに配信されます。ステップ4：AS2 アンパッケージング
準備された文書の受信者は、それをアンパッケージしてEDI 文書を取得します。データが暗号化されている場合、準備された文書は受信者の秘密鍵を使用して_復号_ されます。データが署名されている場合、文書の署名は送信者の身元を保証するために送信者の公開鍵を使用して_検証_ されます。文書が圧縮されている場合、準備された文書は_解凍_ されて元のEDI 文書が生成されます。ステップ5：EDI 処理
AS2 受信者は、アンパッケージされたEDI 文書を、追加のビジネスロジックを実行するためにデータを処理するバックエンドプロセスに渡します。EDI 文書がパースされ、受信者は送信者と受信者の役割が逆転した新しいAS2 トランザクションを開始する場合があります。特にEDI-X12 文書では、元のEDI 文書がバックエンドのビジネスロジックで処理されたことを示すために、997 機能確認応答が元の送信者に送信されることがよくあります。ステップ6：MDN 応答
受信者は、通常は受信者の秘密鍵で_署名_ されたMDN を送信者に送信します。MDN は、AS2 交換で返されるレシートであり、何が受信され、それが正常に受信されたかどうかを送信者に報告するために使用されます。 MDN には、文書が正常にアンパッケージされたかどうかに関する情報と、受信したペイロードに対して計算されたメッセージダイジェストが含まれます。MDN は、送信者がMDN の配信をどのように要求したかに応じて、2つの方法のいずれかで送信者に返されます。同期 トランザクションでは、受信者は受信者のWeb サーバーからのHTTP 応答でMDN を返します。非同期 トランザクションでは、HTTP 応答にはシンプルな確認応答（200 OK）が含まれ、MDN は別の接続で返されます（これは通常、AS2 送信のアンパッケージに時間がかかると予想される場合です）。ステップ7：MDN 処理
送信者が受信者からMDN を受信すると、MDN が署名されている場合はMDN 署名が_検証_ されます。MDN のステータスがチェックされ、受信者がトランザクションの処理に成功したか、MDN で報告されたエラーが発生したかが確認されます。最後に、MDN で報告されたメッセージダイジェストが、送信されたEDI データに対して計算されたメッセージダイジェストと照合されます。署名されたMDN を使用すると、送信者は、メッセージの受信者がEDI 文書の内容全体を意図したとおりに受信したことを検証できます。証明書
AS2 コネクタは、プライベートと公開の両方の鍵証明書を使用します。秘密鍵証明書
AS2 コネクタでは、PKCS#12 形式（.pfx ファイルまたは.p12 ファイル）の証明書を指定できます。秘密鍵証明書は、秘密鍵の保持者だけが実行できるべき2つの操作を実行するために使用されます：- 身元の証明を提供するためのデータの_署名_
- 自分宛てのデータの_復号_
公開鍵証明書
公開鍵証明書は、トレーディングパートナーから提供されます。AS2 コネクタでは、X.509 形式（.cer または.der ファイル）の公開鍵証明書を指定できます。公開鍵証明書は、秘密鍵を必要とする操作と逆の働きをするために使用されます。これらの操作には次が含まれます：- トレーディングパートナーが作成した署名の_検証_
- トレーディングパートナーだけがデータを読み取れるようにするためのデータの_暗号化_
マクロ
例
よくあるエラー
以下は、よくあるエラー、その原因、および推奨される解決策のリストです。詳細については、arcsupport@cdata.com にお問い合わせください。エラー：The receipt signature could not be verified: Message digest mismatch in signature
原因 MDN レシート署名には、メッセージの内容が転送中に変更されていないことを保証するメッセージダイジェストが含まれます。ダイジェストの不一致は、MDN が受信前に変更されたか、パートナー側で適切に生成されなかったことを示唆している可能性があります。 このエラーは、アンチウイルスソフトウェアやファイルセキュリティソフトウェアがMDN 応答の一部を不適切に除去することによって発生する場合があります。ESET のApplication Protocol Filtering 機能には、空白の削除によって折り返されたMDN ヘッダーが無効になる可能性がある既知の問題があります。 解決策 パートナーから返されたMDN に明らかな問題がないか確認します。このエラーがスローされたトランザクションの.mdn ファイルをダウンロードし、問題の説明とともにarcsupport@cdata.com に送信するか、独自に調査してください。 トレーディングパートナーに連絡して、使用しているAS2 ソリューションを確認することも役立つ場合があります。 は、Drummond 認定のあらゆるAS2 ソリューションと相互運用可能です。エラー：The receipt signature could not be verified: The certificate specified does not match the signature
原因 MDN レシートは秘密鍵で署名され、この署名は対応する公開鍵で検証されます。このエラーは、このパートナーからの署名を検証するために設定された公開鍵が正しくないことを示唆しています。 解決策 多くの場合、暗号化に使用される同じ公開鍵証明書が署名の検証にも使用されます。この場合、AS2 コネクタのSettings > Encryption Certificate で設定された証明書を確認し、このトレーディングパートナーに対して正しく設定されていることを確認します。 トレーディングパートナーが署名に別の証明書を使用する場合もあります。この場合、Advanced > Partner Signing Certificate 設定を、パートナーの署名鍵に一致する公開鍵証明書に設定します。エラー：The receipt signature could not be verified: Message digest was encrypted with unknown algorithm
原因 これは、SMIME 暗号化v3.1 のみをサポートしていた古いバージョンのアプリケーションにおける既知の問題です。MDN にSMIME 3.2 で暗号化されたメッセージダイジェストが含まれている場合、このエラーがスローされます。 解決策 v2016 の最終公開ビルドを含む、 のすべての現行バージョンはSMIME 3.2 をサポートしています。古いバージョンでは、このエラーを解決するためにアップグレードが必要です。エラー：MDN Error
Authentication failed または Signature Authentication failed: Could not authenticate signer’s identity 原因 このエラーはMDN 応答の一部として含まれ、トレーディングパートナーがAS2 リクエストの署名を検証できなかったことを示します。これは、トレーディング当事者間の一般的な証明書の不一致を示唆しています。 解決策 のAS2 プロファイルに設定されたプライベート証明書が正しいこと、およびトレーディングパートナーが一致する公開鍵証明書を自身の側で設定していることを確認します。エラー：MDN Error: Unexpected processing error
原因 このエラーはトレーディングパートナーのシステムによってスローされ、AS2 リクエストの処理失敗を示すためにMDN の一部として返されます。これは、問題が署名、暗号化、または圧縮に関連していない場合にスローされる一般的なエラーです。 解決策 このエラーには具体的なデバッグ情報が含まれていないため、トレーディングパートナーに連絡して、失敗の原因に関する詳細情報を求めてください。エラー：System error: Connection refused
原因 このネットワークエラーは、一般的な接続の問題を示します。これは、能動的にリッスンしていないサーバーへの接続試行が行われた場合にスローされます。これは、サーバーがダウンしているか、誤ったURL に接続試行が行われていることを示している可能性があります。 解決策 対象URL が正しいことを確認します。エラーが続く場合は、対象システムのサーバー管理者に連絡して、サーバーがダウンしているかどうか、または問題に関する詳細情報があるかどうかを確認します。エラー：Connection failed
A connection attempt failed because the connected party did not properly respond after a period of time または Connection timed out 原因 このネットワークエラーは、一般的な接続の問題を示します。これは、サーバーへの接続試行が一定時間（通常は60秒）応答されない場合にスローされます。これは、サーバーの応答に対するファイアウォールの干渉の結果であることが多いですが、誤った接続パラメータを示している可能性もあります。 解決策 ファイアウォールがサーバーの応答が返されるのを妨げていないことを確認します。サーバーもファイアウォールの背後にある場合は、AS2 メッセージの送信元IP がサーバーのファイアウォールでホワイトリストに登録されていることを確認します。 ファイアウォールが除外された場合は、対象URL が正しいことを確認します。エラー：Synchronous MDN expected but not received
原因 これは、AS2 リクエストへの応答がMDN ではなかったことを示す一般的なエラーです。これは、AS2 リクエストが期待どおりにAS2 サーバーに送信されなかったことを示している可能性があります。このエラーは、MDN が返されたものの、 がそれをMDN として適切に認識できないほど破損していた場合にもスローされることがあります。 解決策 対象URL が正しいことを確認します。次に、ファイアウォールがMDN から内容を除去し、 が正しくパースできなくなっていないかを確認します。MDN の問題が不明な場合は、失敗したトランザクションに関連付けられた.mdn ファイルを見つけ、問題の説明とともにarcsupport@cdata.com に提供してください。エラー：Unsigned MDN received, but signed MDN requested
原因 このエラーは、トレーディングパートナーからの応答が署名されたMDN レシートであると期待されているにもかかわらず、代わりに何か他の内容である場合にスローされます。これは、署名されていないMDN レシートか、まったくMDN ではない応答である可能性があります。 解決策 失敗したトランザクションのMDN ログファイルの内容を確認します。このファイルには、署名されていないMDN かMDN 以外の応答かにかかわらず、サーバーの応答が含まれます。MDN ログファイルの内容が次のステップを示します。サーバーの応答がまったくMDN でない場合、エラーが含まれているか、AS2 リクエストの送信先のエンドポイントがAS2 受信エンドポイントではないことを示している可能性があります。MDN ログファイルに署名されていないMDN が含まれている場合、これはトレーディングパートナーのシステムの設定の問題を示します。エラー：Unable to find valid certification path to requested target
原因 このエラーは、Java 版で基底のJava セキュリティプロバイダーによってスローされます。これは、対象のWeb サーバーが提示したSSL サーバー証明書がシステムによって信頼されていないことを示します。 解決策 TLS サーバー証明書の信頼は、AS2 コネクタでTrading Partner Certificates > TLS Server Certificate 設定をサーバーの公開鍵証明書またはAny Certificate に設定することで上書きできます。サーバー証明書は、ほとんどのWeb ブラウザを通じてWeb サーバーに接続することで取得できます。
エラー：Key does not exist
原因 これは、複数のスレッドが同じ秘密鍵にアクセスしようとした場合のWindows CryptoAPI における既知の問題です。デフォルトでは、 はプライベート証明書の読み込みなどのセキュリティ操作を実行するためにWindows CryptoAPI を使用します。 解決策 には暗号操作の内部実装が付属しており、このマネージド実装を有効化することでWindows CryptoAPI の制限を回避できます。 のインストールディレクトリのdata フォルダに移動し、該当するAS2 コネクタのフォルダを見つけて、port.cfg をテキストエディタで開きます。証明書の読み込み時にマネージドセキュリティ実装を有効化するために、次の行が存在することを確認します：
エラー：Input string was not in a correct format
原因 これは、AS2 コネクタ設定の何らかの側面で文字列検証が失敗したことを示します。通常は、Receiving URL 設定またはEvents スクリプトでの何らかの文字列処理がエラーの原因です。 解決策 Receiving URL の対象URL が有効なHTTP プレフィックス（平文接続の場合はhttp://、SSL 接続の場合はhttps://）で始まり、意図しない空白を含んでいないことを確認します。
コネクタのEvents にスクリプトが存在する場合（例：BeforeSend またはAfterReceive）、無効な文字列処理が行われていないことを確認します。スクリプトが問題の原因であるかどうかを確認するには、arcsupport@cdata.com にお問い合わせください。
エラー：500 Internal Server Error
原因 このHTTP エラーは、一般的なサーバー側の障害を示します。AS2 メッセージは正常に受信されましたが、メッセージの処理時にエラーが発生し、それ以上のデバッグ情報は利用できません。 解決策 この問題に関連する可能性のある唯一のクライアント側の設定は対象URL です。これが正しい場合は、サーバー側のログを参照して、処理失敗の原因について詳しく確認します。これらのサーバーログが利用可能かどうかをトレーディングパートナーに相談してください。エラー：404 Not Found
原因 このHTTP エラーは、対象URL にリソースが見つからなかったことを示します。これは通常、URL の前半（ホスト、ポート）は正しいものの、URL の後半（リソースパス）が認識されないことを示します。 解決策 対象URL のリソースパスが正しいことを確認します。期待されるリソースパスをトレーディングパートナーに確認してください。エラー：401 Unauthorized
原因 このHTTP エラーは、指定されたURL に到達するために認証が必要であることを示します。これは、TLS クライアント認証またはHTTP 認証の場合があります。 解決策 TLS クライアント認証が必要な場合は、コネクタ設定のAdvanced > TLS Client Authentication セクションで適切な証明書を設定します。HTTP 認証が必要な場合は、Advanced > HTTP Authentication で適切な資格情報を設定します。 HTTP 認証が必要かどうかを確認するには、Web ブラウザで対象URL への接続をテストし、ユーザー / パスワード資格情報の入力を求めるプロンプトが表示されないか確認します。エラー：Incoming request did not match a configured trading partner profile
原因 AS2 メッセージが によって受信されると、本アプリケーションは設定されたAS2 識別子に基づいて、メッセージを特定のAS2 コネクタにルーティングしようとします。このエラーは、送信者と受信者のAS2 識別子がAS2 メッセージに含まれる値と一致するコネクタが見つからなかったことを示します。 解決策 AS2 プロファイルページと、このエラーの影響を受ける特定のトレーディングパートナー用に設定されたAS2 コネクタの両方で、設定されたAS2 識別子を確認します。エラー：Error during handshake: The token supplied to the function is invalid
原因 これは、WinSock ライブラリ（Windows Sockets）によって返されるいくつかのSSL エラーの1つです。このエラーは、HTTPS 接続を期待するサーバーに対してHTTP 接続が試行された場合によく発生します。 解決策 AS2 接続がHTTP とHTTPS のどちらであるべきかをトレーディングパートナーに確認し、対象URL に適切なプレフィックスとポートがあることを確認します。エラー：Error during handshake: the buffer supplied to a function was too small
原因 これは、システムのWinSock ライブラリによって返されるいくつかのSSL エラーの1つで、特定のサーバーOS におけるWindows CryptoAPI の既知のバグです。この問題は、TLS 1.2 と次の2つの特定の暗号スイートを使用する場合に発生します：TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
data フォルダに移動し、profile.cfg ファイルをテキストエディタで開きます。[Application] セクションの下に次の行が存在することを確認します：