Базовыми требованиями являются:
- Продавцу, после отправки блока выбора TPO, | |
- Кассиру, после отправки блока платежного запроса, | |
- Агенту доставки, после отправки блока запроса доставки, |
Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:
Рабочие ошибки в исходных сообщениях
Возврат блока информационного запроса, содержащего компонент Status, который был послан покупателю последним.
Технические ошибки в исходных сообщениях
Возврат блока информационного отклика, содержащего компонент Status. Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка.
Технические ошибки в блоке информационного запроса
Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса.
Сообщения информационого запроса транзакции
На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.
1. | Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли. |
1 a2 | Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса |
2. | Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается |
1 ? 2 | Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный) |
3. | Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |