Суть в чем?
Выгружаю в файл send получателю все объекты, зарегистрированные для него.
У получателя загружаю эти объекты из файла send.
Если загрузка успешна, переименовываю файл send в файл read.

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

Конфу передаю автоматом, целиком, процедура тоже реализована.


Как-то так. Потому что типовая РИБ запарила двумя проблемами:
1. Блокировка при выгрузках. На 100 точках это жесть.
2. Потерей данных при обменах. Непонятно почему происходит, началось после введения параллельных выгрузок на точки.

(0) И че?

(1) зацени красоту решения, подаренного вам моим гением. ;-)

да, забыл присказку. Когда работал в одной конторе, IT-директор мне сказал придумать схему обмена между узлами РИБ.
Я тогда ему ответил - не понимаю постановки, чем обычная РИБ не катит.
В общем, это в итоге стало одним из пунктов наших взаимонепониманий, в результате чего меня уволили (2 раза в жизни увольняли). Но суть в том, что теперь похоже я понимаю, что он имел ввиду - типовая РИБ имеет недостатки, слишком она универсальная, сделанная для сферического коня в ваккууме.

А почему блокировки при выгрузке хоть узнал?
Может таки в одной транзакции всё шло?

(0) Не понял, как решение спасет от озвученных проблем?

(0)
Примус. Признание Америки.
МОСКВОШВЕЯ. Примус.
Пивная. Ещё парочку.
Пивная. Ещё парочку.
Пивная. Ещё парочку.
Пивная. Ещё парочку.
МОСКВОШВЕЯ, МОСКВОШВЕЯ.
Пивная. Ещё парочку.
Буржуи, буржуи.
Не толкайся, подлец, слезай с подножки.
Я тебе покажу, твою мать!
Перестань.
Примус. Признание Америки.
МОСКВОШВЕЯ, МОСКВОШВЕЯ, МОСКВОШВЕЯ.
Примус. Пивная.

(4) потому что выгрузка файла обменов блокирует таблицу регистрации изменений, чтобы менять номера сообщений. В итоге никто не может изменять объекты по этому магазину, ошибка блокировки. Это особенность РИБ.

(5) а подумать?

(3) ИМХО. Единственный недостатов РИБ - встроенный механизм разрешения транзакций. Все остальное - практически идеально.

(7) Вот и я про тоже. Может подумаешь?

(5) типа по п.1 - меньший объём выгрузки будет => меньше блокировок.
а вот п.2 - это уже фантастика, или я не знаю что вкладывается в понятие "паралельных выгрузок"

(7) >>В итоге никто не может изменять объекты по этому магазину
Ну дак выгружай ВНЕ общей транзакцуии каждый объект, ибо блокировка до конца транзакции держится

(8) Не спорю что идеально, но мы же помним, что лучшее - враг хорошего, т.е. идеальное - враг специального.


В чем преимущества быстрой схемы обмена:
1.    При выгрузке сразу удаляются ненужные для получателя данные.
2.    Фиксированная схема обмена – Загрузка, Подтверждение, Выгрузка.
3.    Не будет теряться регистрация изменений, т.к. подтверждение реализовано пообьектно, а не по номерам пакетов.
4.    При выгрузке и загрузке файла обмена не осуществляется блокировка базы данных, что позволяет в центре делать много параллельных обменов и не мешать работе пользователей по вводу данных, а на точке спокойно заниматься продажами даже при автообменах.
5.    Скорость обменов практически такая же, как и в обычных обменах.
6.    Конфигурация всегда передается целиком, т.е. проблемы, когда «конфигурация не соответствует ожидаемой» и требовалось подключение специалиста поддержки исчезнут.
7.    Есть контроль изменений, т.е. если за время обмена объект поменялся еще раз, он все равно будет отправлен получателю, даже если пришло подтверждение получения. Иначе бы непроведенное перемещение могло отправиться на точку, за время между обменами в центр пришла бы новая проведенная версия, но на точку бы не отправилась, если бы пришло с точки подтверждение, что оно точкой получено. Этот момент специально контролируется, коллизий такого рода не будет.
8.    Всегда можно без лишних подключений на точку вернуться на старую схему обмена, если требуется. Т.е. старая схема не исключается, можно использовать гибридно новую и старую, если требуется. Изменения в интерфейс пользователя также минимальны, т.е. с точки зрения пользователя ничего не меняется.

(7) Предполагаю что таблица блокируется не только (а скорее вообще не для этого) для смены номера сообщения.

(0) :[||||||||||||||||||||||]:

(2) подобный лисапед был сделан сначала на 7.7 в 2007 и потом переделан с улучшением на 8.0 в 2008-2009, причем юзал гуиды чтобы огромный справочник отдельно обновлять и стандартный обмен допиленный мог работать штатно ))

(3) не лечится...тока если тяжелым чем то...мания величия она такая...

(7) гыгыгы, делаем обмен и одновременно меням объект который должен быть в этом обмене - ГЫГЫГЫ

(2) В чем таки "красота"? В переименовании файла send и read?
Или в переходе на схему, которая применяется для мобильных приложений?

(10) про параллельность выгрузок я писал на инфостарте.

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

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

(13) ничто не ново под луной. я не удивлен. ;-)

(14) преимущества я описал в (11)

>>3.    Не будет теряться регистрация изменений, т.к. подтверждение реализовано пообьектно, а не по номерам пакетов.
по номерам - ничего и не теряется, у вновь зарегистрированного - номера нет.ну и т.д.

