Всем добрый день!
Вопрос к спецам в 1С.

Как в 1С(возьмем 8 версию) решен вопрос с репликациями данных между офисами?
Средствами SQL-сервера или еще как?
Требуется репликация информации не реже раз в 15 минут. А то и чаще.
Каналы везде выделенные между офисами.
Объем, если брать за единицу расчета обычный складской документ с 50 позициями, примерно 1000 документов в день. Данные во все офисы реплицируются.
Я по 1С не спец, хотя спокойно могу разобраться до бита как там все устроено.
Сейчас подбираем новую систему. Репликации для меня очень важный момент и хочется иметь четкое представление по данному вопросу.

Что-то сразу в форумах не посмотрел. Извиняюсь.

Я так понял что, делается через XML. Выгружаем, передаем, загружаем.
Или есть какой-то модуль на уровне серверов приложений, которые по заданным алгоритмам обмениваются?
Или эти логику этих алгоритмов использует SQL-сервер и репликация идет на уровне SQL-серверов?

Shuhard antand хотя спокойно могу разобраться до бита как там все устроено.

1 слабо
2 http://www.kb.mista.ru/article.php?id=7
Так.... понял технологию.
Может чего не увидел, но реплицируются изменения или вся база?
И еще вопрос: все эта логика лежит на сервере приложений, я так понял?

Прошу прощения, разобрался окончательно вроде в том что написано:
http://www.kb.mista.ru/article.php?id=7
Я понял так:
Создаем конфигурации обмена и настраиваем ее. Можно перечислить все какие надо объекты, поставить фильтры, чтобы лишнего не передавать(хотя этого я не увидел, но догадываюсь что есть) и т.д.
Создаем процедуры обмена для отправки файлов и для приема.
И потом все это в планировщик(в принципе это уже не важно в какой планировщик).

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

Shuhard antandЯ так подозреваю сервер приложений
файловая версии идентична по функционалу , следовательно подозревать стоит клиента
Какого клиента? Код процедуры для обмена на макроязыке описанной выше выполняется на клиенте???
А если нет клиента? Выходные например. То что базы не обмениваются???
Я то как раз считал, что этот код выполняется на сервере приложений.

Ну вроде совсем разобрался с вопросом. Вот здесь все написано.
http://v8.1c.ru/overview/ObmenMain.htm
В принципе, все нормально, красиво и логично выглядит, если не знать, что в качестве базы используется MSSQL и он задействован в этой схеме как таблицы dbf!?

Зачем надо было изобретать велосипед, а не воспользоваться встроенными механизмами репликации MSSQL?
Из описанного видно, все из-за желания 1С сделать универсальными механизмы обмена через XML, а сюда репликации MSSQL не особенно пришьешь.
Я не спорю, механизм обмена по XML нужный и очень полезный, особенно для обмена между разными базами, разными организациями и т.д., но зачем его использовать для обмена между однотипными базами одной организации?

Вообще такое впечатление, что возможности MSSQL как SQL-сервера баз данных как-то слабо используется во всей 1С, и не только в вопросе репликаций.
Все и вся зачем-то сваливается на сервер приложений. Я не против сервера приложений, он как раз нужен, но для для своих задач в такой системе.

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

И я отлично представляю теперь - во что выльется внедрение нормального решения 1С на моем предприятии. Внедрение именно нормального решения. Я здесь не сомневаюсь в квалификации внедренцев, можно грамотно подойти к выбору внедренческой фирмы, они в конце концов(или сразу) сделают нормально. Но нужно четко осознавать, что чтобы сделать нормально им придется писать всю конфигурацию с "0", придется переносить многое из бизнес-логики на SQL-сервер, а это уже совсем другой уровень программирования со своими затратами и т.д.

Честно говоря я не ожидал, что с 1С дела сегодня обстоят именно так.
Вроде сегодня 2006 год и уже можно было очень грамотно систему спроектировать на системном уровне.

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

ХерресКод процедуры обмена может исполняться как на клиенте, так и на сервере.

Почему 1С не пользуется стандартной репликацией sql-сервера ? Да потому, что тогда не будет возможности вписать бизнес-логику обмена на языке 1С, например указать, что в данный узел попадают не все документы а только вот с таким складом (к примеру)

Обмен сообщениями гарантированный, т.е. информация будет посылаться в другой узел пока оттуда не придёт квиток о доставке.
Есть возможность отказаться от такого поведения.
Спасибо за сообщение!
Но во на счет "не будет возможности вписать бизнес-логику обмена" - это немного не верно. Все можно очень спокойно сделать с репликациями от MSSQL, если на языке 1С не управлять самим обменом(как показано в процедуре выше), а управлять именно логикой обмена(кому, что посылать и т.д.).
Т.е. Вы в 1С будете управлять только настройками обмена, а MSSQL в соответствии с этими настройками будет сам реплицировать данные.

Искандер Двурогий Херрес[quot antand]
1С же - это объектная база данных и доступ напрямую в таблицы минуя объекты не совместим со всей идеологией 1С.

Совершенно верно.

Ребята спасибо. Золотые слова прозвучали. Вопросов нет, такая у 1С идеология.

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

Только любой такой уровень управления бизнес-логикой должен опираться на еще более серьезный уровень реализации бизнес-логики. Здесь мы вплотную подходим к таким вещам как грамотная работа с SQL-cервером, проектирование базы(что делается на клиенте, что делается в базе), оптимизация, распараллеливание на сервере приложений и т.д и т.д.
Понятно, что на еще более низком уровне должны быть технологии SQL-сервера и операционных систем(ну и конечно других сервисов, которые нужны для работы).
Это самый низкий уровень для 1С делают ведущие разработчики мира, там уже все столько придумано и продумано, что только надо правильно пользоваться.

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

Искандер ДвурогийВ действительно БОЛЬШИХ проектах такой проблемы нет. Если у компании достаточно ресурсов, она способна обеспечить постоянные устойчивые широкополосные каналы связи (как минимум для работы в терминальном режиме). Иногда бывает необходим редкий офлайн-обмен (например, для квартальной консолидации данных в рамках крупного холдинга) - решается стандартными средствами 1С.
Какая обычная средняя компания с распределенной структурой, может обеспечить бесперебойные!!! постоянные устойчивые широкополосные каналы связи между удаленными точками?
Понятно, что когда есть такой канал, то можно рабтать