Попробую рассказать о принципах оффлайновой работы 1С.

[Сисой]

Итак, как организована работа 1С в оффлайновом режиме.
Есть базовый класс "План обмена". В экземпляр этого класса можно включить объекты конфигурации, по которым требуется вести обмен. Для каждого объекта (документ, справочник и т.п.) указываем, используется ли авторегистрация изменений. Если не используем, то можно устанавливать эти признаки программно, например, из подключаемого обработчика (а-ля триггер).
Далее в режиме пользователя определяется перечень площадок, между которыми ведется обмен.
Даже если используется авторегистрация изменений, можно программно вмешиваться в формирование списка получателей (т.е. кому отправляем).
Сообщения между узлами (площадками) передаются в формате XML (объем велик, но 1С использует ZIP).
Возможны два варианта работы: произвольный обмен между произвольными конфигурациями и режим распределенной БД. В первом случае ответная квитанция получателя строго говоря, не требуется, во втором система обмена автоматически может синхронизировать не только данные, но и код (конфигурации 1С), автоматически разрешает простые коллизии типа "главный-подчиненный", требует квитирования доставки (после валидации и записи в БД-приемник).
Все процессы обмена контролируются многочисленными программными обработчиками, куда можно вставлять свой код.
Центральное место занимает специальная конфигурация "1С:Конвертация данных" (бесплатная, лежит на диске ИТС).
Эта конфигурация умеет выгружать и хранить структуры конфигураций 1С 7 и 1С 8, визуально настраивать правила сопоставления таблиц и правила выгрузки, подключать по любому чиху программные обработчики событий (чаще всего для разрешения коллизий или определения недостающих значений, подлежащих валидации в приемнике). На выходе генерится схема обмена, т.е. правила преобразования данных одной БД в другую, плюс код "триггеров".
В типовые конфигурации встроена обработка, позволяющая по расписанию напрямую (COM-подключение) или через промежуточные файлы выполнять любые обмены между БД 1С (достаточно зарегистрировать схему обмена). Расписание выполняется на сервере приложений.
Сразу оговорюсь, что на самых крупных проектах были успешные попытки применить репликацию средствами MS SQL. Но этот способ требует (именно для 1С) шаманства и специалистов, владеющих им, немного.

[Сисой]

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

[mazzy]

Цитата:

Сообщение от Сисой

Итак, как организована работа 1С в оффлайновом режиме.

1. Прежде всего, термин оффлайновый режим не совсем корректен - лучше использовать термин "репликация данных и приложения (конфигурации)"
2. Репликация выполняется на уровне самого 1С, а не на уровне СУБД
3. 1С содержит механизмы, которые позволят программисту написать обработчики конфликтов репликации, но эти обработчики не написаны для типовых конфигураций. Фактически, конфликты репликации решаются по принципу "кто последний, тот и папа".

Цитата:

Сообщение от Сисой

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

Каждая площадка - отдельная база данных (площадки могут использовать разные СУБД, правильно?)

Цитата:

Сообщение от Сисой

Даже если используется авторегистрация изменений, можно программно вмешиваться в формирование списка получателей (т.е. кому отправляем).

Обратите внимание, на это "можно ... сделать".
Это значит, что в типовых этот механизм не используется

Цитата:

Сообщение от Сисой

Сообщения между узлами (площадками) передаются в формате XML (объем велик, но 1С использует ZIP).

Для работы с xml используется библиотека, которая загружает весь XML в память. Раззипованный xml. (я правильно говорю? )

Цитата:

Сообщение от Сисой

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

В переводе на русский язык это означает:
Первый случай - тотальное программирование
Второй случай - имеет свои ограничения. см. ниже

Цитата:

Сообщение от Сисой

требует квитирования доставки (после валидации и записи в БД-приемник).

Это значит, что обмен должен быть двусторонним.
1С будет слать изменения до тех пор, пока не получит ответ (квитанцию) от приемника об успешном приеме.

Цитата:

Сообщение от Сисой

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

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

Цитата:

Сообщение от Сисой

Центральное место занимает специальная конфигурация "1С:Конвертация данных" (бесплатная, лежит на диске ИТС).
Эта конфигурация умеет выгружать и хранить структуры конфигураций 1С 7 и 1С 8, визуально настраивать правила сопоставления таблиц и правила выгрузки, подключать по любому чиху программные обработчики событий (чаще всего для разрешения коллизий или определения недостающих значений, подлежащих валидации в приемнике). На выходе генерится схема обмена, т.е. правила преобразования данных одной БД в другую, плюс код "триггеров".

Конфигурация лежит, а правила обмена есть? И для каких типовых конфигураций уже существуют правила обмена?

Цитата:

Сообщение от Сисой

Сразу оговорюсь, что на самых крупных проектах были успешные попытки применить репликацию средствами MS SQL. Но этот способ требует (именно для 1С) шаманства и специалистов, владеющих им, немного.

Как всегда, самое интересное в конце и в таком стиле, что понять могут только посвященные.