(13) небольшая разница - ты о своём баяне никому не сказал и он умер с тобой, а я делюсь тут с Олл.

(18) у нас теряется. Ни я, ни привлеченные франчи не смогли выяснить почему. Какой-то косяк с номерами сообщений.

(11) много символов, пиши короче, лень осиливать

(17) слишком много преимуществ это обычно недостастаток...

(0)Хорошо что ты нашел применение подобной схеме.
Я бы не рискнул подобным образом обмены делать.

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

(11)
"1.При выгрузке сразу удаляются ненужные для получателя данные.
2. Фиксированная схема обмена – Загрузка, Подтверждение, Выгрузка."

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

(19) ... умный пингвин ...

(21) да вы филосов.
(22) ну тут жизнь заставила. И потом рисков не особо много. Преимуществ больше.
(25) теперь ты и не докажешь, что этот баян у тебя был, может ты из зависти написал. гыгыгы.

(24) у нас данные не удаляются. принципиально. не считая наборов записей РС и движений документов, но там выгружается ключ записи.

я знаю только один пример рабочий и выбранный осознанно при переписывании типовых схем обмена (в.т.ч. и выборка изменений запросами, а не штатно) - это в системе с 5 тыщ юзеров онлайн к которой ещё обмены прикручены...

(24) но даже если бы удалялись, удаление - это специальный объект УдалениеОбъекта, он присутствует в файле выгрузки, соответственно, если он удалится, то попадет в файл подтверждения.

(28) век живи, век учись. Теперь ты будешь знать еще и мой пример на 100 точках. Если взлетит. Думаю, взлетит.

(26) да в легкую доказать... аптечная сеть целая из 160 аптек вроде до сих пор сидит на 8-й версии по ОНЛС  - ГУП АО "Фармация" в 29

(11)

Пункт 3. - не считаю это преимуществом, а скорее недостатком. В РИБ документы и их движения, как ты знаешь сам, идут независимо друг от друга (т.е. "пообъектно")

Пункт 6. поверь мне на слово: даже когда ты загружаешь конфигурацию - это не всегда спасает от ошибки «конфигурация не соответствует ожидаемой». Ибо ты загружаешь конфигурации поставщика и рабочую(основную), но не конфигурацию БД.

Далее не читал.

(28) Кстати да, забыл сказать, я изменения тоже запросами выдираю, а не штатно, чтобы не блокировать базу методом ПолучитьИзменения. Это важно

(32) разницы не понял. Если раб.конфа не соответствует текущей, пользователю выдается сообщение и напоминание каждые 15 минут. он может обновить конфу.

(31) ну я же не пойду в эту контору уточнять, а публикаций ты не делал. Кто первый опубликовал - того и тапки, гыгыгы.

(27) Понятно... Разговор немого с глухим?
Я спросил за ситуацию, когда что-то нужно выгрузить на периферию, и оно уже якобы выгрузилось. Но до периферии не доехало. Ты информацию о выгрузке уже убил (11) п.1.
Внимание вопрос : сколько тебе понадобится вазелина?

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

ЗЫ смотри изменения в базе (по логике конфы) должны быть связаны скажем. например родительский и подчиненный справочник - если поменяли один то обязательно меняем другой

далее у тебя в обмене может так получиться что выгрузятся только изменения одного без другого так? в получателе только 1 объект поменян (из 2-х необходимых) - приехали...

(35) видишь ли, мне и моим клиентам такие кривые тапки как то совсем не сдались...

(0) Эдакий режим "опережающей квитанции"? Не совсем понял, в чем его смысл. Если загрузка на точке прошла успешно, то почему неуспешно пройдет выгрузка с "настоящей" квитанцией?

По п.2 из (11)
"Фиксированная схема обмена – Загрузка, Подтверждение, Выгрузка."

То есть пока не получили подтверждение о загрузке предыдущей ничего не выгружаем?

Вопрос тот же : сколько понадобится вазелина если вдруг будет нужно вдогон отправить информацию, имеющую ссылки на предыдущую (недоставленную до получателя) выгрузку?

(34) Я не об этом. Демоническое обновление - ошибка может возникнуть в ЦБ при обновлении и далее обменом передаётся по всем ПБ.

Эпитафия: ждём следующую расширенную ветку по теме:

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

Очередной лисапет с биркой "красоту решения, подаренного вам моим гением."...

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

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

(39) не очень понял вопрос.

(40) выгружаем. если не прошла загрузка, выгружаем все
равно. ;-)

(44) слухи о смерти 1с преувеличены. Пока не сделают нормальный RAD, конкурентов у 1С нет. Несмотря на коррозийную гнильцу в виде УФ в 8.3.

(11) Берем обычную схему "Загрузка/выгрузка"
1. В обычной схеме это тоже происходит. Перед выгрузкой загружается файл с квитанцией и программа это делает сама.
2. Тоже самое
3. Никакой потери не происходит
4. Вот тут самый интересный момент. Как я понял, ты получил каким-то образом в итоге экономию на блокировках, но я не понял, за счет чего. Возможно, у тебя был неправильный регламент, а ты его таким странным способом "исправил".
5. Логично
6. Допустим. Хотя кому-то это может быть минусом (каждый раз всю конфу гонять).
7. Коллизии такого рода в обычной схеме исключены (обработка квитанции не может привести к удалению регистрации сделанного в процессе изменения)
8. Возвращаться не нужно :)

