Протокол IGRP

Обработка ошибок IOTP



4. Обработка ошибок IOTP



IOTP создан как протокол запросов/откликов, где каждое сообщение состоит из нескольких торговых блоков, которые содержат некоторое. Существует несколько взаимосвязанных соображений при обработке ошибок, ретрансмиссий, дубликатов и тому подобное. Эти факторы приводят к тому, что IOTP вынужден обрабатывать поток сообщений не просто как последовательность запросов и откликов. Кроме того может встретится большое разнообразие ошибок в сообщениях, на транспортном уровне или в торговых блоках или компонентах. Датее будет рассмотрено, как IOTP обрабатывает ошибки, повторные попытки и дубликаты сообщений.

Могут произойти различные ошибки:

- "технические ошибки", которые не зависят от цели сообщения IOTP,
- "деловые ошибки", которые указывают, что имеется специфическая проблема для процесса (напр., для платежа или доставки), который исполняется.

Глубина ошибки показывает, где произошла ошибка (при транспортировке, при составлении сообщения или на уровне блока/компонента)

4.1. Технические ошибки



К техническим ошибкам относятся ошибки, которые не зависят от значения сообщения. Это означает, что они могут влиять на любую попытку передачи. Обычно они обрабатываются стандартным образом с ограниченным числом опций для пользователя. Такие ошибки могут быть:

o повторная попытка передачи;
o аннулирование транзакции.

Когда связь работает достаточно хорошо, техническая ошибка индицируется компонентом Error (смотри раздел 7.21) в блоке Error (смотри раздел 8.17), посланным партнером, который детектировал ошибку в сообщении IOTP, партнеру, пославшему ошибочное сообщение.

Если связь слишком плохая, сообщение, которое было послано, может не достичь адресата. В этом случае может произойти таймаут.

Коды ошибок, соответствующие техническим ошибкам записываются в компоненте Error, где перечисляются различные технические ошибки, которые могут случиться.

4.2. Рабочие ошибки

Рабочие ошибки могут случиться, когда IOTP-сообщения "технически" вполне корректны.
Они связаны с определенным процессом, например, предложение, платеж, доставка или аутентификация, где каждый процесс имеет разный набор возможных рабочих ошибок.

Например, "Недостаточно средств" является сообщением об ошибке при платеже, но не имеет никакого значения для доставки, в то время как "Back ordered" возможное сообщение об ошибке доставки, но не имеет смысла для платежа. Рабочие ошибки индицируются компонентом Status (смотри раздел 7.16) "блока отклика" соответствующего типа, например, блока Payment Response или Delivery Response. Это допускает любой дополнительный отклик, связанный с информацией, которая необходима для пояснения возникшей ошибки.

Рабочие ошибки должны обычно представляться пользователю так, чтобы он мог решить, что делать дальше. Например, если ошибка связана с недостаточностью платежных средств в предложении, независящим от типа платежа (смотри раздел 9.1.2.2), пользователь может пожелать выбрать другой счет того же типа или другой тип платежа или даже другую платежную систему. Иными словами, если реализация, базирующаяся на IOTP, допускает это и пользователь может перевести дополнительные средства на счет и совершить еще одну попытку.

4.3. Глубина ошибки

Три уровня, на которых могут произойти ошибки в IOTP, включают транспортный уровень, уровень сообщения и уровень блока.

4.3.1. Транспортный уровень

Этот уровень ошибки указывает фундаментальную проблему в транспортном механизме, через который осуществляется передача в IOTP.

Все ошибки транспортного уровня являются техническими и индицируются явно на транспортном уровне, как "No route to destination" из TCP/IP или через таймаут, когда не получено отклика на посланный запрос.

Единственно разумным автоматическим действием, когда сталкиваешся с ошибками транспортного уровня, является попытка повторной передачи, а после нескольких попыток информирование пользователя об этом.

Неявная индикация ошибки, которая может быть получена, является зависимой от транспортной среды и для принятия решения относительно конкретных действий следует обращаться к документации транспортного приложения IOTP.



Таймауты здесь являются функцией как транспорта так и платежной системы, если в запрос инкапсулирована платежная информация. Для выяснения параметров таймаутов и повторных передач рекомендуется обращаться к документации по транспортной и платежной системам. Часто нет способа непосредственно проинформировать партнера об ошибках транспортного уровня, при таких обстоятельствах такие события должны регистрироваться и, если автоматическое восстановление системы не сработало, а в процесс вовлечен человек-пользователь, его следует проинформировать об инциденте.

