Я тут попробовал новый для себя жанр писанины – «типовые письма». Это как типовая конфигурация – решение, предназначенное для определенной цели. Может адаптироваться под клиента, если требуется. Но, в целом, содержит в себе всё необходимое, даже чутка избыточно.
Причины две: я работаю во франче и я ленивый. Мне надоедает говорить или писать одно и то же по несколько раз. Поэтому стал писать «типовые письма», надеясь, что их несколько неформальный стиль понравится клиентам, и я смогу «продать» нужное решение.
Пока вроде получается, поэтому решил с вами поделиться каким-нибудь примерчиком. Вдруг формат будет интересен, я тогда ещё чего-нибудь опубликую.
Ситуация
Ситуация, на самом деле, нестандартная. Клиент покупает достаточно редкую конфигурацию, ему нужно организовать работу с базой из двух территориально распределённых точек. Клиент переживает, что будут перебои в работе, если отвалится интернет. Клиент знает, что на свете есть РИБ. Уже знает, что в его конфигурации нет РИБа. Спрашивает, можно ли сделать, сколько стоит, чё ково, как быть, стоит или нет.
Ответам на этот вопрос и посвящено приведённое ниже сочинение на тему РИБ. Сразу прошу прощения за неточность, а порой – за недостоверность технических терминов. Это сочинение для клиента, уровень знаний которого мне не известен. Мне сказали, что это «айтишник клиента».
Откуда взялся РИБ
Для принятия решения по РИБ нужно понимать его историю, перспективы и особенности.
Первое и главное: РИБ – устаревшая методология. Пишу именно «методология», а не «технология», т.к. технология РИБ ровно такая же, как в современных обменах.
РИБ – это типа «давайте гонять туда-сюда все данные». Несложно догадаться, откуда она взялась – из зеркалирования в SQL (когда рядом с основной БД ставится вторая, и сервер её постоянно пополняет изменениями).
В те времена, когда создали РИБ, просто выхода другого не было. Интернет стоил по 5-10 р. за Мб, всё писалось под локальную сеть и, максимум, флешку. Сейчас смешно, но тогда люди реально ездили с флешкой по магазинам, чтобы собрать данные о продажах за день. С этой же флешкой ездили во франч за обновлениями.
Эти ограничения наложили отпечаток, в частности, и на «клиент-серверную архитектуру платформы» - ту самую, которой не было в толстом клиенте, на обычных формах. Сервер ведь стоял в соседней комнате, без вариантов.
Мы чуть от радости не умерли, когда 1С сделала возможность автоматически обмениваться сообщениями РИБ по электронной почте – прям новая волна внедрений началась.
Собственно, первые годы и РИБа было за глаза. Как говорили самые говорливые из 1С, ИТ-ландшафты предприятий были гомогенными – состояли или из одинаковых, или из схожих систем.
Гетерогенный мир
Потом пришла, по их же словам, гетерогенность – системы стали ужасно разнородными. И со всеми надо было как-то интегрироваться. Да и сама 1С осознала ценность доставки контента через интернет, и начала создавать веб-сервисы. Соответственно, в платформе резко и быстро выросла целая плеяда механизмов интеграции с другими системами, поддерживаемых форматов данных, даже количество поддерживаемых СУБД выросло в разы (ха-ха, с 1 до 4, но это ведь в разы). Появилась нормальная клиент-серверная архитектура, тонкий и веб-клиент, новые стандарты разработки – или, точнее, даже новые подходы к разработке.
А РИБ продолжал существовать – не выкидывать же добро. Не потому, что полезен, а потому, что кто-то пользуется. По той же причине до сих пор существует 7.7, обновляется УПП и появляются всё новые режимы совместимости конфигураций. Самих разработчиков 1С тащить и поддерживать всё это добро ужасно раздражает, но выбора нет – действуют законы рынка. Клиенты, которые купили систему, по-прежнему платят за поддержку, и эти деньги надо отрабатывать.
Уже и сама технология обмена поменялась, появился формат, разработанный самой 1С – EnterpriseData. По сути, тот же XML, но избавляющий разработчика от необходимости описывать сущности бизнес-логики – что-то вроде «конфигурированного XML» (по аналогии с обычной конфигурацией, хранящей метаданные).
А РИБ продолжал существовать, по указанным выше причинам. Но в последние лет 10 даже разработчики 1С от него устали – именно от методологии полного обмена данными.
Главная гадость РИБа
Эту методологию, будь она неладна, к великому несчастью, надо учитывать при разработке конфигурации. Создавая любой справочник, документ, регистр или обработку, надо думать: так, а чё у нас с РИБом? Как оно там бегать будет? И даже разработчики 1С иногда стали забывать про РИБ во время разработки конфигураций или каких-то механизмов.
Широко известный в узких кругах пример: расширенная аналитика учета затрат в УПП (на тот момент – флагманский продукт 1С). Сделали шикарнейший, до сих пор непревзойдённый (даже в ERP) механизм расчёта себестоимости. Ну прям закачаешься, прелесть, восторг, мечта. Но…
Забыли, блин, про РИБ. Когда делали оптимизацию структур хранения данных (превращали 40 аналитик в 4, 30 регистров в 2), сделали автоматическую генерацию элементов справочников при проведении документов. И сели в лужу – данные создавались независимо в разных узлах РИБ. На всех заводах с РИБ колом встал расчет себестоимости.
Пришлось быстро выкручиваться – писать статью о том, что РИБ больше не РИБ, надо исключать из обмена часть объектов. И добавился конский механизм «Допроведение документов» - это когда документ летит в другой узел без движений, и они там пересоздаются заново.
Технически выкрутились, но РИБ действительно перестал быть РИБом – данные уже не транслировались, «как есть», а пересоздавались в приёмнике. Если называть вещи своими именами, то это не РИБ, а обычный обмен данными между разнородными конфигурациями. Примерно так же обмениваются данными, например, Зарплата и Бухгалтерия – отправляется только сам документ, да и то без части данных, а всё необходимое «доделывается» в приёмнике (например, проводки, которых в ЗУП нет по определению).
Так оно, в УПП, и осталось. Я на заводе работал ИТ-директором, и мне пришлось собственный механизм допроведения писать. И не один раз – когда есть РИБ, тут без вариантов.
В итоге я выкинул РИБ на помойку. Намного проще и дешевле оказалось купить ВПН на 100 Мбит, и подключить пользователей напрямую. Кстати, в толстом клиенте. Недавно, в сентябре, точно так же сделали одному клиенту – он тоже перестал понимать, зачем ему РИБ, настроенный в 2011 году.
А как сейчас?
Технически, в современных типовых конфигурациях от 1С тоже есть РИБ. И он тащит за собой те же проблемы, что и старая УПП. Я вот прямо сейчас сходил в код модулей РИБ ERP, и вижу всё ровно то же. Я даже картинку приложу:
Не нужно быть программистом, чтобы понять код на русском языке: ребята, получив данные из другого узла, сразу кидаются исправлять ошибки, которые эти данные с собой принесли.
Потому что в современном мире методология РИБ – ущербна и никому не нужна. Я давно 1С занимаюсь, и честно вам скажу: сейчас люди крайне редко используют РИБ. Просто нет уже таких задач, т.к. исчезли ограничения по передаче данных и доступу к ним. РИБ остался только для специфических задач – создать вторую базу, в которой будет работать только бухгалтерия, и оттуда сдавать отчётность.
Раньше же РИБ был у каждого второго клиента.
А что будет дальше?
Что с РИБ будет дальше – примерно понятно. Он умрёт. Он никому не нужен, дорого обходится в разработке и поддержке, постоянно ломается. Останется, разве что, зеркалирование на уровне СУБД. Да и то не факт.
Современные системы, не 1Сные, давно забили на РИБ. Там используется, по сути, два метода: кеширование данных (хранение части данных на клиенте) и фильтрованная репликация (обмен ограниченными наборами данных). Причём, они давно переплелись между собой, и хрен поймёшь, где кеш, а где результат репликации. Тот же браузер Google Chrome, без вашего ведома, может занять до половины свободного места на жёстком диске своей встроенной СУБД – IndexedDB, а вы об этом даже не узнаете. Это будет кеширование данных сайтов, прилетевших сюда через фильтрованную репликацию.
Так вот, 1С движется в ту же сторону. Кеширование они освоили давно, в т.ч. на сервере (а мы все, дружно, освоили очистку этого кеша). Фильтрованная репликация – в процессе. Это и есть те самые штуки – формат EnterpriseData, механизм синхронизации, публикация для BI-приложений через интерфейс OData и т.д.
РИБа не будет.
Адаптация под клиента
В этом разделе закончилась "общая" информация, и пошли ответы на вопросы клиента, переложение общих тезисов на его конкретную задачу. Внедрение текста в его мозги, короче.
В вашем примере, как я понял, всё ещё хуже: вы принимаете решение не об использовании РИБ, а о его разработке. Как мне кажется, выбор не очень сложный, потому что разбивается вдрызг о единственную фразу, которую я выделил в тексте курсивом: РИБ надо учитывать при разработке конфигурации.
Если конфигурация, которую вы будете использовать, не содержит возможностей РИБ, то при её разработке не учитывались требования РИБ. Грубо говоря, это автомобиль, создатели которого и не думали, что на их детище будут плавать по морю. Наверное, возможно, за очень большие деньги можно приделать к нему парус, днище и шпангоуты, но первый же шторм расставит всё на свои места.
Особенно с учётом того, что конфигурация у вас не очень распространённая, поэтому специалистов по ней не так много. А это, увы, важно, если создавать РИБ – надо знать и понимать, как работают на техническом уровне все механизмы этой конфигурации.
Проблемы будут вылезать в самых неожиданных местах. Причём, к несчастью, обнаружите вы их, когда будет уже поздно – у вас на руках останутся две базы с испорченными данными и без эталона, с которым можно сравнить.
Но самое поганое не в этом. Можно сесть, упереться и сделать РИБ, и он даже будет работать. Но: вам ведь обновляться надо будет. Каждое обновление будет напоминать праздник La Tomatina в Испании – весело, но отмываться долго:
Примерно так же радовались клиенты УПП 15 лет назад, когда обновление обходилось им в 100-500 (!) часов. Потому что нежелание думать, вникать, адаптироваться заменяли тысячами человекочасов программирования. И 1С не отставала, на пару с нашими законотворцами – такие изменения подкидывали, что дым столбом стоял во время обновлений.
Ну и не стоит забывать о развитии платформы. 1С давно работает над механизмом автономных клиентов. Это тоже из веб-разработки пришло – клиент может продолжать работать, даже потеряв связь с сервером. После восстановления связи данные реплицируются. Пока они это сделали только для мобильной платформы, но, не ровен час…
Ну а если серьёзно, то РИБ – не вариант вообще. Если вам необходимо обеспечить высокую доступность сервера на небольшое количество пользователей, то самое простое решение – резервные каналы интернета, в обеих точках (клиент и сервер). Я на заводе, и мои текущие клиенты давно покупают резервные каналы – это не так дорого.
Основной канал работает с ВПН, т.е. он «удобный» - работает даже толстый клиент, если нужно. Резервный канал – для экстренных случаев, там нет никакого ВПН, но есть тонкие клиенты и/или РДП с проброшенными портами устройств, вроде касс ККМ, сканеров штрихкода и принтеров.
Однако, опять же, никакой франч, в т.ч. мы, не будет сильно возражать против разработки РИБ за деньги клиента. Это увлекательно. Примерно, как резьба по дереву – толку мало, но пальцы тренируются. Хоть мышцу прокачаем.
Такое и раньше бывало. Если программисту или клиенту не нравилось, как работает РИБ в типовой конфигурации, он садился и писал весь обслуживающий код самостоятельно. Дима, привет.