Как я догадываюсь, блокировок у тебя меньше не из-за странной схемы обмена квитанциями, на которую ты упираешь. А просто из-за того, что ты реализовал альтернативную УРБД на планах обмена с меньшим количеством блокировок (и сомнительным обеспечением целостности данных). В этом ключе похожая разработка может иметь ценность, т.к. в самом деле позволит нормально распараллелить обмены. Но тут надо очень много думать. Если у тебя сейчас всё ОК на твоей специфике, это вовсе не значит, что ты учел все возможные коллизии.

(47) взял и все опошлил. Но ты не вдался в детали, а поскакал по верхам, поэтому и показалось тебе, что все проще.

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

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

Перевел уже 15 узлов, вроде работает нормалек.
Конфа прогружается, лепота.

(50) а начальный образ базы периферийной создается из центральной? ))

(51) через мою обработку "Генерация узла Риб".
а вообще есть база-образ М00, она обменивается с центром и при необходимости из нее копируется образ новой дочки. ;-)
Бинго!

Основная проблема РИБ - параллельные изменения (когда выгруженный из центра документ поменяли в двух узлах и отправили обратно) не решается в рамках РИБ - та работает принцип - кто первый успел.
Дальше, соответственно, когда оператор видит, что его документ "чудным образом поменялся", то он правит его ещё раз и отправляет изменения - на другой точке на следующий день происходит тоже самое.
P.S. менять не обязательно документ - можно справочник или регистр, главное, что измерения в узлах объектов из центральной базы просто недопустимы.

(53) не понял что такое "измерения в узлах объектов".
у нас документы меняться могут некоторые, но коллизии не возникают. ;-) грамотно надо уметь, дядя.

(53) Аналог - когда в одной базе 2 человека поочереди меняют объект :) Это в головах проблема, а не в РИБ.

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

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

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

(56) видимо, ты не понял схему обмена, гыгыгы. ;-)

(0) А сериализация штатная сохраняется или каждый объект вручную раскладывается на реквизиты, табличные части итд ?

(58) штатная конечно.

(58) Вот выгрузка, например:

Функция    СоздатьФайлВыгрузки(СтруктураОбмена, ИмяФайлаВыгрузки) Экспорт
    //Выбираем все изменения для узла в который выгружаются данные
    ИмяВременногоФайла = ПолучитьИмяВременногоФайла("XML");
    
    ЗаписьXML = Новый ЗаписьXML();
    ЗаписьXML.ОткрытьФайл(ИмяВременногоФайла);
    ЗаписьXML.ЗаписатьНачалоЭлемента("root");
    
    СтруктураИзменений = ВыбратьИзмененияБезЗаписи(СтруктураОбмена.СсылкаУзла, 0, ложь); //Не только подстчет, но и данные сами
    ЭлементыВыборки = СтруктураИзменений.Изменения; //Выборка изменений
    Всего = СтруктураИзменений.Всего; //Количество изменений
    
    
    //Выбираем изменения под очередной пакет
    Сч = 0;
    
    Для Каждого ЭлементДанных Из ЭлементыВыборки Цикл // Пока Выборка.Следующий() И Сч < РазмерПакета Цикл
        
        //Прогрессор
        Если Сч % 20 = 0 Тогда
            ксСостояние("Выгрузка: " + Сч + " из: " + Всего);
            ксОбработкаПрерыванияПользователя();
        КонецЕсли;
        Сч = Сч + 1;
        
        Если ТипЗнч(ЭлементДанных) = Тип("УдалениеОбъекта") Тогда
            ПродолжитЬ; //Удаления пропускаем, с ними не работаем...
        КонецЕсли;
        
        Если СтруктураОбмена.ЭтоЦентр Тогда
            ПередаватьЭлемент = ПроверитьПередачуИзЦентра(СтруктураОбмена.СсылкаУзла, СтруктураОбмена.ОбъектУзла, ЭлементДанных);
        Иначе
            ПередаватьЭлемент = ПроверитьПередачуВЦентр(СтруктураОбмена.СсылкаУзла, СтруктураОбмена.ОбъектУзла, ЭлементДанных);
        КонецЕсли;
        
        Если НЕ ПередаватьЭлемент Тогда
            //Если элемент не передавать, то сразу удаляем по нему регистрацию и пропускаем...
            Попытка
                ПланыОбмена.УдалитьРегистрациюИзменений(СтруктураОбмена.СсылкаУзла, ЭлементДанных)
            Исключение
                Возврат "Ошибка при удалении регистрации в узле: " + СтруктураОбмена.СсылкаУзла + " по элементу: " + ЭлементДанных;
            КонецПопытки;

            Продолжить;
        КонецЕсли;
        
        ЗаписатьXML(ЗаписьXML, ЭлементДанных);

    КонецЦикла;
    
    ЗаписьXML.ЗаписатьКонецЭлемента();
    
       ЗаписьXML.Закрыть();
    
    УпаковатьФайл(ИмяВременногоФайла, ИмяФайлаВыгрузки);
    
    СтруктураОбмена.Вставить("Обработано", Сч);
    
    Возврат истина;

КонецФункции

(57) я-то понял, но разубеждать тебя не буду....


про то чего не хватает:
в 1с не хватает всего одного поля для достижения счастя с рибом, сейчас есть поле _Version по существу это авто инкемент тригера "save", но нужно еще одно поле гуид узла в котором это поле было сгенерировано. Ну и механизм синхронизации механизмов инкрементации (например префиксы).

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