4.3.2. Уровень сообщения

Этот уровень ошибки указывает на фундаментальную техническую проблему с IOTP-сообщением в целом. Например, XML документ некорректно оформлен, сообщение имеет слишком большую длину для получателя, или обнаружена ошибка в блоке ссылок транзакции (смотри раздел 3.3).

Все ошибки уровня сообщений являются техническтими ошибками и индицируются компонентами Error (смотри раздел 7.21), послаными партером. Компонент Error включает в себя атрибут Severity (степень угрозы), который указывает, является ли ошибка предупреждениеим и может быть проигнорирована, TransientError и что повторная попытка может разрешить проблему или HardError, что говорит о срыве транзакции. Технические ошибки (смотри раздел 7.21.2; Коды ошибок), которые являются ошибками уровня сообщения, включают:

  • XML not well formed. Документ имеет не верный формат XML (смотри [XML])
  • XML not valid. Документ не вполне отвечает требованиям XML (смотри [XML])
  • Технические ошибки блочного уровня (смотри раздел 4.3.3) в блоке ссылок транзакции (смотри раздел 3.3) и блоке подписи. Следует проверить только эти блоки, если с XML все в порядке.
Заметим, что проверки блока подписи включают проверку, где это возможно, того, что каждый из компонентов подпися вычислен правильно. Если подпись вычислена неправильно, тогда данные, которые покрываются подписью не будут признаны истинными. Процедура проверки подписи описана в разделе 6.2.

4.3.3. Уровень блоков



Ошибки блочного уровня указывают на проблему с блоком или одним из его компонентов в сообщении IOTP (помимо блоков ссылок транзакции или подписи). Сообщение передано корректно, структура всего сообщения, включая блоки ссылок транзакции и подписи, вполне разумна, но имеется ошибка, связанная с каким-то другим блоком. Ошибки блочного уровня могут быть:

  • техническими ошибками
  • рабочими ошибками
Технические ошибки далее делятся на:

  • Связанные с проверкой атрибутов блочного уровня и элементов.
  • Связанные с проверкой согласованности блоков и компонентов.
  • Переходные технические ошибки.
Если случислась техническая ошибка, связанная с блоком или компонентом, формируется компонент Error для посылки отправителю некорректного сообщения.

4.3.3.1. Проверки атрибутов блочного уровня и элементов

Проверки элемента и атрибута блочного уровня производятся только в пределах одного и того же блока. Проверки, которые включают в себя перекрестные сверки с другими блоками, относятся к проверкам согласованности блоков и компонент.

Проверки элемента и атрибута блочного уровня включают в себя:

  • проверку того, что значение каждого атрибута в каждом элементе блока согласуется с правилами спецификации IOTP;
  • проверку того, что содержимое каждого элемента согласуется с правилами спецификации IOTP;
  • если предыдущие проверки прошли успешно, тогда осуществляется контроль согласованности значений атрибутов и содержимого элементов со значениями атрибутов и содержимым элементов любых других компонентов в пределах блока.
4.3.3.2. Проверки согласованности компонентов и блоков

Проверки согласованности компонентов и блоков состоит из:

  • проверки того, что комбинации блоков и/или компонентов, присутствующих в сообщении IOTP, согласуются с правилами спецификации;
  • проверки взаимосогласованности атрибутов и содержимого элементов в блоках сообщения IOTP;
  • проверки взаимосогласованности атрибутов и элементов в блоках данного сообщения IOTP и блоков, полученных ранее IOTP-сообщений в рамках одной и той же транзакции.
Если блок проходит проверку атрибутов и элементов блочного уровня и контроль согласованности блоков и компонентов, тогда он обрабатывается IOTP-приложением или какой-то оконечной системой, такой как платежный сервер.



4.3.3.3. Переходные технические ошибки

Во время обработки блока могут произойти временные отказы, которые в принципе могут быть преодолены позднее повторной передачей исходного сообщения. В этом случае партнер информируется о переходной ошибке путем посылки компонента Error (смотри раздел 7.21) с атрибутом Severity равным TransientError и атрибутом MinRetrySecs равным некоторому значению, удобному для используемого транспортного механизма и/или платежного протокола (смотри соответствующие приложения транспортного и платежного протокола). Заметим, что переходные технические ошибки могут генерироваться любыми торговыми агентами, вовлеченными в транзакцию.

