совсем не реагировать на информационный
совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.
Базовыми требованиями являются:
- Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:
|
- Продавцу, после отправки блока выбора TPO, |
|
- Кассиру, после отправки блока платежного запроса, |
|
- Агенту доставки, после отправки блока запроса доставки, |
- другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;
- не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.
Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:
- Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.
- Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.
- Технические ошибки в сообщении, содержащем сам блок информационного запроса.
Рабочие ошибки в исходных сообщениях
Возврат блока информационного запроса, содержащего компонент 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. |
Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |
<
Содержание Назад Вперед