Доработка обмена данными между 1С и Битрикс

Загрузка (выгрузка) данных на сайт и поддержание их актуальности (довыгрузка) - одна из самых первых задач, с которыми сталкиваются владельцы интернет-магазинов. И самая важная, ведь если нет данных - то нечего продавать, и остальные работы по созданию интернет-магазина парализуются.

При работе с Битриксом существует несколько подходов к выгрузке данных:

              

1) Используем стандартную выгрузку Битрикс. При этом у нас должны быть данные на стороне 1С без всяких правок/допиливаний самой системы. Отталкиваемся от возможностей этой выгрузки. Если что-то не так или не нравится - правим данные на стороне 1С, чтобы получить желаемый результат.

2) Берем за основу стандартную выгрузку и немного правим. Важно условие - объем дорабатываемых задач должен быть мал, а сами задачи не должны выходить далеко за рамки стандарта.

3) Пишем выгрузку с нуля, отталкиваясь от определенных целей и задач. 

Как легко догадаться, первый вариант легче, быстрее и, в конечном счете, дешевле, если номенклатура ведется стандартным образом и выгружается “как есть”. Минус - относительная неповоротливость стандартной выгрузки. Нельзя реализовать функционал, который не входит в коробку. Правда дополнительный модуль от 1С-Битрикс очень сильно облегчает многие задачи по выгрузке, поэтому практически всем клиентам мы рекомендуем ставить дополнительный модуль обмена (он бесплатен). Последний способ - сложнее, дольше и дороже. Плюс - гибкость и возможность реализовать практически любые задачи по передаче данных.

При предварительном анализе выгрузки следует отталкиваться от первого варианта. Если он невозможен - то второй. Если и он не подходит (особенно, если 1С существенно модифицирована), то третий.

Если определено, что стандартный модуль обмена не подходит и  нужно писать выгрузку с нуля, то можно опираться на ряд требований, которым должна соответствовать хорошая выгрузка данных:

  • Масштабируемость: подходит как для загрузки небольшого количества товаров, так и для огромного каталога
  • Управляемость: имеет ряд настроек в админке, которые позволяют быстро изменить поведение
  • Надежность: готова к возникновению нестандартных и исключительных ситуаций (+самоконтроль, перекрытие, самодиагностика)
  • Модульность: состоит из независимых частей, которые могут быть запущены автономно
  • Согласованность: независимые модули могут объединяться в общий план исполнения
  • Прозрачность: вы в любой момент можете узнать, чем именно она занята, есть ли ошибки
  • Гибкость: каждый скрипт выгрузки может быть запущен со своими параметрами, влияющими на его поведение
  • Безопасность: выгрузка не должна предоставлять доступ (даже случайный) к конфиденциальной информации и должна быть защищена от несанкционированного запуска

Масштабируемость

Часто бывает так, что код, написанный для загрузки полной номенклатуры, не подходит для импорта маленькой части товаров (например, измененных за небольшой промежуток времени). И, наоборот, выгрузка небольшого количества товаров не может быть распространена на весь каталог. Мы считаем, что это две части одного и того же процесса, и это надо учитывать на самых ранних этапах проектирования. В любой момент может возникнуть необходимость перевыгрузить ВЕСЬ каталог (с сотнями тысяч позиций) на уже рабочем сайте.

Управляемость

Имеет смысл продумать ряд параметров, которые могут влиять на общий процесс импорта данных и которые будут доступны прямо в админке сайта. Например:

  • Общий флаг, разрешающий или запрещающий выгрузку
  • Интервалы запуска (в минутах), в т.ч. интервал архивирования лог-файлов
  • Максимально допустимое время работы, считающееся нормальным (превышение этого лимита должно приводить к оповещению ответственного лица по e-mail)
  • Путь к основной папке выгрузочных XML, относительно которой будут простраиваться все остальные пути
  • Идентификаторы задействующихся инфоблоков
  • Последовательность запуска этапов выгрузки (разделы, товары, цены, остатки, изображения и т.д.)
  • Список e-mail адресов, на которые будут отправляться уведомления

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

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

Надежность

