Comments 10
Если вы тоже сталкиваетесь с задачами интеграции 1С и e-commerce или думаете, как оптимизировать обмен данными в своем проекте, пишите нам.
Классная идея со сбором данных о желаемом количестве товаров, может сильно помочь в планировании продаж.
Интересная статья, спасибо! Cразу возник практический вопрос: насколько сложно внедрить подобные практики (например, регулярные выражения для валидации) в уже существующий большой легаси-проект, где кодовая база не всегда идеальна? С чего лучше начать, чтобы не сломать то, что уже работает, и не вызвать сопротивление у команды?
Спасибо за вопрос! В легаси-проектах главное — не пытаться внедрить всё сразу. Лучше идти маленькими шагами: выбрать один понятный кейс, обернуть его простыми тестами и добавить «мягкую» валидацию (сначала просто логировать ошибки, не ломая процесс).
Так команда видит, что изменения реально помогают, а не мешают. Со временем проверки можно сделать строже и расширить на другие участки кода. Такой постепенный подход снижает риски и сопротивление внутри команды.
на практике - проблема в том что екомер уж боьнот разеый.
Редко удается отобразить данные как есть.
Как вы решаете задачу, если объект со ссылкой на другой объект приходит раньше, чем появляется ссылочный объект?
Если объект ссылается на то, чего ещё нет, мы его не теряем, а сохраняем «в ожидании». Когда связанный объект приезжает, система достраивает связь. Если он так и не появился, то отмечаем ошибку и можно повторно запросить данные. Так порядок прихода уже не критичен.
Так вы всю цепочку зависимых объектов ставите в ожидание в таких случаях? Может стоило создавать болванки, чтоб было на что ссылаться, а когда объект приезжает уже перезаписывать? Как то более разумно выглядит
Если зависимых объектов несколько, то да, они тоже уходят в «ожидание», пока не появится ключевая сущность. Это позволяет держать целостность и не плодить пустые записи.
Подход с болванками мы тоже рассматривали. Он выглядит логично, но в больших обменах приводит к куче «пустышек», которые потом трудно отличать от реальных данных. В результате выше риск ошибок и лишних связей.
Мы нашли баланс: для критичных сущностей (например, клиент) иногда создаем минимальную «болванку», чтобы можно было на неё сослаться. Но в общем случае проще и надежнее держать в статусе ожидания и достраивать, когда данные реально пришли
Визуализация обмена с 1С: синхронизация заказов, остатков и контрагентов для e-commerce