4.3.3.4. Рабочие ошибки блочного уровня

Если в процессе платежа или доставки происходит рабочая ошибка, тогда присылается соответствующий тип блока отклика, содержащий компонент Status (смотри раздел 7.16) с атрибутом ProcessState равным Failed и CompletionCode, указывающим на природу проблемы.

Некоторые рабочие ошибки могут быть переходными, при таких обстоятельствах Покупатель может справиться с ситуацией самостоятельно и успешно завершить транзакцию каким-то способом. Например, если на кредитной карточке покупателя недостаточно денег, он может воспользоваться для покупки другой кредитной карточкой.

Преодоление переходных рабочих ошибок зависит от CompletionCode. Для понимания имеющихся возможностей смотри определение компонента Status. Заметим, что для рабочих ошибок не формируется компонент или блок Error.

4.4. Idempotency, последовательность обработки и поток сообщений

IOTP-сообщения представляют в действительности комбинацию блоков и компонентов, как это описано в 3.1.1 (Структура сообщений IOTP). В будущем при расширении IOTP разнообразие таких комбинаций еще более расширится. Важно, что многократные приемы/передачи одного и того же запроса изменения состояния имеют тот же результат, как и однократная передача/прием этого запроса. Это называется идемпотентностью. Например, покупатель, оплачивая заказ, желает оплатить его только раз.


Большинство сетевых транспортных механизмов имеют определенную вероятность доставки одного сообщения несколько раз или не доставить ни разу, что потребует позднее повторной передачи. С другой стороны, запрос состояния можно повторять и при этом каждый раз должно обрабатываться вновь полученное значение. Правильная реализация IOTP может моделироваться по разному различными процессами.

4.5. Последовательность обработки для роли сервера

"Роли сервера" – это любые торговые роли, несовпадающие с ролью Покупателя. Они являются "ролями сервера", так как они обычно получают запросы, которые они должны обработать и посылать на них отклики. Однако Роли сервера могут также инициировать транзакции. Более конкретно роли сервера должны быть способны:

o Инициировать транзакцию (смотри раздел 4.5.1). Это могут быть:
  - платеж, связанный с транзакцией;
&nbsp - инфраструктурные транзакции.
o Принять и обработать сообщение полученное от другой торговой роли (смотри раздел 4.5.2). Сюда относится:
  - идентификация, если сообщение принадлежит транзакции, которая была запущена ранее;
  - обработка сообщений-дубликатов;
  - генерация переходных ошибок, если сервер, который обрабатывает входные сообщения перегружен;
  - обработка сообщения, если оно лишено ошибок и авторизовано, и при благоприятном исходе, послать отклик отправителю сообщения.
o Аннулировать текущую транзакцию, если поступил такой запрос (смотри раздел 4.5.3)
o Повторно передать сообщение, если ожидается отклик, который не поступил за определенный период времени (смотри раздел 4.5.4).
4.5.1. Инициализация транзакций

Роли сервера могут инициировать большое число различных транзакций. В чатности:

o Транзакцию информационного запроса (смотри раздел 9.2.1);
o Транзакцию Ping (смотри раздел 9.2.2);
o Транзакцию аутентификации (смотри раздел 9.1.6);
o Транзакцию, сопряженную с платежем, такую как:
  - Депозит (смотри раздел 9.1.7);
  - Покупка (смотри раздел 9.1.8);
  - Возврат денег (смотри раздел 9.1.9);
  - Отзыв сделки (смотри раздел 9.1.10);
  - Обмен ценностями (смотри раздел 9.1.11).
4.5.2.


Обработка входных сообщений

Обработка входных сообщений включает в себя:

o проверку структуры и идентификацию сообщения;
o выявление и обработку сообщений-дубликатов;
o обработку недублированных, оригинальных сообщений, которая включает в себя:
- выявление ошибок, и, если они не обнаружены,
- обработку сообщений и, если требуется, выработку откликов.
4.5.2.1. Проверка структуры и идентификация сообщений

Крайне важно проверить, что сообщение имее корректную XML-форму и идентификатор транзакции (IotpTransID-атрибут компонента TransId) в сообщении IOTP может быть распознан, так как IotpTransId будет нужен при формировании отклика.

