Обсудить задачу
Автоматизация

Skirbo +
MuleSoft Anypoint / Mule Runtime

Предлагаем контракт складского задания и обратного результата, в котором бизнес-ID, сохранение факта и область повторов определены до реализации.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
Команда складского исполненияERP → Mule → SkirboОбсудим в составе подключения

Сохранить бизнес-ID, версию, владельца и строки.

Факт исполненияSkirbo → Mule → ERPОбсудим в составе подключения

Отдельное подтверждение принятия документа.

Ошибка контракта/повтораMule → владелец интеграцииОбсудим в составе подключения

Неизвестный SKU, повтор и недоставка различаются.

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

Область — конкретный Mule-поток и его версия runtime в Anypoint-проекте клиента. Политики API, трансформация, хранение сообщений и складская бизнес-операция имеют отдельные границы.

Как организовать обмен

Официальная документация подтверждает платформу API/интеграций и отдельные механизмы runtime. Транспорт и контракт ERP/Skirbo выбираются по проекту; вымышленные endpoint не задаются.

Предлагаемый порядок работы

  1. ERP передаёт разрешённую версию заказа в опубликованный клиентом API или иной согласованный вход Mule.
  2. Поток проверяет организацию, бизнес-ID, строки и единицы; трансформация сохраняет исходные ключи.
  3. Вход Skirbo принимает одно задание нужного клиента, а оператор выполняет физическую сборку.
  4. Факт исполнения сохраняется со складским ID независимо от последующей доставки ERP.
  5. Обратный поток передаёт факт и проверяет принятие бизнес-документа ERP.
  6. При тайм-ауте повторяют только операцию с установленным правилом идемпотентности; повтор всего блока после выполненной отгрузки запрещают проектным контрактом.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Корпоративный заказ через Mule

Задача: Пропустить одно согласованное задание и подтвердить физический результат.

Когда начинается: ERP передаёт разрешённую версию заказа в опубликованный клиентом API или иной согласованный вход Mule.

  1. ERP передаёт разрешённую версию заказа в опубликованный клиентом API или иной согласованный вход Mule.
  2. Поток проверяет организацию, бизнес-ID, строки и единицы; трансформация сохраняет исходные ключи.
  3. Вход Skirbo принимает одно задание нужного клиента, а оператор выполняет физическую сборку.
  4. Факт исполнения сохраняется со складским ID независимо от последующей доставки ERP.
  5. Обратный поток передаёт факт и проверяет принятие бизнес-документа ERP.
  6. При тайм-ауте повторяют только операцию с установленным правилом идемпотентности; повтор всего блока после выполненной отгрузки запрещают проектным контрактом.

Результат: ERP и склад сходятся по одному исполнению.

Если возникло исключение

  • Idempotent Validator полезен, но его срок хранения и выбранный ID должны соответствовать бизнес-периоду повторов.

Повтор после частичного успеха

Задача: Не повторять запись склада из-за ошибки следующего процессора.

Когда начинается: Первый процессор создал задание, а последующий вызов ERP завершился ошибкой.

  1. Первый процессор создал задание, а последующий вызов ERP завершился ошибкой.
  2. По сохранённому бизнес-ID проверяют состояние обеих систем и отделяют выполненную часть.
  3. Повторяют только отсутствующее подтверждение; ручной разбор получает точные результаты предыдущих действий.

Результат: Повтор транспортного шага не становится новым складским заданием.

Если возникло исключение

  • Until Successful повторяет все процессоры внутри своей области; расположение операций требует проверки.

Ввод нового склада в корпоративный контракт

Задача: Добавить точку исполнения без поломки клиентов старой схемы.

Когда начинается: Владелец API определяет код склада и версию сообщения.

  1. Владелец API определяет код склада и версию сообщения.
  2. На контрактных примерах проверяют преобразование, неизвестные коды и обратный результат.
  3. После адресного включения сверяют факты нового склада с ERP и журналом потока.

Результат: Новый склад имеет собственную область данных и проверенный маршрут.