Ок. Спрошу.
А почему "на самых крупных проектах" вообще возникли попытки "применить репликацию средствами MS SQL"?

[Сисой]

На уровне типовых реализованы следующие схемы обмена:
1. Бухгалтерия 7 -> Бухгалтерия 8 (перенос операций при апгрейде)
2. Бухгалтерия 8 <-> Зарплата и Управление персоналом 8
3. Бухгалтерия 8 <-> Управление торговлей 8
4. Бухгалтерия 8 <-> Зарплата и кадры 7
5. Бухгалтерия 7 <-> Зарплата и Управление персоналом 8


В них используются все заявленные мной возможности, включая программные обработчики.
Партнеры 1С разрабатывают и другие схемы обмена, например Комплексная 7.7 - > УПП.
Кроме того, в Бухгалтерии 8 есть механизм обмена со всеми необходимыми настройками для автономной работы бухгалтера в выходные дома.

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

Репликация средствами 1С нормально работает в следующих случаях:
1) Обмен НСИ.
2) Иерархическая структура холдинга "одна главная площадка - несколько мелких". Или "одна база - несколько магазинов".
3) Получение отчетной БД с достаточно большой периодичностью (например, еженедельно данные из Бухгалерий колхозов сливаются в централизованную БД управляющей компании).

Важное замечание: Запись большого количества импортируемых документов в 1С может вызывать блокировки ввода текущих документов. Единственное, что смогла предложить 1С - механизм отложенных движений. В этом случае сначала в БД записываются непроведенные документы, а затем специальная фоновая задача выполняет постинг в максимально щадящем с точки зрения OLTP режиме.

Однако, если объем вводимой информации велик, а репликация нужна оперативная (пример - в территориально распределенном горизонтальном холдинге нужно оперативно передавать в центр информацию о взаиморасчетах и кэше), штатные механизмы 1С становятся "бутылочным горлышком". И тогда на помощь приходят спецы из компаний типа softpoint.ru...

[sobolev]

Вопрос к Сисою по технологии обмена.
Я так понимаю, что система фиксирует идентичность одного и того же объекта в разных разделах по UUID'у, который является уникальным неизменяемым идентификатором объекта как в пределах одного раздела, так и всей совокупности разделов.

Скажем, товар А в разделе X1 имеет идент 1000 (естественно, это - UUID). Когда этот товар передается в другой раздел X2, там он тоже будет товаром А с идентификатором 1000.
Когда в первом разделе (X1) какой-то атрибут товара А изменится и будет передан в раздел X2, то там система найдет товар с идент 1000 и изменит вышеобозначенный атрибут. И т.д.

Если до сих пор я все правильно изложил, то вопрос следующий: что делает система в случае, если один и тот же по сути объект существует в разных разделах независимо друг от друга?
Возвращаясь к примеру, если записи для товара А в разделах X1 и X2 созданы независимо друг от друга (само-собой, их идентификаторы разные).

[Сисой]

UUID - лишь один из возможных вариантов контроля уникальности и сопоставления.
В 1С:Конвертации можно определять, по каким ключевым полям сопоставлять товары.
Например, Поставщик+Артикул. Или Код+Наименование.

[sobolev]

Цитата:

Сообщение от Сисой

UUID - лишь один из возможных вариантов контроля уникальности и сопоставления.
В 1С:Конвертации можно определять, по каким ключевым полям сопоставлять товары.
Например, Поставщик+Артикул. Или Код+Наименование.

ОК. При поступлении нового объекта модуль конвертации распознал наличие аналога и не стал создавать нового объекта. Для определенности придерживаемся прежнего примера с товаром А. Теперь этот товар А в разделе X1 имеет идент 1000, а в разделе X2 - 900 (там аналог был создан раньше).
Т.о. с этого момента при дальнейшей синхронизации кто-то должен следить за тем, чтобы указанный набор ключевых полей ни в коем случае у товара А в обоих разделах не менялся. В противном случае у нас "раздвоятся" ссылки на этот объект (в нашем примере, например, вероятны проблемы с документами, ссылающимися на товар А: вчера мы продавали А, сегодня это будет уже А2, потому что менеджер удалил лишний пробел между словами в наименовании).
Это так?

Другими словами, правильно ли я понимаю, что фактически синхронизации между разделами нет, но есть развитая технология импорта/экспорта, позволяющая передать данные из одной базы в другую без сохранения связей между объектами различных разделов?
Или я что-то упустил?

[Сисой]

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

[KingA]

2 sobolev: "зришь в корень". У нас сейчас обмен 8.1 УТ -> 8.1 БУХ легко задваиваются контрагенты. Синхронизация по наименованию, ИНН, КПП. Так что пример абсолютно жизненный.

[mazzy]

Цитата:

Сообщение от Сисой

На уровне типовых реализованы следующие схемы обмена:
1. Бухгалтерия 7 -> Бухгалтерия 8 (перенос операций при апгрейде)
2. Бухгалтерия 8 <-> Зарплата и Управление персоналом 8
3. Бухгалтерия 8 <-> Управление торговлей 8
4. Бухгалтерия 8 <-> Зарплата и кадры 7
5. Бухгалтерия 7 <-> Зарплата и Управление персоналом 8