Если входное сообщение сформировано некорректно, тогда генерируется компонент Error с атрибутом Severity равным HardError и код ошибки XmlNotWellFrmd.

Если входное сообщение сформировано правильно, но IotpTransId не может быть идентифицировано, генерируется компонент Error с :

o атрибутом Severity = HardError и кодом ошибки (ErrorCode) = AttMissing,
o содержимым PackagedContent, включающим в себя "IotpTransId" потерянного атрибута.
Далее получатель вводит компонент Error в блок ошибки с новым компонентом TransactionId с новым IotpTransId и отправляет его отправителю исходного сообщения.

4.5.2.2. Выявление и обработка дублированных сообщений

Если входное сообщение может быть идентифицировано, как корректное, то проверяется, не получалось ли раньше точно такое же сообщение. Под идентичностью здесь подразумевается, что все блоки, компонентя, элементы, значения атрибутов и элементы содержимого тождественны.

Рекомендуемым способом проверки идентичности сообщений является проверка равентства их [DOM-HASH].

Если получено сообщение, прежде чем его исследовать, нужно проверить, завершилась ли обработка предыдущего.

Если обработка не завершилась, генерируется компонент Error с атрибутом Severity = TransientError и кодом ошибки = MsgBeingProc, чтобы указать, что сообщение обрабатывается и послать его обратно отправителю, с предложением повторной присылки поздее.



4.5.2.3. Обработка недублированных сообщений

Если установлено, что сообщение не является дубликатом ранее полученного, тогда оно обрабатывается. Процедура обработки включает в себя:

o проверку того, что сервер готов для обработки, если это не так, генерируется переходная ошибка;
o проверку, не находится ли транзакция в режиме ошибки или неаннулирована;
o контроль корректности входного сообщения, который предусматривает:
  - проверку глубины ошибки сообщения;
  - проверку ошибок блочного уровня;
  - проверку любых инкапсулированных данных
o проверку ошибок в последовательности полученных блоков;
o генерацию компонентов ошибки для любых обнаруженных ошибок;
o если никаких серьезных или переходных ошибок не выявлено, производится обработка сообщения и, если требуется, генерация отклика отправителю входного сообщения.
Этот подход к обработке дублированных входных сообщений означает, что если получены два совершенно идентичных сообщения, будут посланы два идентичнх отклика. Это применимо также к информационным запросам и транзакциям Ping, когда в действительности состояние транзакции или возможность обработки сервером может измениться. Если требуется текущее состояние транзакции или сервера, тогда используется транзакция с новым значением ID-атрибута компонента MsgId.

Процесс обработки входного сообщения должен проверить, свободна ли остальная система. Если сервер слишком занят, он должен выдать компонент Error с атрибутом Severity равным Transient Error и кодом ошибки равным SystemBusy, после чего вернуть отправителю входное сообщение, запрашивая тем самым повторную присылку этого сообщения спустя некоторое время.

Некоторые серверы могут оказаться перегруженными из-за неожиданного всплеска загрузки. Данный подход позволяет преодолевать ситуации с кратковременными пиковыми нагрузками, запрашивая отправителя переслать сообщение несколько позже.

Проверка того, что транзакция не зафиксировала ошибку и не оказалась аннулированной.


Предполагается следующий контроль:

o предыдущие посланные или полученные сообщения не содержат серьезных (Hard) ошибок;
o транзакция не была анулирована покупателем или торговой ролью сервера.
Если это имеет место, сообщение игнорируется. Транзакция с серьезной ошибкой или аннулированная транзакция не может быть перезапущена.

Если с транзакцией все в порядке, производится поиск ошибок на уровне сообщения. Это включает в себя:

  • проверку формат XML;
  • проверку того, что все элементы, атрибуты и содержимое блока ссылок транзакции не содержат ошибок и соответствуют спецификации IOTP;
  • проверку цифровой подписи, которая в свою очередь предполагает:
  - проверку того, что корректно вычислена электронная подпись;
  - проверку того, что значение дайджеста вычислено правильно.
Проверка ошибок уровня блоков включает:

о проверку в пределах каждого блока (помимо блока ссылок транзакции) того что:
  - атрибуты, элементы и содержимое элементов корректно;
  - значения атрибутов, элементы и содержимого элементов не противоречат друг другу в пределах блока.
