API e-Mark: руководство для разработчиков

Рано или поздно в каждом проекте маркировки технический вопрос звучит одинаково: у нас есть учётные данные, почему интеграция — это не просто REST-запрос? Честный ответ в том, что API e-Mark — не универсальный поток данных, а регулируемая, состояние-зависимая система, и несколько архитектурных решений на старте определяют, останется ли интеграция надёжной при реальной нагрузке или незаметно сломается под объёмом. Что на самом деле предоставляет API API e-Mark охватывает несколько разных операций, а не одну: запрос и получение кодов DataMatrix, отправку событий оборота (код вошёл или вышел из оборота), проверку статуса кода или партии, регистрацию продукта и GTIN. У каждой операции свои лимиты запросов, свои сценарии сбоев и свои правила повторных попыток. Считать всё это одной задачей «вызвать API» — первая ошибка большинства интеграций. Учётные данные — это начало работы, а не её завершение Получить логин и пароль API от e-Mark — необходимое условие, а не результат. Как только у системы есть доступ, начинается настоящая работа: кто владеет учётными данными (сервисный аккаунт, а не личный логин), как они хранятся, и как происходит их замена, если разработчик или партнёр теряет доступ. Компании, которые откладывают этот вопрос, обычно в итоге хранят пароли там, где не следовало бы. Исчерпание и порядок кодов Коды DataMatrix выдаются конечными партиями. Интеграция, которая запрашивает коды по одному в момент печати, а не заранее формирует буфер, рано или поздно остановит производственную линию в ожидании ответа от API. Решение архитектурное: запрашивать коды заранее, локально отслеживать остаток и дозаказывать до того, как буфер опустеет — а не после того, как принтер уже простаивает. Повторные попытки без стратегии задержки наносят больше вреда, чем сам сбой Сетевой сбой не должен превращаться в дублирование событий оборота. Наивная логика повтора — вызвать API снова при любой ошибке — может отправить одно и то же событие дважды, а распутывать задвоенную запись оборота задним числом обходится намного дороже, чем сразу построить идемпотентные повторы. Каждая операция записи в e-Mark должна нести ключ идемпотентности или аналогичную защиту. Где в этом DataSync DataSync выступает как связующий слой между вашей ERP, складскими системами, принтерами и самим API e-Mark — берёт на себя буферизацию кодов, логику повторов, порядок событий оборота и сверку статусов, чтобы ваши внутренние системы работали с одним стабильным интерфейсом, а не управляли операционными деталями e-Mark напрямую. Если ваша команда планирует интеграцию, мы можем посмотреть на текущую архитектуру до того, как вы приступите к разработке. Часто задаваемые вопросы Нужны ли учётные данные API e-Mark до начала интеграции? Да — запросите их заранее: процесс подачи заявки и одобрения занимает время и не должен становиться тем, что тормозит сроки разработки. Может ли DataSync выполнить интеграцию полностью, или это должна делать наша команда? Работают оба варианта. DataSync может взять на себя всю интеграцию как управляемый слой либо работать вместе с вашими разработчиками над конкретными частями — буферизацию кодов и порядок событий оборота большинство команд предпочитают не строить с нуля. Что произойдёт, если буфер кодов закончится в разгар производства? Без предварительного резервирования линия будет ждать ответа от API в реальном времени — это реальный производственный риск. Буфер с порогом автоматического дозаказа полностью снимает эту проблему. Одинаков ли API e-Mark для всех товарных категорий? Операции одни и те же, но обязательные поля и данные по категориям могут отличаться. Уточните точную схему для ваших товарных категорий до финальной настройки маппинга полей.