(61) меня коллизии особо не волнуют, ибо бизнес-процессы отлажены. самая головная боль была с потерей данных от филиалов при обменах - ложные подтверждения выгрузок наверное были. Эта схема решает эту проблему на 100%

(61) ну моя коллизии решал через четкое указание где какие объекты можно заводить/исправлять и куда они мигрировать могут

т.е. к примеру глобальные справочники (которые во всех базах) только в центре заводятся и т.д.

ЗЫ через версии слишком базы пухнут и(или) слишком медленный механизм синхронизации если еще и версии сверять по узлам

(63) тоже верно. Хотя есть документы, которые могут меняться в центре и на точке, но там разруливается через статусы. Пока статус документа не стал нужным, его не могут менять в точке или на центре, например. и усё.

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

>>Перед выгрузкой всегда загружаю у отправителя файл read от получателя, для всех объектов снимаю регистрацию (при этом контролирую, изменились ли объекты в базе и файле read), если изменились, не снимаю.

Как контролируешь? Номер сообщения там для этого вообще то.

(66) контролирую по соответствию объекта в базе и файле read.
если они одинаковые, значит с момента отправки в подч.узел объект не поменялся и его можно снимать с регистрации.

(66) то бишь зачем номера сообщений, если можно сравнивать непосредственно объект?

ну сравниваю не сам объект, а его значение после отработки событий ПриПередачеПодчиненному, т.к. иногда в процессе передачи объект меняется (например удаляются лишние записи из набора записей РС)

(68) дык вопрос на самом деле надо ставить так: то бишь зачем сравнивать непосредственно объект, если есть  номера сообщений?

ответ: быстрее выполняется и меньше кода.

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

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

(67)

объект имеет версию 01

База А - меняет версию на 02А
База А - читает файл read там версия 01
База Б - меняет версию на 02Б
База Б - читает файл read там версия 01

База А - записывает версию 02А в файл обмена
База Б - записывает версию 02Б в файл обмена

База А - читает файл, там версия 02Б, база А думает, что надо переслать заново и записывает версию 02А в файл обмена..

База Б - читает файл, там версия 02А, база Б думает, что надо переслать заново и записывает версию 02Б в файл обмена..

и так будет до посинения....

(72)
Чтобы не было такой чехарды, нужно передавать не все объекты, а только изменяемые поля.
Тогда, изменение соседних полей объекта не будет являться коллизией.

(56)
Одна из проблем циклического обмена - это повторная рассылка изменений по сторонним узлам - соответственно - при получении объекта приходится сравнивать его с текущими данными объекта в базе - если все данные совпадают, то приём объекта игнорируется и дальнейшая передача не ведётся.

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

(55) Если изменения объектов делать в одной базе, то можно посмотреть журнал регистрации и увидеть, кто менял документ.
В случае РИБ посмотреть проблематично - пользователи всё списывают на ошибку РИБ и сами же её производят.

Гений 1с опять велосипед с квадратными колесами изобрел
откажись от файликов, они зло

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

(76) А чем регистр сведений не устраивает ?
Просто, в 1с сделали очень "умное" стандартное решение, когда выбираются изменения в виде объектов, а не ссылок (жирного ежа им за это в зад), но регистр-то можно сделать со своими добавками, где отслеживать время изменения, узел, в котором оно сделано и узел, из которого оно получено.

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

(0) потери данных потому, что программист у вас гениален и вообще молодец - в почках не должно быть возможности менять данные, созданные в центре и наоборот

(79) Много бисера завалялось в карманах? :)

(80) есть такое. Если сейчас не найдк, куда деть, то на второй квартал бюджет на бисер порежут, иороды

вспомнил, что это все мне напоминает! КВИНТЭССЕНЦИЯ...

(78) Так для каждого объекта будет свой регистр - точно также - как и в табличной части (так как могут быть сохранены два изменения).

(70) но больше гиммора с номерами сообщений, опять же блокировка базы для переустановки номеров сообщений, понимаешь? огромные объемы транзакций при выгрузке. Нет-нет.

(72) у нас такого не бывает.

(75) я делал через COM эту же схему кстати, но очень медленно работает, поэтому отказался.

(77) (78) почему бы не юзать стандартный механизм хранения изменений, он вполне адекватный. Изменения при выборе их запросом как раз выдаются в виде ссылок и ключей записей, не надо ляля. а я выбираю запросом, чтобы не блокировать базу.

(79) не надо народных песен, со стороны смотрели, тоже не уловили почему потери проходят.

(87) я знаю когда потери, когда изменения делаются часто а обмены редко, есть такая тема...

когда делается 2 изменения подряд номер сообщения не меняется... и если вернется подтверждение первого пакета, то вторые изменения на перефирийку не прокатят...

это баян десятилетний... бороться с этим не так сложно, но в обыкновении такого не возникает...

(88) Номер сообщения сбрасывается если и три изменения подряд сделать. Номер сообщения при повторном изменении обнуляется, а значит, что изменение может пропасть лишь в период загрузки ответа, когда сброс номера сообщения происходит между формированием выборки объектов на удаление из регистрации по номеру сообщения и моментом удаления регистрации именно изменённого объекта.
Без блокировки по номеру сообщения не обойтись, но как заблокировать таблицы изменений...
Поэтому и приходится работать с объектами БД, а не с регистрацией, при этом про блокировку самого объекта на время от начала проверки до удаления его из регистрации тоже нельзя забывать, иначе - грош цена схеме в (0) описанной, ибо пока проверяется реквизит 6, меняется реквизит 1, а мы уже не знаем и с регистрации объект всё равно уходит, а был только что изменён.

