1C vs PHP. Глава 1. Формат обмена данными.

Разработка → 1C vs PHP. Глава 1. Формат обмена данными.

Доброго времени суток тебе, читатель.

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

В нашем случае — конкретно будет про php5, но в целом — это будет просто теория, в которой примеров будет не так уж и много.

Итак, начнём с выбора способа общения. Выкинем сразу возможности прямого подключения из php к 1С и созданию демона — об этом я буду говорить гораздо позже, почти в конце нашей истории (надеюсь, что вспомню).

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

Но вот беда! Программист 1С (или системный администратор) даже не удосужился почитать про различные типы хранения данных, удобных для обработки. Мало того, не смотря на то, что на дворе уже давно 21 век и UTF-8 не просто сказка, а суровая реальность жизни — данные мы сможем получить только в кодировке windows-1251. Too bad.

В итоге на входе нашего синхронизатора мы получим, скорей всего, файл, который будет иметь весьма неявные очертания. Наверняка у него будут проблемы в форматированием, которое мы сможем только обрабатывать возможными и невозможными способами — не всегда можно объяснить, что 2 пробела и tab — это абсолютно разные символы. Не всегда понятно, почему в одной строке мы имеем Unix-like перенос строки, в другом — Windows-like, а в третьем так вообще в формате Мака. Это всё придётся угадывать. Долго и усердно обрабатывать все ситуации, пока, хотя бы, не сможем получить массив \ набор массивов, которые уже можно будет фасовать.

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

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

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

Границы должны быть чёткие и ясные! Если это товар — должно быть ясно, как я должен его получить из этого файла — начинается так, заканчивается так. Если это пользователь — тоже самое абсолютно. А то потом неожиданно у нас появляется товар «Пётр Петрович» или пользователь «Товары из Китая». Ну это же неправильно!

Сами значения должны быть не менее чёткие. Границы — также! Вообще подобные данные должны быть просто напросто унифицированны. Программисту должно быть побарабану — он просто должен одним движением получить массив с переменными… но и так находятся лишние пробелы, запятые, служащие разделителями и прочая ахинея, которая не поддаётся интерпретации…

Пожалейте программистов! Очень тяжело работать с файлами в нескольком сотен тысяч строк, без документации и сидеть угадывать просто напросто, как же это будет работать. А теперь о верном способе решения.

Сходу на ум приходят 3 весьма отличных формата для хранения и переноса данных: XML, YML, JSON. Все форматы отлично форматированны и каждый имеет свои свойства, которые можно применить в той или иной ситуации.

Теперь подробнее:

XML

Старый добрый XML. Лучше не сыскать. Особенно когда данные являются древовидными изначально — это облегчит жизнь парсеру и программисту, создающему его.

Дерево, затем, очень легко будет простроить и, отталкиваясь от него, построить верное дерево в базе данных сайта. Да, без рекурсии здесь не обойтись, но есть замечательный способ хранения деревьев — это Materialized path. По сути — самое обычное построение путей как в любой операционной системе — от корня к детям.

Т.е., допустим, та или иная ветвь будет иметь путь, вроде: root/child1/child2/child3

Поверьте, парсится подобное в любом языке программирования просто на ура, даже можно будет обойтись почти без рекурсии — просто обычный обход. Рекурсия будет использоваться лишь при поиске пути, да и то, если верно составлен XML — файл, то там всё пройдёт ну оооочень быстро, exec в помощь.

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

<user_list>

 <user status=«new»>

   <id>2</id>

   <login>ppetr</login>

   <name>Пётр Петрович</name>

   <phone>8 666 123-45-67</phone>

 </user>

 <user status=«update»>

   <id>1</id>

   <name>Сидр Сидорович</name>

 </user>

</user_list>

Разве не ясно, что нужно с этим делать. Помоему, вполне наглядно. Или вот дерево: <product_tree>

 <product>

  <id>1</id>

  <parent_id>NULL</parent_id>

  <name>Name 1</name>

  <children>

    <product>

      <id>2</id>

      <parent_id>1</parent_id>

      <name>Name 2</name>

    </product>

  </children>

 </product>

</product_tree>  

Дерево видно? Видно. Оно легко парсится и получается структура. В базе данных сайта вы уже можете хранить это как угодно — порядок занесения записей уже задан, вы не ошибётесь и не придётся строить дерево самому по id и parent_id 

YAML 

Отличный формат. Обожаю его за его простоту. Очень хорош для «плоских» структур, где нет никаких ветвлений. 

Он прост и понятен. Если база данных небольшая — используйте именно его, будет проще, чем с XML.

Единственной его проблемой является строчность и привередливость к форматированию. Но тут, опять же, всё зависит от прямоты рук программиста. Отступы задать не проблема. Сделать огромный текст в виде одной строки тем более не должно составлять проблем.

Пример:

products:

 product_1:

   id: 1

   name: «Name 1»

 product_2:

   id: 2

   name: «Name 2»

API имеется под множество языков. Один верный файл — и массив уже у вас в руках, достаточно вызвать функцию, передав ей файл или же саму структуру. Всё просто и легко. Только верное форматирование, а дальше уже данные легко будут раскинуты по нужным полочкам.

JSON

Да, он рассчитан по большей части на Javascript, но от этого менее полезным хранилищем не является. Ну приспичит данные сразу в JS передавать! А тут опа — они уже в нужном формате.

К тому же JSON очень хорош будет и для обычной передачи данных. API для него множество для всех языков. Не буду вдаваться в подробности — способ весьма хорош.

Да, я знаю что 1С не пестрит инструментами для обработки всех трёх языков, но чем изобретать свой формат — почему бы не подготовить почву для уже готового формата?

Данные, на самом деле, уже готовы. Задача не слишком велика — получить хотя бы стандартный набор выгрузки данных в чистом виде…. А дальше уже кастомизация определённая под нужды сайта, заказчика и улучшения процесса в целом.

maddogg

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