4

私は、いくつかの要素を含む XML 確認メッセージを送信する EDI システムを計画していますが、具体的にはこれら 3 つです。ErrorCode、ErrorSeverity、および ErrorDescription。

基本的に受信 XML メッセージを解析し、解析の成功または失敗に応じて、メッセージのフォーマット、構文、構造、有効性、およびいくつかのビジネス ルールを含め、成功または失敗の確認応答を返します。

ErrorCodes、ErrorSeverity、ErrorDescription を自由に選択できますが、単純に ErrorCode [1]、ErrorSeverity [Error]、ErrorDescription [Inbound XML ファイルが見つかりません] から始めて、受信メッセージのコーディング中に考えたとおりにエラーを追加するのではなく、エラーコードと重大度を選択するためのベストプラクティスがあるかどうか疑問に思っていましたか?

HTTP エラー コードは、OK メッセージの場合は 2xx、特定のエラーの場合は 4xx、サーバー エラーの場合は 5xx などであることを知っています。私のすべての「警告」エラーは、3 または同様のもので始まりました。

ErrorSeverity は、おそらく [Error]、[Warning]、[Info]、[OK] よりもはるかに大きくなると思いますか?

ありがとう。

4

2 に答える 2

2

EDI の既存のエラー コードは、次の場所にあります。

http://msdn.microsoft.com/en-us/library/bb245948.aspx

これらのドキュメントのいずれかに記載されている標準のいずれかを使用すると、通信するシステム/開発者はおそらく満足するでしょう。

于 2009-02-18T12:34:54.810 に答える
1

「エラー」（入力データに誤りがある）と「致命的」（システムが壊れている）を区別するのが好きです。データを修正して再試行するための最初の呼び出し。もう一方はしません。

言うまでもなく、 「エラー」メッセージはすぐに対処できる必要があります。何が間違っているのか、データの障害を修正するためにどのようなアクションを実行する必要があるのか​​ を正確に受信者に明確にする必要があります。

重大度を個別に伝えている場合は、事前に定義された数値範囲に固執する必要がないだけでなく、そのような動きは拘束力があることをお勧めします. 範囲を使用することにニーモニックな価値があると判断した場合は、範囲を現在必要と考えている範囲の少なくとも 10 倍にしてください (数字は安価です。なぜ 5 を使用しないのですか? ;-)

メッセージのパラメーター化を検討することもできます。たとえば、テキスト内の位置を示す明示的なフィールド。これにより、コードがメッセージを受信し、それに対して何か役に立つことを実行しやすくなります (手がかりを探すために人間が読めるテキストを解析する必要はありません)。

于 2009-02-18T12:40:34.063 に答える