(89)

предположим последнее сообщение имело номер 99

я записываю док1 (версия 221)
делается выгрузка пакета с номером 100
подтверждения нет....
я снова меняю док1 (версия 222)
выгружаю пакет (номер его будет то же 100, ведь состав пакета не изменился...)

если клиент получит последний файл - все будет хорошо, а вот если предпоследний то в центре будет версия 222 а в узле 221...

сабж легко проверить, если 2 раза изменить конфигурацию, и первое изменение слегка опоздает ....


по этому подтверждение по версии каждого объекта вроде как нужно, но для 99% обменов идеально работает текущая схема...

для 7.7 был МОД, для 8.х нету подобного к сожалению...

(90) У меня не РИБ, проверить нет возможности, но при обычных обменах - версия 222 сбрасывает номер пакета этого объекта в 0, т.е. - объект не выгружался. А новая выгрузка делает номера пакета 101, куда и войдёт версия 222. И, если ответ запаздывает, то объекты из обмена не удаляются вообще, пока ответ на последний посланный пакет не придёт.
У меня 50 узлов, обмен раз в три минуты, параллельный - беда приходит раз в неделю - потеря какого-то изменения.

(90) По уму каждая выгрузка должна инкрементироваться и для каждого измененного объекта при выгрузке должен прописываться именно этот номер выгрузки. А вот удаляться должны версии с равной или меньшим номером ответа.

(91) переходи на мою схему обмена. Я таки Гений, написал альтернативу РИБ, летает. ;-)

(0) очень много постов и телодвижений,геморроя напрямую не связанного ни с программированием ни с 1с ниш решением прикладных задач . Автоматизация обмена ради обмена. Не проще использовать одну базу данных ?

Причем все вешается на  затраты в виде оклада одного программиста 1с....... Тут можно только на поддержке обменов висеть и дальше никуда не двигаться т к времени не хватит

(94) нет, не проще. Это розница. Продавать надо и без интернета, если перебои, например. Да и канал даже в Москве не всегда широкий

(95) это паранойя, не боись.

(96) Проще делать систему с режимом OffLine, то есть когда связь есть, то изменения объекта отражаются в центральной базе в момент записи без всякой там регистрации и отсылки измерений, а если связь пропала, то пишем в таблицу изменений.

(90) Проблема 1С в том, что они пишут номер 0 для сообщений, которые ещё не отправлены. Если бы писался номер следующего сообщения, а при этом не затирался бы номер предыдущего, то не было бы никаких проблем.

(97) эта модель испытывает еще больше проблем чем Риб, гыгыгы...

а ты не пробовал битовский http://www.1cbit.ru/1csoft/bit-menedzher-obmena-dannymi-8-8/#/functional для своих целей?

(97) В семерке так и есть. Если в изменениях есть элемент то ему присваивается перезаписывается 0 и новым и измененным. А вот во время отправки им приваивается номер выгрузки больше на единицы предыдущей отправки. При получении ответа удаляются меньше или равно номеру ответа, за исключением нулевых.

(99) а смысл? моя хрень ложится поверх существующей риб без вопросов, а тут еще че-то менять надо, нет уж.

А ты разобрался откуда у тебя пошло: "самая головная боль была с потерей данных от филиалов при обменах - ложные подтверждения выгрузок наверное были" (c)? В чем причина сего?

(76)(89) просто вы два старпера, которые не в курсе что в больших сетках на 1с рулит обмен через веб-сервисы

(0) Жди третьего увольнения.

(103) Web-сервис - это средство для передачи данных, а не для отслеживания изменений.

(105) Ну можно привязать обращение на веб-сервис к транзакции записи объекта. Тогда отслеживать изменения и не надо особо. Только это может быть медленно. А может и не быть.

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

(0)Непонятно, чем твой метод избавляет от блокировок при выгрузке в центральной базе, или ты про удаленные точки?

(107) Может слетать при реструктуризации, другая база должна быть в досягаемости вытянутой руки. А если она в Гваделупе? Все-таки OLEDB через интернет не очень быстро..
Но вообще в транзакции делать обмен в любом случае какая-то хрень.

(109) Не делать, а инициировать.
Никто же не просит дожидаться окончания обмена перед завершением транзакции.
Да и вообще - в одинЭсе привыкли, что всё в один поток исполняется, а ведь можно же и параллельно многие вещи делать.

(110) К сожалению, парралельность не очень развита в платформе. Клиент-сервер только, без нормальных средств связи между потоками... После Delphi удивлялся - где же какой-нибудь synchronize()...

(111) через фоновые задания разве. да, параллельность лучше бы добавили вместо УФ

(105) слова не мальчика, но мужа.

(102) я не разобрался и привлеченный франч не разобрался. Отловить момент невозможно.

(112) Ну найти то проблему не сложно. Нужно сохранить выгрузки и ответы. И сравнить объекты начиная от последних выгрузок. И тогда можно  будет понять какие выгрузки не попали. И сравнить с ответами.

Разумеется запоминая уже сравнённые объекты и исключать их при дальнейшем сравнении

(113) это сложно. проще написать новую разумную схему

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

P.S. посмотри просто приоритеты изменений.

