Допустимые значения атрибута CompletionCode
Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode для доставки. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| BackOrdered | Back Ordered. Товары, подлежащие доставке, ожидают длставки, но еще не доставлены. Доставка будет оформлена, когда товар будет получен. Это справедливо, если ProcessState = CompletedOk. Восстановление невозможно. |
| PermNotAvail | Постоянно не доступен (Permanently Not Available). Товары не доступны и не могут быть перезаказаны. Это справедливо, если ProcessState = Failed. Восстановление не возможно. |
| TempNotAvail | Временно не доступен. Товары временно не доступны и могут быть получены при повторном заказе. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| ShipPending | Задержка доставки. Товары доступны и запланированы к доставке, но еще не доставлены. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| Shipped | Товары доставлены (Goods Shipped). Товар уже доставлен. Ожидается подтверждение доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| ShippedNoConf | Доставлен – никакого подтверждения доставки (Shipped - No Delivery Confirmation). Товары были доставлены, но их доставку невозможно подтвердить. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| ConsCancelled | Аннулировано Покупателем (Consumer Cancelled). Покупатель по какой-то причине решает аннулировать доставку. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| DelivCancelled | Доставка аннулирована (Delivery Cancelled). Агент доставки по какой-то причине отказался завершить процедуру доставки и аннулировал транзакцию. Этот код допустим только в компоненте Status, содержащимся в блоках Cancel или информационного отклика. Восстановление невозможно. |
| Confirmed | Подтверждено (Confirmed). Все товары были доставлены и получено подтверждение их доставки. Это возможно, если ProcessState = CompletedOk. Восстановление невозможно. |
| Unspecified | Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Атрибут StatusDesc должен прояснить причину. Восстановление невозможно. |
| TimedOutRcvr | Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь. |
| TimedOutNoRcvr | Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| InMsgHardError | Серьезная ошибка во взодном сообщении (Input Message Hard Error). Тип блока запроса не может быть идентифицирован или является несовместимым. Следовательно никакой однодокументный обмен не может быть идентифицирован. Это может вызвать серьезную ошибку в транзакции. |
7.16.6. Коды завершения информационного запроса транзакции
Код завершения требуется только тогда, когда атрибут ProcessState = Failed.
Таблица, представленная ниже, содержит допустимые значения атрибута CompletionCode, которые могут быть использованы. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| UnAuthReq | Неавторизованный запрос (Unauthorised Request). Получатель запроса состояния транзакции отказывается откликаться на запрос. |
7.17. Компонент данных торговой роли
Компонент данных торговой роли содержит данные, которые должны быть пересланы между торговыми ролями вовлеченными в транзакцию.
Компоненты торговой роли определяют:
o организацию, которая сформировала компонент и
o организацию, которая его получила.
Они являются первыми сформированными и включенными в блок “отклик” и затем скопированных в соответствующий блок “запрос”. Например, кассиру может оказаться нужно проинформировать агента доставки о том, что платеж через кредитную карточку авторизован (but not captured). В другом примере продавцу может понадобиться предоставить кассиру некоторую специфическую информацию о Покупателе.
Его определение представлено ниже.
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIREDDestinationElRefs NMTOKENS #REQUIRED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент данных торговой роли транзакции IOTP. |
| OrginatorElRef | Содержит ссылку элемента на компонент Organisation организации, которая создала компонент данных о торговой роли и включила его в блок отклика (напр., блок отклика предложения или платежа). |
| DestinationElRefs | Содержит ссылку элемента на компоненты Organisation организации, которая получила компонент данных о торговой роли в блоке запроса (напр., блоков запроса платежа или доставки). |
Cодержимое:
| PackagedContent | Содержит данные, которыые должны быть пересланы между торговыми ролями в виде одного или нескольких элементов PackagedContent, смотри раздел 3.7. |
7.17.1. Кто получает компонент данных о торговой роли
Восстановление при неудаче или в случае частично завершенной доствки невозможно. Покупатель для получения текущего состояния транзакции должен использовать информационный запрос (смотри раздел 9.2.1).
7.16.4. Коды завершения аутентификации
Код завершения необходим только в случае, если атрибут ProcessState = Failed. Ниже следующая таблица содержит допустимые значения атрибута CompletionCode, которые можно использовать. Рекомендуется, чтобы для разъяснения ситуации использовался атрибут StatusDesc.
| Значение | Описание |
| AutEeCancel | Аннулировано аутентифицируемым (Authenticatee Cancel). Организация по какой-то причине отказывается от аутентификации. Это может быть, например, потому что подпись аутентификационного запроса оказалась некорректной или аутентификатор оказался неизвестным или неприемлемым. Восстановление невозможно. |
| AutOrCancel | Аннулировано аутентификатором (Authenticator Cancel). Организация, запросившая аутентификацию по каким-то причинам отказывается проверять полученный аутентификационный отклик и аннулирует транзакцию. Восстановление невозможно. |
| NoAuthReq | Запрос аутентификации не возможен (Authentication Request Not Available). Аутентифицирующийся субъект не имеет данных, которые должны быть предоставлены. Например, забыт пароль или субъект не авторизован. Восстановление невозможно. |
| AuthFailed | Аутентификация не прошла (Authentication Failed). Аутентификатор проверил аутентификационный отклик, но эта проверка по какой-то причине не прошла. Например, оказался неправильным пароль. Восстановление может быть возможно аутентифицируемым путем повторной посылки отклика аутентификации с корректными данными. |
| TradRolesIncon | Торговые роли несоместимы (Trading Roles Inconsisten). Торговые роли, содержащиеся в атрибуте TradingRoleList компонента информационного запроса торговых ролей (смотри раздел 7.4) не согласуются с торговой ролью, которую аутентифицируемый играет в данной транзакции IOTP. Примеры несогласованности включают в себя: о запрос Кассира информации об Агенте доставки; о запрос Покупателя информации о Продавце. Восстановление может выполнить аутентификатор путем повторной посылки блока аутентификационного запроса с поправленной информацией. |
| Unspecified | Неспецифицированная ошибка (Unspecified error). Имеет место какая-то неизвестная проблема или ошибка, которая не совпадает ни с одним из кодов CompletionCodes. Восстановление невозможно. |
| TimedOutRcvr | Восстановимый таймаут (Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление возможно, если последнее сообщение от другой торговой роли получено вновь. |
| TimedOutNoRcvr | Невосстановимый таймаут (Non Recoverable Time Out). Сообщения были повторно посланы, но отклика не получено. Документальный обмен прерван по таймауту. Этот код приемлем при транзакции информационного запроса. Восстановление невозможно. |
Код завершения требуется только тогда, когда атрибут ProcessState = Failed.
Ниже описаны правила, которые определяют, что следует делать с компонентами данных торговой роли.
- Когда бы ни был получен компонент данных торговой роли в блоке "Отклик", идентифицировать компоненты Organisation, которые должны получить его, как идентифицированные атрибутом DestinationElRefs.
- Когда бы ни был послан блок "Запрос", проверить, был ли он послан одной из организаций (адресат), идентифицированной атрибутом. Если это так, включить в блок "Запрос" следующее:
| - компонент данных о торговой роли, а также, | |
| - компонент Organisation, идентифицированной атрибутом OriginatorElRef. |
Компонент типа информационного запроса содержит информацию, которая указывает тип процесса, о котором получен запрос. Его определение представлено ниже.
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType ID ID #REQUIREDType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIEDProcessReference CDATA #IMPLIED>
Атрибуты:
| ID | Идентификатор, который однозначно определяет компонент типа информационного запроса транзакции IOTP. |
| Type | Содержит тип информационного запроса. Допустимые значения типа запроса: o Offer. Запрос касается статуса предложения и обращен к продавцу. o Payment. Запрос касается статуса платежа и обращен к кассиру. o Delivery. Запрос касается статуса доставки и обращен к агенту доставки. |
| ElRef | Содержит ссылку элемента (смотри раздел 3.5) на компонент, к которому относится информационный запрос. Это: о Блок TPO, когда тип = Offer; o Компонент Payment, когда тип = Payment; o Компонент Delivery, когда тип = Delivery. |
| ProcessReference | Опционно содержит ссылку на процесс, о котором произведен запрос. Он должен быть установлен, если информация доступна. Для определения значений, которые он может принимать, смотри атрибут ProcessReference компонента Status (смотри раздел 7.16). |
Определения структур XML для подписей и сертификатов описаны в документе "Digital Signatures for the Internet Open Trading Protocol" Kent Davidson и Yoshiaki Kawatsura, опубликованном одновременно с этим документом - смотри [IOTPDSIG].
В будущем ожидается, что новые версии IOTP зафиксируют какой-то метод цифровой подписи XML в к ачестве стандарта.
Каждый компонент подписи цифровым образом подтвержжает один или более блоков или компонентов, включая компоненты подписи.
Компонент подпись:
- содержит дайджесты одного или более блоков или компонентов в одном или нескольких IOTP-сообщениях в пределах одной транзакции IOTP и помещает результат в элемент Digest;
- объединяет элементы дайджестов с другой информацией о типе подписи, об отправителе и потенциальных получателях, а также об используемом алгоритме подписи, и помещает их в элемент Manifest,
- подписывает элемент Manifest, используя опционный сертификат, идентифицированный в компоненте Certificate блока Signature, помещая результат в элемент Value комполнента Signature.
- Подпись отклика предложения,
- Подпись отклика платежа,
- Подпись отклика доставки, или
- Подпись отклика аутентификации.
7.19.1. Использование элементов подписи и атрибутов IOTP
Определения элементов и атрибутов содержится в [IOTPDSIG]. Ниже представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.
Элемент SIGNATURE
ID-атрибут является обязательным.
Элемент MANIFEST
Опционный атрибут LocatorHrefBase содержит текст, который должен быть включен до текста, содержащегося в атрибуте LocatorHREF всех элементов Digest в пределах элемента Manifest.
Целью элемента Manifest является сокращение значения атрибута LocatorHREF, так как первая часть атрибутов LocatorHREF в подписи идентична.
Обычно в IOTP он будет содержать все символы атрибута LocatorHref вплоть до ("#") (смотри текст ниже).
Элементы ALGORITHM и PARAMETER
Элемент algorithm идентифицирует алгоритмы, использованные при формировании подписи. Тип алгоритма определяется значением алгоритма Type, который указывает, следует ли его использовать в качестве Digest-алгоритма, алгоритма подписи или алгоритма Key Agreement.
Следует использовать следующие алгоритмы дайджестов:
- алгоритм [DOM-HASH]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:dom-hash";
- алгоритм [SHA1]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:fips:sha1" и
- алгоритм [MD5]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:md5".
- Следует применять следующие алгоритмы подписи:
- алгоритм [DSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:us.gov:dsa"
- алгоритм [HMAC]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:ibm:hmac"
- алгоритм [RSA]. Идентифицируется путем установки атрибута Name элемента Algorithm равным "urn:rsa:rsa"
Один алгоритм может использовать другие алгоритмы через посредство элемента Parameter, например:
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1"> </Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
Элемент DIGEST
Атрибут LocatorHREF идентифицирует элемент IOTP, который подписан цифровым образом. Он состоит из:
- значения ID-атрибута IotpTrans ID-компонента транзакции, за которым следует:
- символ "#", за которым следует
- ссылка элемента (смотри раздел 3.5) на элемент транзакции IOTP, который является субъектом дайджеста.
Элемен атрибут
Должен существовать один и только один элемент атрибута, который содержит атрибут Type со значением типа подписи и содержимым равным одному из: OfferResponse, PaymentResponse, DeliveryResponse, AuthenticationRequest, AuthenticationResponse, PingRequest или PingResponse; в зависимости от типа подписи.
Значения содержимого элемента атрибута управляются процедурой, определенной в разделе 12 (IANA), и допускающей определение значений пользователем.
Атрибут Critical должен быть установлен равным true.
Элемент ORIGINATORINFO
Атрибут OriginatorRef элемента OriginatorInfo должен всегда присутствовать и содержать ссылку элемента (смотри раздел 3.5) на компонент Organisation организации, которая сформировала компонент Signature.
Элемент RECIPIENTINFO
Атрибут RecipientRefs содержит список ссылок (смотри раздел 3.5), указывающих на организации, которые должны будут проверить подлинность подписи.
7.19.2. Компонент подписи отклика предложения
Элемент Manifest подписи, который имеет тип OfferResponse должен содержать элементы дайджеста для следующих компонентов:
- Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, которое содержит подпись отклика предложения;
- Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, которое содержит подпись отклика предложения
- из блока TPO:
| компонент опций протокола; | |
| каждый из компонентов Organisation; | |
| каждый из компонентов списка видов платежа; |
- опционно, все компоненты выбора вида платежа, если они посланы Продавцу в блоке выбора TPO;
- из блока отклика предложения:
| компонент Order; | |
| каждый из компонентов Payment; | |
| компонент Delivery; | |
| каждый из компонентов запроса аутентификации; | |
| любой компонент данных о торговой роли. |
- если продавец получил блок выбора TPO, содержащий компоненты выбора вида платежа, тогда генерируется элемент дайджеста для кассира, идентифицированного компонентом выбора вида платежа, и для агента доставки, идентифицированного компонентом Delivery.
Смотри раздел 6.3.1. - если Продавец не ожидает получить блок выбора TPO, тогда ренерируется элемент дайджеста для Агента доставки и всех Кассиров, вовлеченных в сделку.
Элемент Manifest компонента подписи платежной расписки должен содержать элеиенты Digest для следующих компонентов:
- Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись платежной расписки;
- Блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись платежной расписки;
- компонент подписи отклика предложения;
- компонент платежной расписки;
- компонент Payment Note;
- компонент Status;
- компонент выбора вида платежа;
- любой компонент данных о торговой роли.
Элемент Manifest компонента отклика доставки должен содержать элементы Digest для следующих компоентов:
- Id-компонент транзакции (смотри раздел 3.3.1) сообщения IOTP, который содержит подпись отклика доставки;
- блок ссылки транзакции (смотри раздел 3.3) сообщения IOTP, который содержит подпись отклика доставки;
- компонент данных доставки покупателя, содержащихся в предыдущем запросе доставки (если имется);
- компоненты Signature, содержащиеся в предыдущем запросе доставки (если имется);
- компонент Status;
- компонент Delivery Note.
Элемент Manifest компонента подписи запроса аутентификации должен содержать элементы Digest для следующих компонентов:
- блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, которая описывает сообщение и транзакцию IOTP;
- Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
- следующие компоненты блока TPO:
| - компонент опций протоколов; | |
| - компонент Organisation. |
- следующие компоненты блока запроса аутентификации:
| - компоненты запроса аутентификации (если имеются) | |
| - компонент запроса информации о торговой роли (если имеется) |
Компонент подписи отклика аутентификации
Элемент Manifest компонента подписи отклика аутентификации должен содержать элементы Digest для следующих компонентов:
- блок ссылки транзакции (смотри раздел 3.3) для сообщения IOTP, который содержит информацию, описывающую сообщение и транзакцию IOTP;
- Id-компонент транзакции (смотри раздел 3.3.1), который однозначно идентифицирует транзакцию IOTP;
- следующие компоненты блока запроса аутентификации:
| - компонент запроса аутентификации, который был использован в аутентификации (если имеется); | |
| - компонент информационного запроса о торговой роли (если имеются). |
- компоненты Organisation, содержащиеся в блоке отклика аутентификации.
Если информационный запрос подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest компонента типа информационного запроса и, если присутствует, компонент схемы платежа.
7.19.8. Компонент подписи
Если информационный отклик подписан (смотри раздел 9.2.1) элемент Manifest компонента подписи информационного запроса должен содержать элементы Digest блока торгового отклика и компонент Status.
7.19.9. Компонент подписи запроса Ping
Если запрос Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.
7.19.10. Компонент подписи отклика Ping
Если отклик Ping подписан (смотри раздел 9.2.2), элемент Manifest компонента подписи запроса Ping должен содержать элементы Digest для всех компонентов Organisation.
7.20. Компонент Certificate
Определения структур XML для подписей и сертификатов описаны в работе "Digital Signatures for the Internet Open Trading Protocol", смотри [IOTPDSIG]. Смотри также начало раздела 7.19.
Компонент Certificate содержит цифровой сертификат. Они используются только, когда, например, использована асиметричная криптография и верифицирующий получатель подписи не получил еще общедоступного ключа (Public Key).
Структура сертификата определена в [IOTPDSIG].
7.20.1. Использование в IOTP атрибутов и элементов подписи
Подробные определения упомянутых выше элементов и атрибутов содержатся в [IOTPDSIG]. Далее представлена дополнительная информация, которая описывает, как эти элементы и атрибуты используются в IOTP.
Компонент CERTIFICATE
ID-атрибут является обязательным.
Элемент VALUE
ID-атрибут является обязательным.
7.21. Компонент Error
Компонент Error содержит информацию о технических ошибках (смотри раздел 4.1) в сообщении IOTP, которое было получено одной из торговых ролей, вовлеченных в сделку. Для ясности ниже приведены две фразы, которые определяют использование компонента Error:
- сообщение сопряжено с ошибкой. Сообщение IOTP, которое содержит или вызывает ошибку какого-то вида;
- сообщение, уведомляющее об ошибке. Сообщение IOTP, которое содержит компонент Error, который описывает ошибку, обнаруженную в сообщении.
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIREDErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED Severity (Warning|TransientError|HardError) #REQUIRED
| MinRetrySecs CDATA #IMPLIED | SwVendorErrorRef CDATA #IMPLIED> |
| ID | Идентификатор, который однозначно определяет компонент Error транзакции IOTP. |
| xml:lang | Определяет язык, используемый атрибутами или дочерними элементами компонента, если только значение не переписано атрибутом xml:lang дочернего элемента. Смотри раздел 3.8. |
| ErrorCode | Содержит код ошибки, который указывает на природу ошибки в сообщении. Допустимые значения ErrorCode приведены в секции 7.21.2. |
| ErrorDesc | Содержит текстовое описание ошибки на языке, заданном xml:lang. Содержимое этого атрибута определено поставщиком/разработчиком программного обеспечения, которое сгенерировало компонент Error. |
| Severity | Определяет степень (severity) ошибки. Допустимы следующие значения: о Warning. Индицирует, что хотя имеется ошибочное сообщение, транзакция может продолжаться. о TransientError. Индицирует, что ошибка в сообщении может быть исправлена, если ошибочное сообщение, на которое указывает элемент ErrorLocation, послать повторно. o HardError. Индицирует, что в сообщении имеется неустранимая ошибка, трпнзакция IOTP должна быть остановлена. |
| MinRetrySecs | Этот атрибут должен присутствовать, если Severity равен TransientError. Он равен минимальному числу полных секунд, которое приложение IOTP, получившее сообщение об ошибке, должно подождать прежде чем переадресовать сообщение, идентифицированное элементом ErrorLocation. |
Если атрибут Severity не равен TransientError, тогда значение этого атрибута игнорируется.
| SwVendorErrorRef | Этот атрибут является ссылкой, чье значение установлено поставщиком/разработчиком программы, которая сформировала компонент Error. Он должен содержать данные, которые позволяют поставщику идентифицировать точную позицию в его прогрпмме и установить причины, которые вызвали сообщение об ошибке. Смотри также атрибут SoftwareID Id-элемента сообщения в блоке ссылки транзакции (раздел 3.3). |
| ErrorLocation | Идентифицирует Id транзакции IOTP сообщения с ошибкой и, если возможно, элемент и атрибут сообщения, который вызвал формирование компонента Error. |
| PackagedContent | Содержит дополнительные данные, которые могут использоваться для понимания ошибки. Его содержимое может варьироваться в зависимости от природы ошибки (смотри раздел 7.21.2) и ои поставщика/разработчика приложения IOTP. Определение f PackagedContent смотри в разделе 3.7. |
Если об ошибке уведомляют более чем один компонент Error в сообщении, следует выполнять обработку компонента Error с наивысшим значением атрибута severity. В этом контексте, HardError имеет выше уровень “серьезности” (severity), чем TransientError, который имеет серьезность выше, чем Warning.
7.21.1.1. Severity = предупреждение
Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = Warning, тогда, если сообщение об ошибке не содержит другого компонента ошибки с атрибутом Severity выше, чем Warning, сообщение должно включать торговые блоки и компоненты, которые следовало бы включить, если бы сообщения об ошибке отсутствовало. Если сообщение получено с компонентом Error, где Severity = Warning, тогда:
- рекомендуется, чтобы информация об ошибке была доведена до сведения пользователя,
- разработчик приложения IOTP должен:
| - продолжеть транзакцию как обычно или | |
| - прервать транзакцию, выработав сообщение с компонентом Error и атрибутом Severity = HardError (смотри раздел 7.21.1.3). |
Если они не сформированы, то вырабатывается сообщение с компонентом Error и Severity = HardError.
7.21.1.2. Severity = переходная ошибка
Если приложение генерирует сообщение с компонентом Error, где атрибут Severity = TransientError, тогда в сообщение должен быть только один компонент Error. Кроме того, должен присутствовать атрибут MinRetrySecs. Если сообщение, уведомляющее об ошибке получено с компонентом Error, где Severity = TransientError тогда:
- если атрибут MinRetrySecs присутствует и имеет правильное значение, тогда следует использовать данную величину MinRetrySecs. В противном случае, если MinRetrySecs отсутствует или имеет неверное значение, тогда:
| - сформироать сообщение с компонентом Error и атрибутом Severity = Warning, после чего послать его со следующим сообщением (если такое имеется) торговой роли, которая прислала сообщение об ошибке с неверным значением MinRetrySecs и | |
| - использовать величину MinRetrySecs, установленное поставщиком/ разработчиком приложения IOTP. |
- Проверить, что только один элемент ErrorLocation содержится в компоненте Error и что он относится к сообщению, которое было послано получателем компонента Error с Severity = TransientError. Если имеется более одного элемента ErrorLocation, тогда генерируется сообщение со степенью серьезности равным HardError.
Если приложение генерирует сообщение об ошибке с компонентом Error, где атрибут Severity = HardError, тогда в сообщении должен быть только один компонент Error.
Если получено сообщение с компонентом Error, где атрибут Severity = HardError, транзакция прерывается.
7.21.2. Коды ошибок
Ниже следующая таблица содержит допустимые значения атрибута ErrorCode компонента Error. Первое предложение описания содержит текст, который должен использоваться для описания ошибки при отображении. Индивидуальные реализации могут транслировать его на альтернативные языки по своему усмотрению. ErrorCode не должен быть длиннее 14 символов.
| Значение | Описание |
| Reserved | Reserved. Эта ошибка зарезервирована поставщиком/ разработчиком программы. Контактируйте, если требуется, с поставщиком/разработчиком программы. Смотри ID-атрибут Software Id-элемента сообщения в блоке ссылок транзакции (раздел 3.3). |
| XmlNotWellFrmd | XML плохо сформирован. Документ XML плохо сформатирован. Смотри [XML]Ю, для того чтобы понять, что значит "хорошо сформатирован". Даже если XML сформатирован плохо, он должен быть просмотрен, найден блок ссылок транзакции, с тем чтобы было можно правильно сформировать отклик Error. |
| XmlNotValid |
XML некорректен. Документ XML сформатирован хорошо, но он некорректен. Для того чтобы понять, что значит "корректен" смотри [XML], в частности: oдокумент XML не следует регламентациям, определенным декларацией типов документов IOTP (DTD) (смотри раздел 13) и o документ XML не следует регламентациям, определенным расширениям декларации типов документов [XML Namespace]. |
| ElUnexpected | Нестандартный элемент. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который не является стандартным для данного контекста согласно правил и ограничениям, содержащимся в данной спецификации. |
| ElNotSupp | Элемент не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, присутствует элемент, который: o согласуется с правилами и ограничениями данной спецификации, но o не поддерживается приложением IOTP, которое обрабатывает IOTP-сообщение. |
| ElMissing | Элемент отстутствует. Несмотря на то что документ XML сформирован правильно и корректен, отсутствует элемент, который должен присутствовать, если следовать правилам и ограничениям данной спецификации. |
| ElContIllegal | Содержимое элемента не верно. Несмотря на то что документ XML сформирован правильно и корректен, элемент Content содержит значения, которые не согласуются с правилами и ограничениями данной спецификации. |
| EncapProtErr | Ошибка инкапсулированного протокола. Несмотря на то что документ XML сформирован правильно и корректен, PackagedContent элемента содержит данные инкапсулированного протокола, которые неверны. |
| AttUnexpected | Нестандартный атрибут. Несмотря на то что документ XML сформирован правильно и корректен, присутствие такого атрибута в данном контексте не предусмотрено и не согласуются с правилами и ограничениями данной спецификации. |
| AttNotSupp | Атрибут не поддерживается. Несмотря на то что документ XML сформирован правильно и корректен, и приутствие атрибута элемента согласуется с правилами и ограничениями данной спецификации, он не поддерживается конкретной программной реализацией, которая обрабатывает сообщение IOTP. |
| AttMissing | Атрибут отсутствует. Несмотря на то что документ сформирован правильно и корректен, отсутствует атрибут, который согласно правилам и ограничениям данной спецификации должен присутствовать. |
В этом случае следует установить PackagedContent компонента Error соответствующим типу пропущенного атрибута.
| AttValIllegal | Не верно значение атрибута. Атрибут содержит значение, которое не согласуется с правилами и ограничениями данной спецификации. |
| AttValNotRecog | Значение атрибута не распознано. Атрибут содержит значение, которое приложение IOTP, обрабатывающее сообщение, не смогло распознать. |
| MsgTooLarge | Сообщение имеет слишком больую длину. Сообщение слишком велико для приложения, его обрабатывающего. |
| ElTooLarge | Элемент слишком велик. Элемент слишком велик для приложения, его обрабатывающего. |
| ValueTooSmall | Значение слишком мало. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком мало. |
| ValueTooLarge | Значение слишком велико. Значение всего или части элемента Content или атрибута, хотя и верно, но слишком велико. |
| ElInconsistent | Элемент не согласован. Несмотря на то что документ сформирован правильно и корректен, согласно правилам и ограничениям данной спецификации: о содержимое элемента не согласуется с содержимым других элементовили их атрибутов или о значение атрибута не согласуется со значением одного или нескольких других атрибутов. |
| TransportError | Транспортная ошибка (Transport Error). Этот код ошибки используется для индикации проблем с транспортным механизмом, которые приводят к потере сообщения. Она обычно ассоциируется с переходной ошибкой. Объяснение переходной ошибки содержится с атрибуте ErrorDesc. Значения, которые могут использоваться в ErrorDesc с TransportError специфицированы в приложении IOTP для транспортного механизма. |
| MsgBeingProc | Сообщение обрабатывается (Message Being Processed). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Код указывает, что предыдущее сообщение обрабатывается и, если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь. |
| SystemBusy | Система занята (System Busy). Этот код ошибки используется только с серьезностью (Severity) переходных ошибок. Он указывает, что сервер, который получил сообщение, в настоящее время занят и обработать сообщение не может. Если в орговоренное время, заданное атрибутом MinRetrySecs, не получено отклика, оригинальное сообщение следует послать вновь. |
Если транспортный механизм сервера/системы (например, HTTP) занят, следует использовать транспортные ошибки. Этот код нужно использовать в связи с серверами/системами IOTP или другими аналогичными системами, с которыми связан IOTP.
| UnknownError | Неизвестная ошибка. Индицирует, что транзакция не может завершиться по неидентифицированной причине. Атрибут ErrorDesc следует использовать для индикации природы проблемы. Эта ошибка может быть применена для указания, например, внутренней ошибки оконечного сервера или процесса клиента. |
Элемент Error Location указывает элемент и опционно атрибут в сообщении, с которым ассоциируется ошибка. Он содержит ссылку на сообщение IOTP, торговый блок, торговый компонент, элемент и атрибут, где обнаружена ошибка.
<!ELEMENT ErrorLocation EMPTY >
| <!ATTLIST ErrorLocation ElementType | NMTOKEN #REQUIRED |
| IotpMsgRef NMTOKEN #IMPLIED | BlkRef NMTOKEN #IMPLIED |
| CompRef NMTOKEN #IMPLIED | ElementRef NMTOKEN #IMPLIED |
Атрибуты:
| ElementType | Имя типа элемента, где обнаружена ошибка. Например, если элемент декларирован как <!ELEMENT Org, тогда его имя - "Org". |
| IotpMsgRef | Значение ID-атрибута Id-компонента сообщения (смотри раздел 3.3.2), к которому относится компонент Error. |
| BlkRef | Если ошибка ассоциирована со специфическим торговым блоком, тогда это значение ID-атрибута торгового блока, где обнаружена ошибка. |
| CompRef | Если ошибка ассоциирована со специфическим торговым компонентом, тогда это значение ID-атрибута торгового компонента, где обнаружена ошибка. |
| ElementRef | Если ошибка ассоциирована со специфическим элементом торгового компонента, тогда, если элемент имеет атрибут с типом (смотри [XML]) "ID", тогда это значение данного атрибута. |
| AttName | Если ошибка ассоциирована со значением атрибута, тогда это имя данного атрибута. В этом случае PackagedContent компонента Error должен содержать значение атрибута. |
