Синхронизация заказов и рейсов по лентам изменений

У заказов и рейсов отдельные ленты изменений. Выберите сценарий по объекту и роли в нужной организации.

Храните курсор в долговременном хранилище клиента. Включите в ключ курсора стенд, вид ленты, роль и область организаций. Токен, идентификаторы, запросы и ответы оставляйте в клиенте. Права доступа и правила раскрытия проверяйте по карточкам методов.

Начать чтениеНачать чтение

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

1. Возьмите сохранённый курсор выбранной ленты. Если курсора нет, передайте границу чтения в data.toTime в формате RFC 3339. Чтобы начать чтение с текущего момента, используйте текущее время. Возьмите начальный курсор из data.id. Значение 0 допустимо.
2. Передайте курсор в data.lastId. В порцию входят изменения с id > lastId. Разберите JSON-ответ перед чтением data.changes, даже если клиент вернул тело в байтах. При пустой первой порции сохраните начальный курсор. Если курсор уже сохранён, завершите обработку пустой порции без записи в хранилище. Допустимые значения пустой порции указаны в сценарии роли.

Обработать порциюОбработать порцию

1. Обработайте записи data.changes по возрастанию id. Сохраняйте каждое событие, даже если по одному объекту пришло несколько изменений. Убирайте повторы только из списка идентификаторов для запроса деталей.
2. Проверьте идентификатор объекта в каждом событии, для которого нужны детали. Для ленты заказов это orderId, для ленты рейсов — flightId. Если хотя бы один такой идентификатор отсутствует или пуст, остановите обработку всей порции и оставьте курсор прежним.
3. Запрашивайте детали по непустому списку идентификаторов через метод из сценария. Для больших порций запрашивайте детали группами. Используйте только карточки с id из запроса. Карточка показывает состояние объекта на момент чтения.
4. Если в ответе отсутствуют запрошенные карточки, соберите их ID. Если интеграции нужны все карточки, оставьте курсор прежним. Если интеграция допускает отдельную сверку, сохраните список вместе с событиями и следующим курсором.
5. После успешной обработки порции запишите события и следующий курсор в одной транзакции хранилища клиента. Следующий data.lastId возьмите из последнего data.changes[].id.

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

Продолжить после ошибкиПродолжить после ошибки

• Если запрос деталей завершился ошибкой, оставьте курсор прежним. Повторяйте только после временных ошибок, указанных в карточке метода.
• Если клиент потерял ответ на запись в локальное хранилище, перед повтором прочитайте фактически сохранённый курсор.
• При ошибке авторизации проверьте доступ к API для исходной области организаций.
• Если продолжить чтение с прежнего курсора не удаётся, согласуйте с пользователем новую границу чтения. Укажите период, за который могут быть пропущены изменения. Контракт ленты не задаёт срок доступности истории.
• Для отдельной сверки повторите запрос деталей по сохранённым ID в той же области доступа. Уберите ID из списка после сохранения карточки или по решению пользователя. Отсутствие карточки само по себе не подтверждает удаление заказа или рейса. Сверку ведите отдельно от курсора ленты.