Принципы синхронизации данных
(бесплатная статья по Программированию в 1С)

Другие статьи по программированию:

«Как в 1С подготовить информационную базу у клиента»

«Как в 1С восстановить поврежденную базу «1С:Предприятие 8»»

«Как в 1С настроить список информационных баз»

Принципы синхронизации данных

Оглавление

• Общие принципы
• Планы обмена
• Универсальный обмен данными на основе КД
• Планы обмена + КД + Промежуточная база
• Архитектура ЦБ(8.х) ↔ МП (самописный обмен)
• Гибрид
• Какой вариант синхронизации выбрать?

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

Общие принципы

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

Ну тут сразу возникает как минимум две идеи:

• Использовать планы обмена;
• Использовать самописный вариант синхронизации;

Но я сразу добавлю еще и третий вариант – гибридный:

• Использовать самописный вариант синхронизации, но данные регистрировать при помощи планов обмена.

Давайте условно дадим каждому из этих вариантов краткую характеристику и попробуем выяснить их положительные и отрицательные стороны.

Планы обмена

Те, кто использовал ранее распределенные базы данных, знает на сколько это круто и удобно, но увы, с мобильными технологиями – это не реально. И это не реально не по той причине, что эта технология попросту не доступна в мобильном решении, а по той причине, что она не нужна. Почему? Давайте попробуем разобраться.

Какие у нас есть плюсы в использовании РБД?

• Переносимость структуры конфигурации в узлы, т.е. если мы что-то изменили в конфигурации ЦБ, то оно перенесется в узлы, и конфа узлов соответствует конфе ЦБ;

• Готовый механизм регистрации объектов и передачи их дальше в узлы, т.е. достаточно подстроить новый или существующий план обмена;

• Возможность создать первоначальный образ распределенного узла, с дальнейшим его разворачиванием в нужном месте;
• Куча готовых внешних обработок по обслуживанию и исправлению косяков.

Какие минусы, при переносе этого всего в область мобильной платформы:

• Переносимость структуры конфигурации в узлы, так как конфигурации в итоге являются идентичными – то это нас не устраивает, у нас, к примеру, нет партионного учета, нам не нужны все реквизиты в мобильном приложении;

• Готовый механизм регистрации объектов и передачи их дальше в узлы, так как передача данных выполняется при помощи сериализации объектов, а это возможно, только при выполнении первого пункта, то для нас это без толку;

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

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

Первые два пункта, которые являются самыми главными – абсолютно бесполезны в мобильной среде. Что, по большей части, сводит на нет все плюсы. Хотя, я не исключаю, что 1С-таки что-то придумает.

Но кроме РБД у нас еще есть и полные обмены, но у них тоже присутствуют эти критерии.

Универсальный обмен данными на основе КД

Вот тут уже становится все немного ближе, т.е. мы можем использовать КД (Конвертация данных) для настройки правил обмена между мобильной платформой и центральной базой данных, но тут есть одна проблема – ограничение мобильной платформы.

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

Планы обмена + КД + Промежуточная база

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

В итоге у нас выйдет следующая схема:

Давайте теперь посмотрим, что же происходит тут. Зелеными стрелочками я показал обмен данными, а красной – обмен конфигурацией. Т.е. логика проста – МП получает данные от ПБ, и от нее же получает конфигурацию. А ПБ обменивается данными с ЦБ.

В чем преимущество данной архитектуры:

• У вас одна и та же база для мобильного приложения и для стационарного;

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

• Нет необходимости конфигурировать ЦБ для реализации обменов, так как при обмене между ЦБ и ПБ – вы можете использовать типовой обмен данными при помощи «Конвертации данных»;

• Так как у вас метаданные в МП и ПБ будут идентичными, то для обмена между МП и ПБ – вы можете использовать план обмена;

• Вы не будете нагружать ЦБ лишними регламентами (о некоторых мы поговорим ниже);

Из недостатков:

• Использование ПБ – это еще одно звено, а чем меньше звеньев, тем стабильней;

Архитектура ЦБ(8.х) ↔ МП (самописный обмен)

Здесь зеленными стрелочками я выделил обмен данными, а красными – обмен конфигурацией.

Что особенного происходит в данном случае? У нас есть центральная база, в которой настроены планы обмена (соответственно мы «гоняем» данные из приложения в ЦБ и обратно), но одновременно у нас есть отдельная база, в которой мы пишем конфигурацию для мобильных телефонов.

Таким образом, ЦБ не должна располагаться именно на платформе 8.3, она может располагаться на любой платформе, просто в планах обмена (ну или чем вы там выберете делать обмен) нужно учитывать особенности разных платформ.

Минусы такого подхода очевидны – необходимо постоянно переделывать конфигурацию, нужно создавать новые планы обменов и/или web-сервисы и т.д.

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

Почему ЦБ должна иметь доступ в интернет, почему ЦБ на платформе 8.х? Все очень просто, самый удобный способ обмена – это обмен при помощи веб-сервисов. А они появились с 8.х и требуют выход базы в интернет.

Гибрид

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

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

Таким образом, вы получаете ряд преимуществ:

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

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

• В ЦБ вы выгружаете только заказы, и как практика показывает после выгрузки их редактировать нельзя, т.е. с ЦБ, в лучшем случае вы можете получать только список статусов заказов, ну там принят, отклонен, собран и т.д.

Так как у вас практически все будет гоняться между ЦБ и ПБ при помощи КД, и только заказы будут самописные, то, когда, наконец то, в мобильной платформе появятся запросы – вы очень быстро сможете вообще избавиться от ПБ и все перенести полностью на мобильный телефон, при минимальном редактировании ЦБ.

Какой вариант синхронизации выбрать?

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

К примеру, если вы выберете вариант самописного обмена, то вы должны понимать, что на любой чих клиента – вам придётся обновлять ЦБ, а если база работает 24/7? То я так думаю, что клиент вряд ли будет рад вашим обновлениям среди рабочего дня. Тогда вам подойдет второй или третий вариант.

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

PDF-версия статьи для участников группы ВКонтакте

Мы ведем группу ВКонтакте – http://vk.com/kursypo1c.

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке:
Ссылка доступна для зарегистрированных пользователей)