о проверку того, что комбинации блоков корректны
o проверку того, что значения атрибутов, элементы и содержимое элементов взаимосогласованы на межблочном уровне в пределах входного сообщения с блоками, полученными или отправленными ранее. Это включает проверку уместности данного блока для этого типа транзакции.
Если сообщение содержит какие-то инкапсулированные данные, то, если возможно, они проверяются на наличие ошибок.

4.5.2.4. Проверка ошибок в последовательности блоков

Далее при объяснении поиска ошибок в последовательностях блоков выражение типа "относится к транзакции IOTP" следует интерпретировать как "содержится в сообщении IOTP, где TransRef Block включает в себя IotpTransId, который указывает на данную танзакцию". Так, например, "Если ошибка или аннулированный блок относится к транзакции IOTP, которая не распознана, тогда..." следует интерпретировать как "Если ошибка или аннулированный блок содержатся в сообщении IOTP, TransRefBlock включает в себя IotpTransId, который относится к транзакции IOTP, которая не распознана, тогда...”.



Ошибки в последовательности прихода блоков зависят от блока. Блоки, где требуется проверка последовательности:

  • Error и Cancel блоки. Если Error или Cancel блок относится к транзакции IOTP, которая не распознана, тогда это серьезная (Hard) ошибка. Чтобы избежать зацикливания, не следует посылать оповещения об ошибке, если получен Error или Cancel блок транзакции IOTP.
  • Блоки отклика и информационного запроса. Если блоки отклика и информационного запроса относятся к транзакции IOTP, которая не распознана, это серьезная (Hard) ошибка.
  • Блок запроса аутентификации. Если блок запроса аутентификации относятся к транзакции IOTP, которая распознана, это серьезная (Hard) ошибка.
  • Блок отклика аутентификации проверяется следующим образом:
  - Если блок отклика аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае.
  - Если блок отклика аутентификации не относится к аутентификационному запросу, который был ранее послан, то это серьезная (Hard) ошибка, в противном случае.
  - Если блок отклика аутентификации получен в рамках IOTP-транзакции, до того как аутентификация успешно завершилась, то это серьезная (Hard) ошибка.
о Блок состояния аутентификации проверяется следующим образом:
  - если блок состояния аутентификации не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
  - если блок состояния аутентификации не относится к аутентификационному отклику, который был перед эти послан, тогда это серьезная (Hard) ошибка, в противном случае,
  - если блок состояния аутентификации получен для той же самой транзакции раньне, то это предупреждение (а не ошибка).
o Блок выбора TPO (только для продавца) прооверяется следующим образом:
  - если блок выбора TPO не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае,
  - если блок выбора TPO не относится к транзакции IOTP, где блок TPO и отклик предложения (в одном сообщении) были посланы ранее, то это серьезная (Hard) ошибка, в противном случае,
  - если блок выбора TPO относится к транзакции IOTP, где только блок TPO (т.e. без отклика на предложение) был послан ранее, то это серьезная (Hard) ошибка, в противном случае,
  - если блок выбора TPO для того же блока TPO получен ранее, то это серьезная (Hard) ошибка.
o Блок запроса платежа (только для кассира) проверяется следующим способом:
  - если блок запроса платежа относится к транзакции IOTP, которая не распознана, тогда все в порядке, в противном случае
  - если блок запроса платежа относится к транзакции IOTP, которая не связана с платежом, то это серьезная (Hard) ошибка, в противном случае
  - если был предшествующий платеж, который не прошел с кодом завершения недопускющим восстановление, то это серьезная (Hard) ошибка, в противном случае
  - если предыдущий платеж еще в работе, то это серьезная (Hard) ошибка.
o Блок платежного обмена (только для кассира) проверяется следжующим образом:
  - если блок платежного обмена не относится к транзакции IOTP, которая распознана, то это серьезная (Hard) ошибка, в противном случае
  - если платежный обмен не относится к транзакции IOTP, где такой обмен уже был, то это серьезная ошибка (Hard).
o Запрос доставки (только для агентов доставки). Если блок запроса доставки относится к транзакции IOTP, которая распознана сервероим, то это серьезная ошибка.



Если сгенерированы какие- либо компоненты Error, то они должны быть собраны в блок Error для посылки отправителю входного сообщения. Заметим, что блоки Error следует отсылать назад отправителю сообщения и ErrorLogNetLocn для торговой роли отправителя, если это специфицировано.