Если возникло исключение

  • Совместимость старых версий и политика API не устанавливаются названием платформы.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
ЗаказERP/OMSMule не меняет коммерческий смысл при трансформации.
SKUКаталог клиентаТрансформация сохраняет вариант и единицу.
ОстаткиSkirbo для физического складаПоток маршрутизирует факт, не вычисляет новый остаток без правил.
СтатусыERP/Skirbo; Mule — доставка сообщенияУспех процессора не доказывает отгрузку.
ДокументыERP/ЭДОответ API отделён от учётного принятия.
ВозвратыERP — разрешение; склад — приёмкаВозвратный факт имеет отдельный бизнес-ID.
Доступ, версии и разбор ошибокНазначенные владельцы платформы, учёта и складаВладелец Anypoint согласует версию потока, API-политику и область повторов. Владелец ERP утверждает учётный документ; склад подтверждает количество и состояние. Доступ к Object Store и прикладные права клиента проверяются независимо от административной роли платформы.

Что обсудить перед пилотом

  • Какой ID используется для обнаружения повтора?
  • Где сохраняется результат внешней записи?
  • Кто разбирает успешный первый шаг при неуспехе второго?
Перед оценкой

Что нужно уточнить

  • Версия Mule Runtime и схема действующего потока.
  • Контракт заказа/исполнения и бизнес-ID.
  • Настройки хранения обработанных ID и области повторов.
  • Контакт владельца API и инструкция разбора частичного успеха.
  • Указать сохраняемый бизнес-ключ tenant/источник/заказ/версия/исполнение, а не полагаться на новый correlationId каждой попытки.
  • Раздельно назначить владельца Mule flow, API-контракта ERP, факта склада и журнала внешних результатов.
Границы сценария

Что учесть заранее

  • Механизм повторов runtime не гарантирует однократное выполнение внешней операции.
  • Idempotent Validator по умолчанию не следует считать долговечным бизнес-журналом; настройки необходимо проверить.
  • Коннектор ERP и политика API оцениваются отдельно от платформы.
  • Региональная доступность договора и развёртывания проверяется для организации.
  • Сохраняемая переменная внутри неуспешной области Until Successful не является журналом уже совершённых внешних действий.
  • Настройки Object Store проверяются у конкретного компонента; свойства общего хранилища приложения не приписываются автоматически Idempotent Message Validator.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

Покажите схему Mule-потока, область повторов и пример команды складу — проверим, что произойдёт при потере ответа.

Вопросы о подключении

Достаточно включить Idempotent Validator?

Нет. Нужно выбрать устойчивый бизнес-ID, хранение и срок удержания, а также проверить повтор на стороне склада после потерянного ответа.

Почему опасен Until Successful вокруг нескольких действий?

Документация говорит о повторе всех процессоров блока. Если одно действие уже создало объект, повтор без защиты может его продублировать.

Нужно менять ERP?

Сначала определяют существующий контракт. Возможно сохранить ERP и добавить отдельный складской API, но это проектное решение.

Можно запомнить ID созданной отгрузки только в переменной внутри Until Successful?

Это недостаточно: следующая попытка начинает с переменных до блока. В проекте нужен независимый сохранённый результат внешнего действия и проверка по бизнес-ключу после потерянного ответа.

Возврат должен иметь тот же ключ, что исходная выдача?

Нет. Он ссылается на исходное исполнение, но получает собственный ключ операции и подтверждение приёмки. Иначе защита от повторов может ошибочно отбросить реальный возврат или повторить выдачу.

Интеграция уже готова?

Изучаем возможность связи со Skirbo. Ни готовый коннектор, ни приёмка обмена для вашего кабинета пока не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Изучаем возможность

Автоматизация

Albato

Связка внешних приложений со складским процессом через согласованный сценарий.

Сценарий подключения
Изучаем возможность

Автоматизация

Boomi Integration

Связь корпоративного интеграционного контура с операциями фулфилмента и контролем результата.

Сценарий подключения
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

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

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.