Кажется вполне убедительной мысль, что перед каждым своим запуском скрипты импорта данных должны убедиться в том, что выполнены хотя бы самые необходимые условия для их корректного функционирования. Тем не менее, это требование соблюдается далеко не всегда. Что можно проверять перед каждым запуском? Как минимум,

  • Достаточно ли на жестком диске свободного пространства
  • Не запущена ли выгрузка в данный момент (чтобы не возникало несколько процессов, выполняющих одну и ту же задачу и вступающих в конфликт)

Также выгрузка должна учитывать ряд лимитов, превышение которых должно считаться ненормальным. Например, аномально длинное выполнение. Возможно, процесс просто оборвался (выключением питания) - и не сумел об этом сообщить. Другой пример - нетипично большой расход оперативной памяти. Это может навести на мысль ошибки в алгоритме, которую надо локализовать. Во всех этих случаях скрипты должны отправлять как минимум e-mail уведомления.

Должны обрабатываться ситуации фатальных ошибок из-за нехватки памяти или превышения лимитов выполнения самого php (memory_limit и max_execution_time). В этих случаях скрипты могут корректно завершить текущий этап, предоставив необходимую информацию для корректного продолжения при следующем запуске. На всякий случай рекомендуется отправка почтового уведомления.

Модульность

Создание единой, монолитной выгрузки - плохая идея. Гораздо удобнее, если она состоит из максимально автономных частей, которые могут быть запущены независимо (при одном и том же наборе XML-файлов). Например, выгрузка товаров и их изображений можно разделить. Это очень удобно, когда есть возможность просто загрузить изображения, не обновляя другую информацию товаров. Аналогично можно разделить выгрузку цен, общих остатков и остатков по складам.

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

Однако сама по себе модульность не так хороша, как в системе с согласованностью.

Согласованность

Разделяя общую выгрузку на отдельные части, мы быстро поняли, что должен быть какой-то объединяющий все этапы модуль. Допустим, вся наша выгрузка делится на ряд этапов:

  • Загрузка складов
  • Типов цен
  • Единиц измерений
  • Справочников
  • Товарных категорий (разделов)
  • Общей информации о товарах
  • Ценовых предложений
  • Остатков
  • Изображений

Каждому из этапов соответствует свой скрипт. Управлять запуском и интервалом каждого из них в отдельности - неудобно. Увеличивается количество cron-заданий, увеличивается объем работы при переезде на другой сервер. Повышается вероятность возникновения ошибок из-за неправильно настроенного запуска.

Было бы проще, если бы был единый скрипт выгрузки, который делал бы всю “грязную работу” за нас: управлял последовательностью и запуском отдельных модулей, отслеживал возникающие ошибки, сообщал о них, отражал текущий статус (что происходит в данный момент), временные параметры и пр.

Согласованность заключается в том, что этот интегративный скрипт может контролировать перекрывающий запуск выгрузки: какой-то скрипт работает в данный момент, и параллельно инициируют запуск другого. Эти ситуации должны строго пресекаться.

Прозрачность

Все скрипты должны вести подробные логи. Что-то показалось странным - запишите в лог. Исключительная ситуация - запишите в лог. Обработано n-ое количество элементов - запишите в лог. Тут логика проста - если есть лог-файл, то есть возможность проследить, как происходила работа; если нет файла - то нет такой возможности. И понять причину возникающих ошибок будет гораздо сложнее.

Но здесь нужно помнить о том, что избыточное разрастание логов тоже приносит вред - дисковое пространство нужно экономить. Поэтому сразу нужно написать скрипты по архивированию логов.

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

Гибкость

Каждый модуль выгрузки может иметь ряд параметров, влияющих на режим его работы (это могут быть простые GET-переменные). Например, это могут быть такие настройки:

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

Благодаря наличию этих нехитрых настроек, можно решить сразу несколько задач:

  • Запустить всю многоэтапную выгрузку с самого начала
  • Запустить всю выгрузку, начиная с конкретного этапа
  • Запустить только данный скрипт (модуль)

Безопасность

Все лог-файлы, размещенные на сервере, должны быть надежно защищены. Как вариант, можно использовать в качестве логов файлы с расширением *.php, на которые распространяются права доступа Битрикс. В таком случае можно спокойно делиться ссылкой на лог как обычным URL. Если перейти по этому адресу, откроется стандартная форма авторизации (логи доступны только администраторам). Все выгрузочные скрипты должны быть защищены от несанкционированного запуска.