Разработка → 1C vs PHP. Глава 2. Поговорим?

Давным давно я начал писать мини-книгу про то, как же заставить 1С и PHP работать вместе.

За плечами ещё одна отличная интеграция, после которой появился ещё не один десяток мыслей.

А пока шишки, набитые от странностей PHP и 1С залечиваются - есть немного времени написать ещё одну главу.

В прошлой главе мы узнали, что можно между этими двумя системами найти общий язык. А теперь научим 1C и PHP говорить на выбранном нами языке.

И вот пришло время знакомства таких загадочных и замечательных систем!

Как же обмениваться информацией? Начнем с хороших и не очень способов и описания подводных камней.

1. FTP

Такой способ общения подойдет в том случае, если нужды в частом и быстром обновлении не было и нет - номенклатура обновляется раз в год, заказы ходят раз в 2 часа.

В данном случае посредником между 1C и PHP становится любой FTP сервер. На него складываются файлы в определенном формате, с определенными алиасами или ID.

По большей части в данном случае FTP будет располагаться на сервере, где находится сам сайт. Далее разделяем данные как входящие и исходящие (incoming/outgoing) методом каталогов. Добавляем необходимые параметры в имена файлов (ID, время, алиас типа данных).

Углубляться дальше - не стоит, пожалуй.

Плюсом является простая интеграция - из 1С обновления послать на FTP не сложно, если сайт расположен там же, где и сам FTP - никакого шаманства не понадобится.

Уже есть защита - это пароль сервера. Больше, скорей всего, и не понадобится.

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

Самое главное - это не забывать делать инкремент, чтобы не перечитывать файлы по несколько раз.

Пример:

Разберем на примере обновления товаров из 1С на сайт.

В течение 2 часов 1С следит за обновления товаров и при определенном кол-ве обновлений создает файл в нужном нам формате и заливает на FTP.

Допустим это формат XML. Имеем на FTP следующее:

/icoming/2.xml

/icoming/3.xml

/icoming/4.xml

/icoming/6.xml

Каждые 2 часа по крону срабатывает синхронизатор на PHP, смотрит на последний ID обновления (в нашем случае это 1) и смотрит далее на файлы, ID в имени файла которого больше 1. Забирает все файлы, парсит по очереди, выставляет себе ID 6 и уходит на покой.

2. HTTP/HTTPS

Здесь не обойтись без разделения на несколько пунктов - полет фантазии большой.

2.1 PHP - слушатель, 1С - рассказчик.

В данном случае мы улучшим актуализацию данных.

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

Самое главное - это рассчитать наилучший баланс кол-ва отсылаемых данных из 1С на сайт.

Если данные требуется держать актуальными постоянно - то лучше всего при изменении одного объекта в базе данных 1С - отсылать сразу обработчику на сайте. В данном случае, стоит выстраивать входящие данные в виде стэка и обрабатывать только по очередности отсылки данных. Лучше всего - если с данными приходит время их обновления на стороне 1С - тогда очередь будет выставлена грамотней и не произойдет ошибок обновления. Да, будут небольшие задержки, но лучше задержка в 1-2 секунды, чем неверные данные из-за неверной очереди.

Если постоянная актуализация не нужна - стоит взять в расчет, сколько объектов за раз может обновить PHP достаточно быстро и без больших нагрузок на сайт. Кол-во объектов приянять в расчет для 1С. Например, 1С обновляет каждые 15-20 объектов. Т.о. при накоплении этого объема - данные уходят на сайт.

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

1С, к сожалению, в данном случае может лишь опрашивать PHP скрипт о наличии обновлений.

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

Плюсом в данном случае является то, что ни 1C ни PHP не должны задумываться о том, какие данные им забирать.

1С формирует всё сам и отдает. PHP лишь обязать написать в лог, распарсить и обновить данные. 1С тоже не особо заботит, какой там по счету запрос - об этом должен думать PHP. Когда 1С обращается к сайту - PHP просто должен отдать все обновления с последнего времени обращения, записать время текущего обновления в лог и ждать следующего опроса.

Минус - данные в 1С не всегда будут актуальны.

2.2 PHP и 1C - рассказчики

Таким способом общения я уже задавался давно, но, к сожалению, на практике его применить так и не удалось и существует способ лишь в теории. Проблема в 1С - не найден способ "слушать" данные, приходящие извне. Была теория относительно веб-интерфейса 1С и общения средством SOAP. Ни один из них проверен не был, так что буду признателен любому, кто сможет применить способ на практике.

В теории всё просто и красиво. В предыдущем пункте 1С отсылал обновления данных в зависимости от их кол-ва и актуальности. В данном случае это будет делать и PHP.

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

Например, если обновления каталога присылаются из 1C в PHP и возможно обновление из PHP в 1С, то рано или поздно могут случиться расхождения при обновлении одного и того же объекта одновременно. Ещё хуже - обновления могут стать несовместимыми - где-то перенесена или удалена ветка каталога, а мы будем продолжать с ней работать.

Достаточно будет сравнивать входящие и исходящие данные. Но зачастую двусторонние обновления редки и всё будет упираться в оптимизации баз данных и разделения одного типа данных на несколько дискретных.

2.3 Сервер-посредник

Обдумывая данную статью пришла в голову одна идея - о создании сервера-посредника между 1С и PHP.

Т.о. обе системы являются и слушателями и рассказчиками, но не общаются напрямую - только через сервер, который хранит в себе обновления, разделяет их и ничем не занимается, кроме как обновлением данных.

Способ так же на практике ещё не существует, но это ещё только пока ;)

2.4 Защита

При таком типе обновлений защита - ведущий фактор.

Организовать её можно достаточно просто:

1. Использовать HTTPS - изначально он безопасней и данные не улетят куда не надо

2. Использование уникального ключа общения на стороне PHP и 1С - уникальные ключи, которые будут уходить с запросами на обновление данных - это как пароли. Если их переодически планово менять - шансы утечки данных ещё меньше.

3. Привязка к IP. А ещё лучше - привязка IP к ключам. Т.о. создается отличное правило - 1 IP адрес = 1 ключ.

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

maddogg

Вернуться к списку постов