тогда промолчал. но поскольку возникают ссылки сюда прокомментирую.

ок.
В этом списке нет УПП,
В этом списке нет обмена 7-7.
В этом списке нет несовместимых друг с другом конфигураций типа УТ-УТ.
В этом списке нет того, нет сего.

Но хоть как базу эти уже имеющиеся схемы использовать можно?
Я правильно понимаю, что для синхронизации УПП - БУХ можно взять схему УТ - БУХ и допилить ее? Или не получится?
Сколько по времени может занять создание схемы УПП - БУХ?

[Сисой]

Цитата:

Сообщение от mazzy

В этом списке нет УПП

Есть БП --> УПП, УТ --> УПП

Цитата:

Сообщение от mazzy

В этом списке нет обмена 7-7.

Я их просто не упоминал, т.к. топик про 8-ку.
Есть ТиС<->Бух, ЗиК<->Бух

Цитата:

Сообщение от mazzy

Я правильно понимаю, что для синхронизации УПП - БУХ можно взять схему УТ - БУХ и допилить ее? Или не получится?
Сколько по времени может занять создание схемы УПП - БУХ?

Лучше не допиливать, а настроить заново по образу и подобию. Все-таки УПП содержит больше информации для БУ и НУ, чем УТ (те же счета НУ, к примеру).
Я делал обратную схему (тогда еще не было типовых правил обмена БП --> УПП) для документов кассы, банка, склада дня три (там еще фильтрацию нужно было программно обеспечить).

[mazzy]

Цитата:

Сообщение от Сисой

Есть БП --> УПП, УТ --> УПП

Только сейчас заметил, что есть однонаправленные стрелки, а есть двунаправленные.

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

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

Так?

[Сисой]

Цитата:

Сообщение от mazzy

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

Так?

Да.
При этом следует понимать, что к идее переноса больших массивов информации через текстовые XML-файлы следует относиться с определенной долей скепсиса.
Алгоритм, прекрасно работающий при выгрузке пары сотен документов или перегрузке НСИ из одной конфигурации в другую, оказывается неуклюжим и непрозрачным при попытке перенести десятки тысяч операций. Еще раз повторюсь: концепция распределенных баз, предложенная 1С, вполне работоспособна, но до определенного масштаба.

[korvint]

мысль, просто мысль
а может хватит off-line
на дворе 21-й век
реальный масштаб времени (on-line) рулит сейчас и будет рулить
а на 1С реальный масштаб времени никак?

[mazzy]

ну, почему же "никак"?
очень даже как http://demo-ma.1c.ru/
другое дело, что 1С сильно вложилась в оффлайновый режим (как и в собственную базу данных). Вопрос "зачем?" останется неразгаданным долго.

[Reaper]

Цитата:

Сообщение от mazzy

1С сильно вложилась в оффлайновый режим (как и в собственную базу данных). Вопрос "зачем?" останется неразгаданным долго.

Поясню на примере. Есть магазин, составленный из 8 бутиков. Владелец один, даже здание одно. На настоящий момент работают на УТ 10.3. Схема обмена доработана нашими руками так, что каждый магазин имеет на кассе собственную базу 1С, в которой есть данные только самого магазина и только необходимые для осуществления продаж. В итоге базы магазинов весят 200-300 МБ и компы там стоят 10-летней давности. В офисе стоит просто хорошая рабочая станция на которой развернут центральный узел системы весом около 1,5 ГБ и работает около 10 пользователей. Если же делать централизованную базу в которой бы работали абсолютно все пользователи - нужен был бы и клиент-сервер и собственно нормальный аппаратный сервер.

[gl00mie]

Цитата:

Сообщение от Reaper

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

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

[mazzy]

Цитата:

Сообщение от Reaper

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

Сколько стоит соверменный сервер? 5000-7000 долларов. Разово.
Сколько стоит поддержка специалистов, которые разгребают конфликты репликации? Каждый месяц.

Цитата:

Сообщение от gl00mie

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

Можно подумать, что распределенка не приводит к простоям.
Обслуживание распределенки тоже необходимо выполнять.

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

[Reaper]

mazzy, это мы с вами специалисты на стыке IT-технологий и экономики. А малым бизнесменам, которые не стремятся устроить федеральную торговую сеть, которых устраивает то что есть, и больше чем отвезти семью на лето в Турцию не надо - им и образование ни к чему. Для них проще 10 лет платить по 100 долларов в месяц, чем за раз оборудовать толковую серверную и всю IT-инфраструктуру. Мне самому интереснее работать с системами высокой пропускной способности с большим количеством пользователей... а приходится настраивать репликации и разруливать коллизии.

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

[Logger]

Ну, обслуживание больших комплексов тоже стоит дороже. Спецов сложнее найти, они дороже.
Плюс не надо забывать о числе одновременно работающих пользователей в системе. Сколько их будет, как разруливать блокировки и потащит ли вообще КИС такое число.