(115) и сделать новые ошибки, которые потом будет проще не искать а писать новую схему

и так до бесконечности :)

(115) Там на коленке написать сравнение объектов по метаданным. А объекты считываются через сериализатор. Зато можно найти причину, что бы не напороться на неё в своей схеме.

(116) (117) если уйти от порочной схемы на более простую, ошибок будет меньше

(115)  нифига не проще
Комуто просто было влом работать кропотливо
То ли тебе
То ли франчу

Даже как неспец совсем тупо бы сделал по факту установки расхождения между базами методом половинного деления восстановление из бэкапов базы там и тут и сравнения объектов там и тут

(119)  простые схемы имееют тенденцию превращаться в сложные в условиях отсутствия возможности четких регламентов

(90)предположим последнее сообщение имело номер 99

я записываю док1 (версия 221)
делается выгрузка пакета с номером 100
подтверждения нет....
я снова меняю док1 (версия 222)
выгружаю пакет (номер его будет то же 100, ведь состав пакета не изменился...)

Ради интереса проверил. 8.2.19.90. Создал конфу с одним доком. КАЖДАЯ выгрузка имеет свой номер. Даже если ничего не менял в базе.

Так что ничего пропадать не должно.

(102) Небось в тестовых копиях работали регламентные задания обмена ))

(0) как конфу передаёте в вашей схеме?

(123) кстати очень может быть, классические грабли :)

Весь мир уже давно пользуется плодами прогресса, один только Гений1с до сих пор трахается с распределенными базами. Если найдется умный человек и покажет его руководству какие выгоды те получат от единой базы и прикинут затраты на РИБ и на единую базу начальство Гения будет просто в шоке.

А теперь по сабжу, по сути это лисепед очередной при чем без тормозов ибо тормоза придумал трус.

почему лисапед? кто тут предложил рабочее решение для обмена 1000 точек розницы? я не видел, покажите, куплю

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

(129) вы считаете, что всегда есть возможность засунуть всех пользователей в единую базу? представьте, что вам необходимо автоматизировать фронт макдака. будете останавливать продажи бургеров из-за пьянового дяди который центральную магистраль положил?

(130) Я бы на фронт в макдаке, 1с вообще бы не ставил.  Там впрочем именно так и сделали.

(131) так о каких плодах прогресса вы говорите, которые избавляют от секса с РИБом ?

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

(128) пАтамучтА лисапед он и есть лисапед. И нифига он не решает проблему обмена с 1000 точек розницы.
В мобильной платформе РИБ вообще не используется. Ввиду ограниченных возможностей платформы. А обмен работает и отлажен и методики выложены. Сырьоже их просто влом изучить. Начил изобретать лисапед.

(133) полно магазинов у которых на фронте 1с, для примера Hoff, 3 кита, да и вообще почти все хозяйственные, мебельные, автомобильные и т.д.

разумеется на супермаркет 1с ставить это не айс, но это ПОКА !!!

И тут скорее дело в лицензиях а не в техническом развитии...

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

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

2. Упр конфигурация - там проги делают чего от них хотят, конфигурация меняется часто. От нее узлы - в магазины

---------------------------------------------
обмен продаж
касса -> база фронта магазина -> центральная база фронта -> урп центральная база -> упр база магазина

---------------------------------------------
обмен цены, номенклатура
урп центральная база -> упр база магазина
урп центральная база -> центральная база фронта -> база фронта магазина -> касса

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

(133) это не возможно получить инет в любой точке мира. в наших точках за уралом до сих пор файлики обмена на флешках переносят. причем не достаточно иметь просто инет, наверно вам не надо говорить, что он должен быть стабильным и широким.
не понял вашего вопроса. мы работаем на данных, которые на 95-97% показывают правду в учете, понимаем это и закладываем риски. Вы предлагаете отделу продаж не знать о продажах вовсе, чем знать что мы продали 10000 штук +-500штук?

(135) на практике фронт меняется очень часто, чем хотелось бы, вашу схему очень тяжело поддерживать

(137) Я предлагаю нормально организовать работу тех кому надо планировать продажи поставки и т.д. чтоб в определенный момент у них была точная информация.

(139) уважаемый коллега, с каким максимальным количеством точек розничной сети вы сталкивались в сталкивались? кажется, что вы хотите нагнуть бизнес пользователей со стороны IT. я ни в одной конторе не видел, чтобы что-то было организовано нормально, особенно в продажах. вчера бакс вырос, сегодня санкции. как в этих условиях что-то нормально организовывать?

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

(141) и всё же представим, что звёзды сошлись и инет есть везде. о каком решении вы говорили ранее?

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

+(143) А то что кассиру нежрен делать в центральной базе это просто не обсуждается.

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

(145) Да,  именно так а все остальное от лукавого.

(144) я думал мы говорим о рознице, у которой ~1000 точек и о том как ускорить выгрузку\загрузку с этими точками ... (145) так и делаем :) но с каждой точкой обмен 2-3 минуты, а их 1000. сколько часов будем обмениваться? :)

(147) У вас в один момент времени база может принимать данные только от одной точки?

(148) давайте сразу перейдем к выгрузке? так как с параллельностью загрузки никогда проблем не было в платформе 1с

(147) А в чем проблема с сумарной выгрузкой? Уж точно максимум 2-3 секунды.

(149) А какие проблемы с выгрузкой?