Описанная выше проверка последовательности аутентификационных откликов и платежных запросов поддерживает повторение запросов Покупателя, если предыдущая операция не прошла, например:

o потому что не получен корректный отклик (напр., пароль) на аутентификацию или

o не удалось произвести оплату, так как нехватает денег на кредитной карточке.

Обработка входного сообщения, лишенного ошибок

Если входное сообщение прошло предыдущие проверки, то оно должно быть обработано и послан, если требуется, отклик. Заметим, что:

  • Информационные запросы на транзакции Ping следует игнорировать;
  • Если входное сообщение содержит блок Error с переходной ошибкой, следует подождать необходимое время и затем повторно послать предыдущее сообщение, если не было получено отклика на сообщение, посланное ранее;
  • Если входное сообщение содержит компонент Error с HardError или блок Cancel, тогда последующая обработка транзакции должна быть остановлена. Это включает в себя блокировку отправки любых текущих сообщений или посылку откликов на любые новые приходящие недублированные сообщения;
  • Обработка инкапсулированных сообщений (напр., сообщения платежного протокола) может вызвать дополнительные переходные ошибки;
  • Цифровая подпись может быть корректно сформирована лишь в случае, если сгенерированы все блоки и компоненты и известно, какие элементы в сообщении должны быть подписаны.
Если выходное сообщение сгенерировано, оно должно быть запомнено, так чтобы иметь возможность, если потребуется, послать его повторно. Заметим, что выходные сообщения, которые содержат переходные ошибки, не запоминаются, так что они формируются заново, при их повторной посылке.

4.5.3. Аннулирование транзакции

Этот процесс используется, чтобы аннулировать транзакцию, Этот процесс служит для аннултрования транзакции работающей на сервере IOTP.


Он инициируется некоторым другим процессом, как результат внешнего запроса отдругой системы или сервера, который играет ту же торговую роль. Обработка такого запроса требует:

  • если IotpTransId транзакции, которую надо аннулировать, не распознан, или она завершена, то запрос не проходит, в противном случае,
  • если IotpTransId относится к транзакции Ping, то запрос не проходит, в противном случае,
  • определить, какой локументальный обмен нужно прервать, сформировать блок Cancel и послать его партнеру.
Аннулирование транзакции на сервере IOTP обычно возникает по деловым причинам. Например продавец может попытаться безуспешно аутентифицироваться несколько раз, после чего решает аннулировать транзакцию. Следовательно процесс, который решаетпроизвести такое действие, должен послать сообщение из процесса/сервера с инструкцией о том, какую транзакцию следует аннулировать.

4.5.4. Повторная посылка сообщений

Сервер должен периодически проводить проверки, нет ли транзакций, ожидающих сообщения-отклики и неполчивших их своевременно. Такая задержка может быть связана со следующими факторами:

о из-за используемого танспортного механизма;
o из-за времени, необходимого для обработки инкапсулированных сообщений (напр., платежных) и
o зависит оттого, нужен или нет ввод со стороны человека.
Если не получено никакого сообщения, оригинальное сообщение должно быть послано повторно. Это должно производиться некоторое число раз в зависимости от надежности используемого транспортного механизма. Если не получено отклика в течении оговоренного времени, транзакция прерывается по таймауту. В этом случае, состояние транзакции устанавливается равным Failed, и выдается код завершения:

o TimedOutRcvr, если транзакция может быть восстановлена позднее, или
o TimedOutNoRcvr, если транзакция невосстановима.
4.6. Последовательность обработки для роли клиента

"Роль клиента" в IOTP является торговой ролью Покупателя.

Компания или организация, которая является Продавцом может, например, взять на себя роль покупателя, делая покупки или или выполняя отзыв электронного платежа.



В частности Покупатель должен быть способен:

o Инициировать транзакции (смотри раздел 4.6.1). Среди них могут быть:
  - платеж, связанный с транзакцией
  - инфраструктурные транзакции.
o Воспринять и обработать сообщение, полученное от другой торговой роли (смотри раздел 4.6.2). Сюда входит:
  - идентификация того, принадлежит ли сообщение транзакции, запущенной ранее;
  - обработка дублированных сообщений;
  - генерирование переходных ошибок, если сервер, который обрабатывет входное сообщение перегружен;
  - обработка сообщения, если оно не имеет ошибок и, если необходимо, посылка отклика партнеру по результатам обработки.
