Данные рекомендации основаны на длительной практике использования протокола версии 2 в самых различных приложениях и продуктах e-port и других разработчиков ПО.
Правильный выбор архитектуры приложения и правильное использование протокола с учетом приведенной здесь информации позволит разработать высокопроизводительное и надежное ПО по приему платежей.
Рекомендуем использовать аутентификацию по ЭЦП, по следующим причинам:
Аутентификация по ЭЦП безопаснее, поскольку позволяет обеспечить контроль целостности передаваемого сообщения, и таким образом исключить возможность подделки сообщения. Кроме того, реквизиты карты e-port легко запомнить, содержимое файла закрытого ключа запомнить практически невозможно.
Аутентификация по ЭЦП работает значительно быстрее и надежнее, поскольку проверка ЭЦП осуществляется по локальной копии файла сертификата Точки Агента, а аутентификация по реквизитам карты e-port требует обращения к авторизационному серверу e-port.
Дополнительные усилия, затраченные на реализацию аутентификации по ЭЦП, окупятся повышенной скоростью и надежностью взаимодействия.
Порядок аутентификации сообщений протокола подробно описан в документации, п 6.5, рекомендации по использованию ЭЦП и примеры исходного кода для различных языков программирования и платформ приведены в разделе Дополнительная информация.
Рекомендуем использовать при обмене простой текстовый формат.
Несмотря на высокую доступность различных компонент и библиотек для работы с XML, простой текстовый формат имеет важные преимущества:
В случае, если Вы планируете значительный поток обрабатываемых операций, эти преимущества могут стать критически важными. Подробное описание форматов протокола содержится в документации, п 7.
Синхронный режим протокола рекомендуется использовать только в специальных случаях, если Ваша система работает в режиме реального времени.
Из общей практики широко известно, что системы массовой параллельной обработки, построенные на пакетной асинхронной обработке задач, обеспечивают гораздо большую пропускную способность при меньших системных затратах, чем системы реального времени.
Синхронный режим, несмотря на кажущуюся простоту реализации, по сравнению с асинхронным режимом обладает рядом существенных недостатков.
При обработке синхронного запроса и клиенту и серверу приходится удерживать контекст соединения гораздо более длительное время, чем в случае асинхронного запроса. Это создает повышенную нагрузку на обе взаимодействующие стороны, но на скорость обработки операции, очевидно, никак повлиять не может. Кроме того, затраты на установку соединения (для каждого запроса по каждой операции) значительно выше, чем в асинхронном пакетном режиме.
Синхронный режим может быть полезен в случае, если имеется очень жесткое ограничение на время проведения операции, и при превышении отведенного на взаимодействия тайм-аута предполагается безусловная отмена операции.
В этом случае следует отправлять один синхронный двухфазный запрос операции. Если сервер ответил запросом подтверждения, после принятия решения о результате операции следует отправить на сервер запрос подтверждения в асинхронном пакетном режиме. Если сервер отклонил заявку, операцию следует безусловно отменить, прекратив дальнейший обмен с сервером по ней. При отсутствии со стороны сервера запроса подтверждения после принятия решения об отмене операции следует перейти к отправке на сервер запроса отмены операции в асинхронном пакетном режиме. Описанная схема дейстивтельно позволяет принять решение о результате операции в течение фиксированного времени. Тем не менее, любые задержки в обработке, например, со стороны провайдера, будут приводить к безусловной отмене операций.
В случае стабильных задержек со стороны провайдера все операции данного провайдера будут завершаться неуспешно. Поскольку основной задачей, как правило, является проведение платежей, а не их отмена, подобная архитектура не рекомендуется к использованию. Протокол допускает данную возможность опционально, для подключения уже существующих систем, работающих по описанным принципам.
В случае, если Вы планируете значительный поток обрабатываемых операций, следует принять решение в пользу асинхронного пакетного режима.
Если в Вашем случае действительно необходимо использовать синхронный режим, то рекомендуем Вам его применять предельно аккуратно.
По каждой операции имеет смысл отправлять в синхронном режиме только первый запрос, все остальные запросы должны отправляться в пакетном асинхронном режиме.
Операции необходимо проводить в двухфазном режиме, в противном случае отсутствует возможность надежной отмены операции после завершения отведенного тайм-аута.
Иные способы использования синхронного режима протокола, кроме описанной выше схемы, комбинирующей один синхронный запрос и завершение операции в асинхронном пакетном режиме, приведут к бессмысленному увеличению нагрузки на ПО клиента и сервера.
Подробное описание данных режимов протокола содержится в документации, п 4.
В случае, если сервер ответил по операции кодом ответа «Отложено», Агент должен в следующих обменах сообщениями с сервером повторить последний отправленный запрос для продолжения выполнения операции.
Рекомендуется выполнять повторный запрос с нарастающим тайм-аутом по каждой из операций. После второго ответа сервера с кодом «Отложено» при формировании следующего пакета данную операцию следует исключить из запроса, отложив перезапрос по ней в последующий пакет. С каждым очередным ответом «Отложено» количество пропущенных пакетов следует увеличивать вплоть до такого, когда разница между перезапросами составит порядка 10 - 15 минут.
В случае большого потока операций при формировании очередного пакета следует включать в него в первую очередь запросы по новым операциям, добавляя перезапросы с пониженным приоритетом.
Данный алгоритм позволит существенно снизить нагрузку на ПО клиента и сервера и уменьшить объем пересылаемых данных без понижения качества обработки операций. Очевидно, если операция по причине недоступности Провайдера или иным причинам не завершилась за длительный срок (минуты), то получение ответа о завершении на секунды раньше или позже уже не изменит ситуацию.
Порядок обмена сообщениями при проведении операции подробно описан в документации, п 4.4.
Для повышения надежности и производительности системы Сервер e-port реализован в виде симметричного кластера, который представляет собой группу совершенно идентичных по функциональности серверов, доступных из Интернет по различным адресам, отличающихся именем домена или номером порта.
В целях оперативного уведомления о доступности и загруженности серверов кластера, протоколом предусмотрена передача дополнительного HTTP-заголовка. Автоматическая обработка этого заголовка в программном обеспечении Агента позволяет повысить надежность взаимодействия и ускорить обработку операций.
В силу того, что некоторые сервера кластера могут быть выведены из эксплуатации без предупреждения, не реализация автоматической обработки списка адресов может привести к невозможности проведения операций.
Подробное описание данной функциональности содержится в Описании протокола, п 6.8, действующий список адресов опубликован в Дополнительной информации по подключению.
Обязательно подпишитесь на рассылку сообщений Службы Поддержки группы e-port, чтобы оперативно получать информацию о технических проблемах и задержках зачисления платежей.
Вы и/или Ваша служба технической поддержки будете оперативно получать по e-mail/icq/sms информацию обо всех инцидентах, связанных с техническими проблемами на стороне Организатора Системы и на стороне Провайдеров, включая предварительные уведомления о штатных запланированных работах и уведомления о нештатных аварийных ситуациях.
Дополнительно, при наличии информации, в сообщении указывается срок разрешения проблем, и обязательно высылается сообщение о восстановлении работоспособности (закрытии инцидента).
Подписка на рассылку производится в ЛКА.