Телекоммуникационные технологии

         

совсем не реагировать на информационный


  • совсем не реагировать на информационный запрос, так как она может быть в нерабочем состоянии или считать запрос неправомочным из-за того, что он, например, не подписан.


    • Базовыми требованиями являются:

    • Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:


    - Продавцу, после отправки блока выбора 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. Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю.
    <

    Содержание  Назад  Вперед