o Аннулировать текущую транзакцию, если поступил соответствующий запрос, например от пользователя (смотри раздел 4.6.3).
o Повторно передать сообщение, если ожидаемый отклик не пришел своевременно (смотри раздел 4.6.4).
4.6.1. Операции инициализации

Роль Покупателя может инициировать большое число различных транзакций. В частности:

o Процедуру запроса (смотри раздел 9.2.1)
o Транзакцию Ping (смотри раздел 9.2.2)
o Процедуру аутентификации (смотри раздел 9.1.6)
4.6.2. Обработка входных сообщений

Обработка входных сообщений для роли покупателя происхотит также как и для IOTP-сервера (смотри раздел 4.5.2) за исключением проверки ошибок в последовательности блоков (для IOTP-сервера смотри раздел 4.5.2.4).

Описание обработки входных сообщений для сервера IOTP включает соображения многопроцессности и многозадачности. Для роли покупателя – в частности при работе на изолированной рабочей системе использование много процессности оставляется на усмотрение разработчика.

4.6.2.1. Поиск ошибки в последовательности блоков

Последовательность обработки блоков для роли покупателя та же, что и для IOTP-сервера (смотри раздел 4.5.2.4) за исключением того, что роль покупателя подставляется вместо роли сервера IOTP:

о Блоки Error и Cancel,
o Блоки отклика и информационного запроса,
o Блоки запросов аутентификации, отклика и состояния.
Для других блоков роль покупателя может получать уведомление об ошибках в порядке прихода блоков и может зависеть от типа блоков.


Блоки, где важна последовательность проверки перечислены ниже:

o Блок TPO проверяется следующим образом:
  - если входное сообщение содержит блок запроса аутентификации и блок отклика на предложение, то это серьезная (Hard) ошибка, в противном случае,
  - если входное сообщение содержит блок запроса аутентификации и статуса аутентификации, то это серьезная (Hard) ошибка, в противном случае,
  - если входное сообщение содержит блок запроса аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
  - если входное сообщение содержит блок состояния аутентификации и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
  - если входное сообщение содержит блок состояния аутентификации, а блок состояния аутентификации послан до сообщения-отклика аутентификации, то это серьезная (Hard) ошибка,
  - если входное сообщение содержит блок отклика на предложение и транзакция IOTP распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
o Блок отклика предложения проверяется следующим образом:
  - если блок отклика на предложение является частью брэнд-независимого обмена предложения (смотри раздел 9.1.2.2), тогда никакой проверки последовательности не нужно, так как это первое сообщение, в противном случае,
  - если блок отклика на предложение не является частью транзакции IOTP, которая распознана покупателем, то это серьезная (Hard) ошибка, в противном случае,
  - если блок отклика на предложение не относится к транзакции, где в последнем сообщении послан блок выбора TPO, то это серьезная (Hard) ошибка.
o Блок платежного обмена проверяется следующим образом:
  - если блок платежного обмена не относится к транзакции IOTP, которая распознана системой покупателя, то это серьезная (Hard) ошибка, в противном случае,
  - если платежный обмен не относится к транзакции IOTP, где только что послан блок платежного запроса или платежного обмена, то это серьезная (Hard) ошибка.
o Блок платежного отклика проверяется следующим образом:
  - если блок платежного отклика не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,
  - если блок платежного отклика не относится к транзакции IOTP, где только что послан блок платежного обмена или блок платежного запроса, то это серьезная (Hard) ошибка.
o Блок отклика доставки проверяется следующим образом:
  - если блок отклика доставки не относится к транзакции IOTP, которая распознана системой Покупателя, то это серьезная (Hard) ошибка, в противном случае,
  - если блок отклика доставки не относится к транзакции IOTP, где только что послан блок запроса платежа или платежного обмена, то это серьезная (Hard) ошибка.
4.6.3.Аннулирование операции

Этот процесс аннулирует текущую транзакцию системы покупателя в результате внешнего запроса пользователя или другой системы или сервера, исполняющего роль покупателя. Обработка запроса делается также как для сервера IOTP (смотри раздел 4.5.3).

4.6.4. Повторная передача сообщений

Ретрансмиссия сообщений осуществляется так же, как и в случае сервера IOTP (смотри раздел 4.5.4).



Содержание раздела