Экстренная разработка и внедрение скрипта синхронизации с "МойСклад"

Срок выполнения: 2 дня

Инициатива: Экстренный запрос клиента, работа без финального ТЗ — "делаем, чтобы работало, а потом допилим"

Клиенту потребовалось экстренное решение: автоматизировать обновление остатков и цен по товарам между собственной БД и системой "МойСклад". Основная цель — обновление данных каждые 3 часа с консолидацией остатков по виртуальным складам (Санкт-Петербург и Москва). Решение нужно было внедрить в кратчайшие сроки, без детального технического задания (ТЗ), с возможностью последующих доработок.

Условия:

• Отсутствие финального ТЗ, только устное описание задачи.

• Сжатые сроки

• Необходимость гибкой архитектуры для будущих улучшений.

Почему это важно:

Для клиента, работающего в сфере розничной торговли, актуальность данных об остатках и ценах критически важна для управления продажами и складскими операциями. Автоматизация синхронизации позволила бы сократить ручной труд, минимизировать ошибки и повысить эффективность бизнеса. Экстренность запроса подчеркивала необходимость оперативного решения, сохраняющего потенциал для масштабирования.

Мы разработали и внедрили скрипт на C#, обеспечивающий автоматическую синхронизацию остатков и цен между внутренней базой данных и «МойСклад» через REST API. Скрипт работает по расписанию (каждые 3 часа), поддерживает консолидацию данных по виртуальным складам СПБ и МСК, включает обработку ошибок с логированием и опциональными уведомлениями (Telegram/Email). Решение сопровождается документацией и готово к дальнейшим доработкам, таким как добавление новых складов или фильтрации по категориям товаров.

Ценность для заказчика:

• Оперативность: Скрипт был внедрён за 2 дня, решив срочную проблему клиента.

• Надёжность: Стабильная работа без ошибок, подтверждённая тестами, обеспечила доверие к решению.

• Гибкость: Модульная структура и конфигурация через .env позволяют легко адаптировать скрипт под новые требования.

• Экономия ресурсов: Автоматизация устранила ручное обновление данных, сократив трудозатраты и ошибки.

Почему такой подход? 

C# был выбран за его простоту, мощные библиотеки для работы с API и базами данных, а также за скорость разработки, критично важную для сжатых сроков. Использование REST API «МойСклад» обеспечило надёжную интеграцию, а модульная архитектура и конфигурация через .env сделали решение масштабируемым и безопасным. Такой подход позволил не только решить текущую задачу, но и заложить основу для будущих улучшений.

 Получили устное описание задачи

– Получили доступ к структуре внутренней базы данных (MySQL) и изучили ключевые таблицы: товары, остатки, цены, склады.

– Проанализировали документацию REST API «МойСклад», проверили доступные эндпоинты для работы с остатками и ценами.

– Уточнили правила консолидации: объединение остатков по id_product с разделением на виртуальные склады СПБ и МСК на основе физического распределения.

Ключевые решения и почему:

– Быстрая диагностика: Вместо ожидания формального ТЗ мы собрали требования через прямое общение, что сэкономило время.

– Фокус на ключевых данных: Сконцентрировались на минимально необходимых полях (id_product, остатки, цены, названия), чтобы избежать перегрузки на старте.

– Подготовка к масштабированию: Уже на этапе анализа учли возможность добавления новых складов или фильтров в будущем.

Быстрый анализ позволил приступить к разработке в тот же день, минимизировав задержки. Уточнение требований напрямую с клиентом обеспечило точное соответствие ожиданиям.

– Разработали базовый скрипт на C#

– Настроили конфигурацию через файл .env для хранения чувствительных данных (API-ключи, параметры подключения к БД).

– Реализовали выборку данных из базы: остатки, цены, названия и id_product.

– Собрали виртуальные склады СПБ и МСК на основе физического распределения через View таблицы в базе

– Подключились к REST API «МойСклад» с использованием авторизации по логину и паролю.

– Реализовали модуль обновления остатков через создания документов прихода и ухода товара, а так-же изменение цен через прямое изменение товара

– Добавили обработку ошибок: логирование в файл log.txt с временными метками и подробностями (например, HTTP-ошибки, таймауты).

Некоторые товары отсутствовали в «МойСклад», что вызывало ошибки. Добавили проверку существования id_product перед отправкой запроса.

Настроили повторные попытки (retries) для API-запросов с экспоненциальной задержкой, чтобы минимизировать сбои при нестабильном соединении.

– Настроили задачу используя Quartz для запуска скрипта каждые 3 часа

– Провели тестирование трёх последовательных запусков, проверив корректность обновления остатков и цен.

– Убедились, что логирование работает корректно, а критические ошибки отсутствуют.

Почему так?

Quartz –  Простое и надёжное решение для автоматизации, не требующее сложной инфраструктуры. Это позволило быстро внедрить расписание.

Тестирование запусков –  Многократные запуски в реальных условиях подтвердили стабильность скрипта, исключив риск сбоев при регулярной работе.

В итоге автоматизация устранила необходимость ручного запуска, экономя время сотрудников. Стабильность запусков обеспечила уверенность в непрерывной синхронизации данных.

–  Скорость: Экстренный запрос требовал максимальной оперативности. Параллельная работа (анализ, разработка, тестирование) позволила уложиться в 2 дня.

–  Минимализм с перспективой: Скрипт был простым, но с модульной структурой, что исключило «костыли» и облегчило доработки (например, добавление новых складов или фильтров).

–  Гибкость: Конфигурация через .env и разделение логики на модули сделали скрипт адаптивным к изменениям, таким как новые API-эндпоинты или параметры синхронизации.

–  Надёжность: Логирование, обработка ошибок и уведомления обеспечили прозрачность и устойчивость решения, минимизировав риски сбоев.

Альтернативы и почему их не выбрали:

–   Монолитный скрипт: Отказались, так как он усложнил бы доработки и отладку.

–   Сторонние платформы (например, Zapier): Рассматривались, но отклонены из-за высокой стоимости и ограниченной гибкости по сравнению с кастомным скриптом;