(147) Для розницы я бы сделал регистрацию выгружаемых объектов из центральной базы по дате времени с индексом по дате времени. А при запросе данных выступала бы максимальная полученная дата.
Лучше конечно использовать номер транзакции. Но и даты достаточно. Всегда можно передавать избыточные данные и загружать данные с предварительным сравнением

152 в регистре сведений.

Да еще можно регистр сведений с ответами, где хранится максимальное время ответа от каждого магазина, для чистки регистра изменений

(147) такие вещи делают с промежуточной консолидацией, о чем я и писал ранее...

(124) целиком. выгружаю в спец каталог с именем файла например config_2014_03_22.cf

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

при входе если ГУ отвязан, он привязывается и перезапуск.

Плюс: перестали возникать ошибки "Конфа не соответствует ожидаемой".

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

(123) я такое встречал, да, но там номера сообщений мелкие, не грузилось. Да бывало такое, но это быстро находится и лечится. реально классические грабли. Проблема то не в этом.

(126) ты будешь удивлен, но Единая База рассматривалась и была послана .... в лес. Ибо гладко на бумаге, но я указал, где овраги. и слава богу.

(129) в чем будет гимор, интересно? гыгыгы.... в частном данном случае наоборот, решилась куча проблем. Особенно с блокировкой.

(133) вы батенька идеалист, наверное считаете что в любой точке москвы можно получить шикарный интернет. Вынужден вас разочаровать. Увы и ах, особенно в ТЦ порой с интернетом туго.

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

(136) не только. Еще на фронте нужна приемка товара, контроль остатков и ревизии.

(161) У вас конечности не с того места растут.
У меня, почему-то, даже в поделке на VbScript, которая через тот же самый драйвер работает, но она не только знала, пробит чек или нет, но и умела проверять, что он оформлен правильно в ЭКЛЗ.

(162) Вот когда начинается приёмка товара с вводом нового, то сразу возникает вопрос - как это вообще можно вести в единой базе или в РИБ, так как одинаковые товары вводятся разными операторами в разные позиции.
Поэтому, если нет электронного обмена с поставщиками и они не во всех точках совершенно одинаковы, то вообще нафиг не нужна попытка объединить базы - достаточно сделать базу, в которой будут консолидироваться результаты.

(157) вот это жестко.

(105) а я как раз про механизм передачи данных

(157) почитай на 50 оттенков мутнее, там как раз про такое

(161) Вообщем при пробитии чека аппарат возвращает код успеха. Если нет кода успеха - значит ошибка - в чем проблема принципиальная?

(161) это в любом ПО так, 1С не при чем
другое дело что 1с после поднятия могла бы и слазить в фискальник за информацией, пробился чек или нет.

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

(169) Просто, если связь пропала, то её нужно восстановить.
У меня, например, система перед пробитием чека запоминала номера операций в ФР-е и в случае потери связи проверяла сначала номера документов - если они не изменились, то операция на ФР-е не прошла, а если изменились и чек закрыт, то считается, что чек пробит.
Потом, отменять транзакцию в случае не пробития чека на ФР-е вообще нет смысла. Пробивать чек нужно не в транзакции, а отдельной обработкой, сделав запись документа до (с признаком начала пробития чека) и после (с признаком окончания).

(170) это все припарки мертвому, ненадежные. В DrvFr1C нет метода для проверки завершенности транзакции. Это странно. С таким подходом супермаркеты не автоматизировать, гыгыгы...

(169) да, там штук 5 комбинаций. комп может тупо перезагрузиться, когда чек пробьется, и 1с не получит подтверждение пробитости чека, например.

(163) как как. У товара ставится признак Новый и периодически новые товары синхронизируются, дубли заменяются. делов-то.

(163) на уровне драйвера можно все получить, да.
но 1с не позиционирует себя как надежное решение для розницы, т.к. в типовом драйвере DrvFR1s нет возможности для проверки законченности транзакции. Вот и вся малина

(174) В типовом драйвере есть метод, позволяющий получить состояние ФР-а и даже данные из ЭКЛЗ, чтобы не только понять состояние последнего чека, но и нужного чека по номеру - у меня так и работало. Причём, дату-время завершения чека только из ЭКЛЗ и можно получить, так как получение даты-времени до начала завершения чека не даёт гарантии, что он именно тогда завершится.
Конечно, всё без танцев с нескольким количеством бубнов не обходится, но, если захотеть, то всё получается.
И база данных в текстовых файлах тоже получается.

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

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

гнать сцаными тряпками!

+ (176) Помимо прочего РИБ в мобильной платформе не поддерживается. Но методика обмена прописана в штатной документации. С использованием планов обмена и фильтрацией по реквизитам участвующих в обмене данных.
Одна пичаль. Это читать надо. И не пропишешь "мой гений дарит вам". А к "безобразную г0вноподелку" - влегкую.

На самом деле, проблема работы ФР даже не в драйвере - она глубже.
Начнём с того, что ФР как и любой принтер - пассивное устройство, то есть оно не умеет передавать команды в компьютер, а только отвечает на переданные компьютером.
В случае печати и завершения чека фискальные регистраторы Штрих-М (и Атол, так как они "потомки") выполняются команду за два этапа - сначала проверяется режим и возможность выполнить команду, потом выполняются вычисление и выдаётся ответ компьютеру, а только после ответа начинается печать чека.
Поэтому, чтобы узнать у ФР-а напечатал он чек или нет - нужно давать отдельную команду - запрос состояния (для ФР-а Штрих-М не так часто, так как эта команда очень замедляет исполнение печати).

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

