Базовая транзакция запроса состояния транзакции IOTP
Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:
торговый блок информационного запроса (смотри раздел 8.12),
торговый блок информационного отклика (смотри раздел 8.13)
опционный блок подписи (смотри раздел 8.16).
Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:
чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,
определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.
Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.
Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:
не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или
совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.
Базовыми требованиями являются:
Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:
| - Продавцу, после отправки блока выбора TPO, | |
| - Кассиру, после отправки блока платежного запроса, | |
| - Агенту доставки, после отправки блока запроса доставки, |
другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;
не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.
Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:
Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.
Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.
Технические ошибки в сообщении, содержащем сам блок информационного запроса.
Рабочие ошибки в исходных сообщениях
Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним.
Технические ошибки в исходных сообщениях
Возврат блока информационного отклика, содержащего компонент Status.
Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка. Технические ошибки в блоке информационного запроса Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса. Сообщения информационого запроса транзакции На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.
| 1. | Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли. |
| 1 а2 | Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса |
| 2. | Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается |
| 1 Я 2 | Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный) |
| 3. | Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |
Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:
- один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке.
- нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений.
- один компонент Signature (смотри раздел 7.19)
- один или более компонентов сертификата, если таковые нужны.
- Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой;
- другие торговые роли могут согласовать применение цифровых подписей, если это требуется. Например, Кассир может потребовать, чтобы информационный запрос был подписан Продавцом.
- один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции,
- нуль или один компонент платежной схемы. Этот компонент содержит инкапсулированные платежные сообщения, специфические для выбранной схемы оплаты.
- один компонент Signature (смотри раздел 7.19)
- один или более компонентов Certificate, если они нужны.
- Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой;
- другие торговые роли могут договориться о том, что подпись необходима. Например, продавец может потребовать присылки подписанного информационного отклика от кассира.
