На этой странице
Инструкции описывают рабочие сценарии. Доступность действий зависит от конфигурации UNIUM и прав вашей организации.
Начните с рабочего события
Интеграция должна продолжать конкретный процесс: передать организацию, обновить статус документа, получить результат исполнения или загрузить согласованный справочник. До выбора технологии опишите событие, исходный объект и ожидаемое изменение в системе-получателе.
Для каждого обмена назначьте владельца данных и технического владельца. Первый определяет смысл и правила изменения, второй — доставку и диагностику. Если поле меняется в двух системах, заранее установите приоритет и порядок разрешения конфликта. Иначе успешный обмен может перезаписывать верные данные.
- Что запускает обмен и какие записи должны участвовать?
- Какая система является источником истины для каждого поля?
- Как быстро результат нужен следующему участнику процесса?
- Как пользователь узнает об ошибке и кто её разбирает?
- Какие данные действительно нужны получателю?
Составьте паспорт обмена
| Раздел | Содержание |
|---|---|
| Сценарий | Событие, цель и границы процесса. |
| Контракт | Версия спецификации, операции, поля и обязательные значения. |
| Сопоставление | Ключи организаций и объектов; обработка отсутствующих связей. |
| Доступ | Сервисный субъект, область и необходимые полномочия. |
| Доставка | Частота, порядок, повторы и подтверждение результата. |
| Эксплуатация | Мониторинг, журнал ошибок, владелец разбора и критерий восстановления. |
Сценарий: передача согласованной организации
Источник истины: утверждённый справочник заказчика
Получатель: согласованный контур UNIUM
Ключ сопоставления: определяется контрактом
Повторная доставка: не создаёт повторный объект
Конфликт: направляется владельцу данных
Приёмка: запись, её поля и связи проверены в обеих системахПаспорт должен позволять новому специалисту восстановить смысл обмена без личной переписки. Приложите обезличенные примеры корректной записи и ошибок. Реальные URL, параметры и способ авторизации берите из спецификации поставки.
Выберите способ доставки по условиям процесса
| Способ | Когда рассматривать | Что проверить |
|---|---|---|
| Синхронный запрос | Ответ нужен для продолжения текущего действия. | Таймаут, недоступность и неопределённый результат изменения. |
| Событийная доставка | Получатель может обработать изменение отдельно. | Порядок, повторы, подтверждение и задержка обработки. |
| Пакетная загрузка | Нужно перенести большой набор или обновлять его по расписанию. | Частичные ошибки, контроль объёма и возобновление. |
Выберите механизм обмена из спецификации API: события, пакетную передачу или запросы по расписанию. Учитывайте объём данных, допустимую задержку и ограничения методов.
При асинхронной обработке различайте получение сообщения и применение изменения. Подтверждение приёма не всегда означает, что запись прошла проверку и стала доступна пользователю. Уточните, как получать итоговое состояние.
Сохраните идентификаторы и связи
Используйте устойчивый ключ сопоставления, согласованный с владельцами систем. Он должен различать организации и объекты без раскрытия ненужных внутренних идентификаторов. Название компании или документа обычно недостаточно: оно может измениться или совпасть.
Для связанных объектов определите порядок создания. Если документ ссылается на организацию, получатель должен уметь сопоставить организацию до применения связи. Отсутствующая запись требует понятного решения: отложить обработку, отклонить строку или создать объект предусмотренным способом.
- Опишите правила дублей и повторной доставки.
- Разделите очистку поля и отсутствие поля в сообщении.
- Уточните поведение при архивировании или удалении источника.
- Проверьте версию записи и конфликт параллельных изменений.
- Храните результат сопоставления так, чтобы его можно было проверить при разборе.
Проектируйте отказ вместе с успешным сценарием
После таймаута изменяющего запроса неизвестно, успела ли система применить операцию. Слепое повторение может создать дубликат. Нужен подтверждённый контракт идемпотентности либо способ установить результат исходной операции.
Ошибки данных отделяйте от временной недоступности. Исправление обязательного поля требует участия владельца данных; увеличение числа повторов не поможет. Для временных ошибок задайте ограниченную стратегию повторов, учитывающую лимиты и правила сервиса.
| Ситуация | Ожидаемое поведение |
|---|---|
| Повтор того же сообщения | Нет повторного объекта или повторного необратимого действия. |
| Таймаут после отправки | Результат устанавливается предусмотренным способом до нового изменения. |
| Конфликт версии | Нет незаметной перезаписи; зафиксировано решение по конфликту. |
| Истёкшие полномочия | Обмен приостановлен управляемо, ответственный получает сигнал. |
| Отсутствующая связь | Ошибка содержит контекст для исправления и повторного разбора. |
| Частичный пакет | Успешные и ошибочные строки различимы; повтор не дублирует результат. |
Доступ, наблюдаемость и приёмка
Сервисному субъекту выдавайте права только для данного обмена. Определите место хранения секретов, процедуру замены и отзыва. Проверяйте ограничения по организации, объектам и действиям, включая связанные сущности.
В журнале нужны время, тип операции, идентификатор обмена и результат обработки. Тело запроса целиком может содержать лишние персональные данные; сохраняйте только согласованный диагностический набор. Секреты и данные авторизации в журнал не помещайте.
Приёмка должна подтвердить не только передачу, но и смысл результата: правильные поля, связи, состояние и отсутствие дублей. После тестового сбоя проверьте восстановление очереди или пакета, состояние исходных данных и возможность ручного разбора.
Нужна помощь с вашим сценарием?
Опишите задачу и раздел системы. Команда UNIUM поможет разобраться в рабочем сценарии.