(179) Как раз у Штрих-М фискальник отвечает "закрытие чека выполнено успешно" и только начинает печатать чек. Понятно, что отменить чек после этой команды нельзя, а критические ошибки ФР-а рассматривать не обязательно, так как после них ФР отправляется в сервисную организацию, но, например, окончание бумаги в процессе печати требует выдать пользователю сообщение о том, что её нужно заменить, а также дать команду продолжения печати, чтобы допечатать чек на новом рулоне.

P.S. работа с ФР и другим торговым оборудованием с РИБ никак не связано.

(181) По вопросам обмена рекомендую http://its.1c.ua/db/pubintromobile#content:117:hdoc. Там есть все, что сырожа пытается представить прорывом.

(182) Правда там основным транспортным каналом рекомендуют Web-сервис. Но в легкую обмен дополняется обменом файлами сообщений. И это там тоже есть.

(183) Канал не важен - есть проблема, когда все узлы (например, вечером) должны обменяться с центром.

(184) Поделка от сырьожи эту проблему никак не решает.

+ (185) Нужна запись измененных данных - она должна быть выполнена. Параллельная запись в одну таблицу БД - это фантастика даже в исполнении сырожи.

(186) Параллельная запись в одну таблицу - для нормальных SQL-серверов - это повседневная реальность.

(188) Да ладно... Я же не настаиваю на том, что это невозможно. Я говорю, что при любом варианте записи нужно время. И переименование файлов из send в read этот процесс никак не ускорит.

(188) Ну, поставьте FireBird и посмотрите, как оно работает - можно даже в одну строку параллельно писать, только вот второму будет "сюрприз" при COMMIT-е.
Так что, думаю, взрослые SQL-сервера тоже это умеют, если не из коробки, то после настройки.
Просто, если "хорошим" программистам 1С дать такой инструмент, то "гвоздей назабивают аш мама не горюй".

(169) речь про другую ситуацию, когда 1с рухнула.
фискальник сам по себе очень надежен и его ПО падает на порядок реже.

(191) Можно перед пробитием чека записать его содержимое в текстовый файл, чтобы потом можно было восстановить.
Но, если сделать запись до пробития и запись после, то ничего теряться не должно.
Случай, когда база 1С "отправилась коту под хвост" мы не рассматриваем как и случай, когда "за фискальником пришёл белый лис".

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

(175) и как называется типовой метод из DrvFr1s, дружище? гыгыгы...

(176) штатный риб не значит лучший риб. ;-)
горе поделка работает лучше штатного риб, как быть? чую холивар

(191) вот именно. 1с упала и чек не получит подтверждения от фр.

(191) или кабелек задели и подтверждение не прошло в 1с.

(192) она не отправилась, комп перезагрузился. Скажем так, при объеме 100 магазинов с нагрузкой 100 чеков в день в среднем случалось 2-3 коллизии с ФР при штатной схеме подтверждения.

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

(193) да, об этом есть моя статья на ИС, вот как раз после этого и начались потери данных. ;-)
поэтому перешел на альтернативный РИБ.

(182) Стыдно давать ссылки на закрытые ресурсы, не комментируя содержимое.

(198) штатные схемы вообщем страдают херней обычно. Хочешь чтобы работало устойчиво и быстро - надо переписывать. Это еще и на семерочной рознице так было.

GetEKLZDocument ПолучитьДокументЭКЛЗ
Метод позволяет по номеру КПК, который следует указать в свойстве KPKNumber, извлечь из ЭКЛЗ и распечатать документ, соответствующий этому номеру. Перед вызовом метода в свойстве Password указать пароль системного администратора. В свойство UDescription возвращается название ККМ из ЭКЛЗ.

(201) Лучше смотреть в сторону GetEklzState, так как там можно увидеть дату и время последнего документа.

------------------------------------------------
eeeio
193 - 17.03.15 - 03:10
Если не ошибаюсь, то для избавления от проблемы блокировки при выгрузке (и если не страшен риск ущерба целостности данных) достаточно установить размер транзакции = 1 (ну или 100).

------------------------------------------------
Гений 1С
199 - 17.03.15 - 10:11
(193) да, об этом есть моя статья на ИС, вот как раз после этого и начались потери данных. ;-)
поэтому перешел на альтернативный РИБ.


------------------------------------------------
Прикольно, сначала появились блокировки

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

ничего в нашем мире не меняется !!!

Размер транзакции в 1 объект не должен приводить к потере данных, так как транзакция всё равно будет отрабатываться.
А вот отказ от транзакций вообще действительно может приводить к потере данных из-за блокировок, которые таким образом отменили.

(205) если транзакция отменяется, то и вся выгрузка отменяется как бы. не вижу проблемы

(209) та ладно, мы вот как бы не видим проблемы юзать стандартный механизм риб (слегка отшлифованный)

(210)+ вместо какой то неведомой ...

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

Не знаю как реализация, но сама идея пообъектной выгрузки и пообъектного снятия регистрации горазда лучше типового 1с риба и пачками изменений

(213) гы, а пухнущая база не мешает? когда 100+ узлов? для каждого нужно каждый измененный объект хранить не? вместо пакета?

(213) Эта идея как раз и тесно связана с "Потерей данных при обменах. Непонятно почему происходит, началось после введения параллельных выгрузок на точки."

Вы же тупо теряете ссылочную целостность. Аккуратно ее восстанавливать и есть решаемая задача.