Попробую рассказать о принципах оффлайновой работы 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, потому что менеджер удалил лишний пробел между словами в наименовании).
Это так?

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

[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С, вполне работоспособна, но до определенного масштаба.

[Сисой]

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

[KingA]

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

[Reaper]

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

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

[Logger]

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

[mazzy]

Цитата:

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

...не стремятся устроить федеральную торговую сеть...

Цитата:

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

Ну, обслуживание больших комплексов тоже стоит дороже

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

Все проще и дешевле.

[Logger]

Как правило ларек с распределенкой бывает дешевле

[Reaper]

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

1. Служба регистрации изменений
2. Механизм сериализации объектов платформы и работы с XML

Собственно первый механизм предназначен сугубо для управления составом пакетов. В простейшем случае регистрируются все изменения - это и будет та самая распределенка. Она используется в типовых для построения полных репликаций и действительно работает по топологии "звезда".

Второй механизм используется только для полных обменов. Сильная его сторона в том, что он делает выгрузку/загрузку с очень достойной скоростью (по сравнению с универсалкой, поясню ниже). В этом же и его минус - обмен может длиться 5 минут вместо 4-х часов, но на все время этого обмена блокируются физические таблицы службы регистрации изменений. А организованы они "в лоб" - на каждый узел репликации одна таблица. Блокировка накладывается исключительная на всю таблицу. В итоге получаем замирающую на время обмена базу.

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

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