Настройка получения событий с ящиком Контур.Диадок
В данной статье будет на примере нашего тестового ящика показано как добавить интеграцию с Контур.Диадок.
Для начала, уточним общие моменты. Что понимаем под интеграцией в контексте данной статьи? Конкретно в контексте данной статьи - получение событий из ЭДО-провайдера, их первичная обработка (конвертация) и отправка универсальной структуры события в обработчик. Детали по тому как работает интеграция смотрите в соседних статьях.
1. Создание DataSource до ЭДО провайдера
В новой интеграции мы не опираемся на жестко заданных в конфигах URL. По этой причине, при настройки интеграции - понадобится задать URL.
Описание работы DataSource смотрите в дочерних статьях раздела REST Data Source Он создается через системный журнал Data Sources.
Для начала проясним, нас интересует в большинстве случаев - REST DataSource, так как большинство ЭДО провайдеров предоставляют именно HTTP API. Требования к DataSource ЭДО провайдера, отличного от Контур.Диадок - смотрите в соответствующих статьях. Предоставляю пример настроенного DataSource для продуктивного Контур.Диадок:
Как несложно заметить, заполнены только обязательные поля (Id, Name) и URL. Именно на URL смотрит интеграция при запросе.
Примеры заполнения URL и расшифровка:
https://diadoc-api.kontur.ru - продуктивный Контур.Диадок, указанный на скрине выше.
https://diadoc-api-test.kontur.ru - тестовый Контур.Диадок.
https://test-edi-api.kontur.ru - тестовый Контур.EDI.
https://courier-demo-api.esphere.ru - тестовый Сфера.Курьер (Корус).
https://courier-api.esphere.ru - продуктивный Сфера.Курьер (Корус).
В случае, если REST Data Sources будет не хватать для нового ЭДО провайдера - будем развивать функционал Data Sources.
2. Создание Credentials для доступа к ЭДО провайдеру по API
По аналогии с Data Sources, нужно так же создать запись в системном журнале Credentials.
Пример заполнения с предзаполненными кредами от тестового ящика Citeck (Id - случайный):
3. Создание ящика с информацией об ЭДО провайдере
Заходим в системный журнал “Конфигурация ящиков ЭДО” (“EDI boxes configuration”) и создаем там запись о нашем ящике.
Пример:
В данной записи обязательно надо выбрать ЭДО провайдер. Сейчас доступны для выбора следующие ЭДО провайдеры (доступны для выбора, но поддерживался на момент написания статьи только Контур):
Атрибуты “URL” и “Авторизационные данные” содержат созданные в пунктах выше значения - выбираем соответствующий датасорс и креды.
После этого - вставляем идентификатор ящика и ключ разработчика.
P.S. ключ разработчика добавлен только на форму для Контур ЭДО провайдера. Иные провайдеры могут затребовать еще какие-то дополнительные данные.
4. Настройка интеграции с ЭДО провайдером в рамках ящика
Финальный этап настройки - заходим в системный журнал “Синхронизации”. Создаем запись интеграции ЭДО (это новый отдельный вариант создания, доступен для выбора по кнопке “+”):
Идентификатор и наименование - произвольные.
Чекбоксы “Включена” и “Необходимо перезапустить?” - стандартные атрибуты синхронизаций ECOS, пример описания другого типа синхронизации можно посмотреть здесь
В разделе “Базовая конфигурация” - необходимо выбрать ящик из пункта 3, и указать время блокировки и время лага в миллисекундах.
Время наложения блокировки - необходимо задавать для того, чтобы одновременно не запускалось более 2х интеграций для одного и того же ящика. Если значение не задано - блокировка будет накладываться на 2 часа.
Время лага - придумано для того, чтобы не обрабатывать события, которые произошли только что. Цель - не обрабатывать события, транзакция по которым в системе могла еще не завершиться. Рекомендуется ставить значение, хотя бы, 60 секунд (60000).
В разделе конфигурация шедулинга - указаны несколько атрибутов для шедулинга.
Опишу тут логику их работы:
Если задан CronExpression - джоба будет отрабатывать по CronExpression. Подробнее здесь: org.springframework.scheduling.support.CronTrigger.
Иначе, джоба будет работать периодично, раз в TriggerPeriod миллисекунд. Если задан InitialDelay - джоба не будет триггериться первые N миллисекунд. Если установлена галка FixedRate - отсчет времени до следующего триггирования будет начинаться только после того как завершилась работа по предыдущему триггированию. Подробнее здесь: org.springframework.scheduling.support.PeriodicTrigger.
Самый важный и интересный раздел - Конфигурация персистентности.
Camel endpoint - это эндпоинт Camel, в который будут поступать универсальные структуры события (Event). Данные события должны уметь быть отработанными в заданном роуте Camel. Рекомендуется использовать эндпоинты типа direct-vm, чтобы работала передача событий в посторонние контексты.
Список параметров, которые можно добавлять - это мапа String-String, которая будет прокидываться в сообщение с событием в Camel роут в виде Properties к CamelExchange.
5. Итоги
На этом, настройка завершена. Важно, что новая интеграция работает как несколько изолированных компонентов. Соответственно, настроив текущую интеграцию - надо подключить в микросервис OSGi бандл с классами для работы с диадок и OSGi бандл, ответственный за предоставление Camel контекста с поддержкой роута, указанного при настройке интеграции. Данные моменты будут уточнены и подробнее рассмотрены в следующих статьях данного раздела.