Callback

1 Технология Callbacks
- 1.1 Настройка
2 Поведение при отправке и повторной отправке колбэков
3 Callback по заказам
4 Callback по статике

Технология Callbacks

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

Настройка

Раздел настройки Callback находится в разделе "Настройки - Настройки Callbacks":

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

Параметры:

Использовать Callback – включает механизм Callback;
Адрес Callback – URL получателя сообщений (обязательный параметр);
Callback HTTP Headers – список заголовков HTTP:

Accept-Encoding: gzip,deflate

Content-Type: text/xml;charset=UTF-8

SOAPAction: http://sap.com/xi/WebService/soap1.1

User-Agent: Corteos

Cookie2: $Version=1

Authorization: Basic QsdfgSDGHFasdfSADFxaWM=

Callback method (POST/GET) – HTTP-метод (обязательный параметр). Необходимо ввести “POST” или “GET” без кавычек;
Callback body – тело сообщения.

ОБРАТИТЕ ВНИМАНИЕ

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

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

Агент в свою очередь ставит задачу в Okdesk на вайтлистинг данного адреса. Support Corteos добавит адрес в соответствующий раздел.

Если адрес не завайтлистен в Corteos, система будет выдавать ошибку:

Статья о том, как протестировать отправку callbackов https://corteos-platform.atlassian.net/wiki/x/7ekM

Поведение при отправке и повторной отправке колбэков

Базовая логика отправки
Колбэк формируется в момент возникновения события, требующего уведомления слушателя, и отправляется на указанный в настройках endpoint слушателя.
Отправка выполняется независимо от дальнейшей судьбы колбэка (успешен он или нет), однако система ожидает подтверждение получения от слушателя.
Подтверждение получения
Слушатель должен вернуть ответ HTTP 200 OK в ответ на колбэк.
Получение этого ответа фиксируется как успешная доставка, и повторная отправка не выполняется.
Механизм повторной отправки
Если система не получает HTTP 200 OK, считается, что колбэк не доставлен, и запускается механизм повторных попыток:
- При первой ошибке устанавливается таймер — первая повторная отправка выполняется через 15 минут.
- Далее выполняется до 10 повторных попыток с интервалом каждые 5 минут.
- После исчерпания всех попыток колбэк помечается как неуспешный, и дальнейшая отправка не производится.
Причины и балансировка
Механизм реализован так, чтобы:
- с одной стороны, обеспечить доставку при временных проблемах на стороне слушателя;
- с другой — не перегружать базу и очередь сообщений лавинообразными повторными колбэками.
Рекомендации для слушателей
- Слушатель должен гарантированно возвращать HTTP 200 OK только после успешной обработки данных.
- Если на стороне слушателя возможны кратковременные сбои или задержки, рекомендуется реализовать:
  - собственный механизм повторной обработки входящих колбэков;
  - логирование всех полученных запросов для безопасного восстановления при сбоях.

Важно! Support Corteos (по запросам) не выполняет повторную отправку Callback, ни в единичном случае, ни за период. Callback отправляется только согласно описанию выше, вынужденные повторные отправки невозможны.

Callback по заказам

Данное callback-сообщение отправляется по адресу, указанному в настройках, в том случае, если произошли изменения с заказом.

Callbacks по заказам отправляются для следующих событий (@EventType):

заказ переходит в статус “Готов к оформлению” (readyforissuance)(@EventType=NewOrder);
заказ оформлен (выписан билет или сформирован ваучер) (@EventType=OrderTicketed);
заказ отменен (@EventType=OrderCanceled);
в заказ добавлен файл (@EventType=OrderPushStaticFile) (доступен при активации мода "Уведомление клиента о добавлении файла к заказу"(ModMailToClientAfterAddedFiles) ) ;
у заказа изменился статус (@EventType=OrderStateChanged);
у заказа изменилась стоимость (@EventType=OrderPriceChanged).

Callbacks также могут отправляться по командировке для следующих событий (@EventType):

командировка создана (@EventType=NewComplex);
у командировки изменился статус (@EventType=ComplexStateChanged);

Если вы хотите получать callbacks по командировкам, которые не содержат заказов, то вам требуется поставить чекбокс в настройке “Отправлять callback-сообщения по командировкам без заказов". В таком случае вам будут приходить callbacks о создании командировок и смене статуса командировок, в которых еще нет заказов. В ином случае callbacks будут приходить только по тем командировкам, которые уже содержат заказы.

Когда происходит изменение статуса командировки без изменения при этом статуса заказа, также отправляется callback, поля с информацией о заказе (номер заказа и статус заказа) при этом не заполнены.
Если изменение заказа влечет за собой изменение статуса командировки, то будет отправлен callback о изменении командировки с данными о заказе.

Формирование командировки происходит следующим образом: при бронировании любой услуги (например, перелета в город Санкт-Петербург), сначала создается командировка в статусе "Черновик" и далее в нее добавляется заказ по этой услуге (тоже в статусе "Черновик").
Бронирования при этом не происходит. По факту создания заказа придет callback.

При добавлении каждого нового заказа в командировку будет формироваться callback.

При вызове бронирования бронируются все услуги в командировке. После проставления бюджетных кодов в командировке, если они применяются, можно перевести командировку в "Чистовик". Далее командировку можно оформить – то есть выписать все автоматизированные услуги.

На каждую смену статуса заказа формируется callback.

Вы можете использовать SOAP или REST приемник для сообщения. В первом случае в теле сообщения необходимо указать всю структуру SOAP-объекта – например, Envelope, Body и так далее. Рекомендуется отправить тестовое сообщение к своему сервису при помощи SOAP UI и получить полный набор заголовков и структуру сообщения.

Ниже приведен набор переменных, которые можно использовать в данном callback:

@id_Reserve – уникальный системный номер заказа, по которому произошло событие;
@id_ComplexReserve – идентификатор командировки;
@OuterId - Внешний идентификатор командировки;
@EventType – тип события (см. выше доступные типы);
@ReserveState – текущее состояние заказа, значение из набора:
- draft – черновик;
- readyforissuance – готов к оформлению;
- inprocess – в обработке;
- finished – выполнен;
- canceled – отменен;
- queued – ожидает реакции агента;
- onconfirmation – у поставщика;
- needswork – ожидает реакции клиента;
- error – ошибка обработки заказа.
@ComplexState – текущее состояние командировки, значение из набора:
- draft – черновик;
- authorizing – идет авторизация;
- cleancopy – чистовик;
- forexecution – на исполнении;
- canceled – отменена;
- finished – завершена.
@EventDescription – текстовое описание события;
@CallbackId – это количество тиков текущих даты и времени (timestamp сервера, сформированный на момент отправки сообщения);

CallbackId - не уникальное значение и иногда (могут) совпадать для разных заказов. Это будет означать что CallbackId были сформированы в одно и тоже мгновение.

@id_ClientGroup - идентификатор группы компаний клиента;
@DIC:DictionaryName - Значение кода из указанного справочника.

Callback по статике

Данное сообщение отправляется в том случае, когда меняется структура какого-либо бизнес-объекта из следующего списка: