4

我正在计划一个 EDI 系统，其中包括发送包含几个元素的 XML 确认消息，但特别是这三个元素；错误代码、错误严重性和错误描述。

我将基本上解析入站 XML 消息，并根据解析的成功或失败包括消息格式、语法、结构、有效性和一些业务规则，我将返回成功或失败确认。

我可以自由选择 ErrorCodes、ErrorSeverity 和 ErrorDescription，但不是天真地从 ErrorCode [1]、ErrorSeverity [Error]、ErrorDescription [Cannot Find Inbound XML File] 开始，并在入站消息的编码过程中添加我认为的错误parser 我想知道是否有选择错误代码和严重性的最佳实践？

我知道 HTTP 错误代码就像 2xx 表示 OK 消息，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

我喜欢将“错误”（输入数据错误）与“致命”（系统损坏）区分开来。第一个要求修复数据并重试；另一个没有。

不言而喻，任何“错误”消息都应该是可操作的；他们应该让接收者清楚地知道什么是错误的，以及需要采取什么措施来纠正数据中的错误。

如果您单独传达严重性，那么我不仅认为没有必要坚持预先定义的数字范围，而且我建议这样的举动是直截了当的。如果您确实认为使用范围有助记符的价值，请使范围至少比您现在认为的需要大十倍（数字很便宜，为什么不使用五个？;-)

你也可以考虑参数化你的消息；例如，明确的字段来指示文本中的位置。这使得代码更容易接收消息并使用它做一些有用的事情（无需解析人类可读的文本来寻找线索）。

于 2009-02-18T12:40:34.063 回答