В УТ настроен обмен с Розницей по правилам обмена через COM-соединение.
Хочу, чтобы при выгузке из УТ в Розницу (из базы-отправителя в базу-получатель), когда документ передан в базу-получатель и зарегистрирован в отложенных движениях, чтобы он удалялся из плана-обмена базы-отправителя (УТ).
Т.к. иногда выгрузка не доходит до конца, или же не получает подтверждения, чтобы данные повторно не гонялись.
(3) лунс, обмен по правилам идет через COM-соединение. Забыл уточнить. Соответственно, квитанция не нужна.
Если передал, то зашибись.
(2) спасибо, но этого мало. Нужно еще в место ткнуть, где происходит обмен, т.е. куда эту фигню вставить и как отличить от обмена не через COM-соединение.
(1) fixin, Для автоматической очистки регистрации изменений сделай обмен двухсторонним, т.е. из Розницы тоже что-нибудь выгружай в УТ по этому же узлу обмена. Настрой расписание выгрузки из Розницы в УТ, дабы очистка регистрации изменений была автоматической.
(1) fixin, прочитайте мой пост № 61, он больше недели уже висит.
Хотелось бы знать: подходит - не подходит, или вообще не о том, что нужно.
Ну, мне-то кажется, что подходит, но хотелось бы знать Ваше мнение.
(65) motorkuzbassa.it,
Ну что ж, давайте рассмотрим сообщение (22), а точнее, (21), но которое оно было ответом.
Цитата из (21):
"Регистрация очищается обработкой обмена данными, когда она прочитает ответ об успешности загрузки объектов в базе приемнике."
- Да, действительно, в типовой обработке обмена данными сеанс обмена начинается с чтения сообщения из базы-приемника. То есть, ответ об успешности загрузки объектов в базе приемнике будет прочитан в следующем сеансе обмена. Это будет сообщение об успешности всей загрузки в целом, а если хоть один объект не удастся загрузить, то и ответа об успешности не будет. Во всяком случае, если у нас не COM-соединение, то передается или не передается всё. В (21) именно это имеется в виду. Цитата из (21):
"удаленность баз конечно хорошая, поэтому COM-соединение не подходит".
Поэтому ясно, что такое решение для fixin, насколько я понимаю, неприемлемо.
Если повнимательнее приглядеться к тому, как происходит обмен в типовой обработке при COM-соединении, то мы обнаружим, что каждый объект передается по отдельности, при этом тут же (не после того, как все объекты будут переданы!) возвращается результат успешности его прочтения. Кроме того, в указанном мной в (61) месте программы есть возможности для идентификации этого объекта. Стало быть, в это место и надо воткнуть процедуру удаления его регистрации. Так что независимо от того, будет ли неудача при передаче других объектов в этом сеансе, данный объект уже будет исключен из набора объектов для передачи в следующих сеансах.
Ну, конечно, надо не забыть о том, что загрузка сообщения обмена не должна осуществляться в одной транзакции...
Да, кстати, Вы пишете: "он уже поковырялся час" - если имеется в виду, что советы уже не требуются, то я бы ожидал, что fixin самолично закрыл бы эту тему. А так не понятно.
Где мУзловВыгрузки - массив узлов для которых производится удаление регистрации.
Объект - Объект для которого необходимо отменить регистрацию (тип значения - ДокументОбъект/СправочникОбъект
Ну а как заполнить массив узлов думаю догадаешься.
ну наверное можно подпиской на событие в рознице фиксировать куда либо загруженные объекты (гуиды), например в файл.
потом уже в ут считывать их из файла и чистить таблицу регистрации.
определить в рознице что обмен через ком, можно возводя глобальную переменную из ут, а рознице проверяя ее в подписке.
должно получиться и изменений минимум.
(5) это более гиморно, чем воткнуть в обработку выгрузки через COM. Т.к. нужно будет потом эти GUID соотносить по регистру СоответствиеОбъектовОбмена (они могут быть разными) и т.п. Писать доработку надо на стороне УТ.
(6) не фига не гиморно.
у тебя обработка на стороне ут работает.
используется обменданнымиxml типовой, там много мест менять надо.
а так, ты в конце типовой обработки встроишься и все.
(8) fixin, а не лучше ли это сделать на уровне правил обмена?
Встает только один вопрос где именно, поясни алгоритм по которому ты хочешь удалять регистрацию.
К примеру:
У нас на регистрации 10 документов, пошел обмен, 5 документов загрузились успешно, на 6-ом ошибка - обмен остановился, при следующем обмене идет повторная выгрузка всех десяти - что собственно и не устраивает. Вопрос: мы должны снять с регистрации в таком случае 5, 6 или же 10 документов (в зависимости от этого нужно выбрать подход к решению)?
(54) fixin, как говорится, возможно все. Вопрос в том что геморно очень. Как минимум без регистра соответствие объектов для обмена не обойтись, так как получается тебе нужно в момент чтения пакета на стороне приемника выдавать информацию для снятия с регистрации объектов в источнике, а ссылки на эти объекты ты получишь только по регистру. (хотя пока писал этот текст появилась мысль - осмыслю ее отпишу).
(55) lex271, (56) nevrex, Ребята, это стандартный механизм обмена, который итак работает, но вопрос о ситуации выходящей из стандартного алгоритма типовых обменов - здесь при загрузке возможен отказ и тогда не будет никакого ответа из базы-приемника.
(57) nevrex, Делать это в указанном модуле - глупость потому что процедура вызывает обработчик события ПВД и дописки нужно добавлять именно в правила в этот обработчик - для того оно собственно и сделано. А во-вторых этот способ самый простой, но опять-таки не подходящий. Я писал пример в (52) - в таком варианте все выгружаемые обекты будут сняты с регистрации, а нужны только те, которые успешно записались перед тем как обмен упал на стороне приемника.
т до конца, или же не получает подтверждения, чтобы данные повторно не гонялись.а не доходит до конца, или же не получает подтверждения, чтобы данные повторно не гонялись. не доходит до конца, или же не получает подтверждения, чтобы данные повторно не гонялись.
Переделываешь на обмены через файл, в базе приемнике - ответ по пустым правилам. И все хорошо работает - удачно если загрузилось, то регистрация очищается.
P.S. Когда дорабатывается то, что можно решить типовым способом - это плохая доработка.
(19) меня прикалывают такие советы. Сломать хорошую схему, сделать еще более плохую, чтоб было еще больше проблем... Клево...
Регистрация очищается кем? После получения ответного пакета? Ага, шас...
Регистрация очищается обработкой обмена данными, когда она прочитает ответ об успешности загрузки объектов в базе приемнике.
У меня десятки обменов по этой схеме работают, правда удаленность баз конечно хорошая, поэтому COM-соединение не подходит. Ничего плохого в этой схеме не вижу. Решения вам уже писали, куда воткнуть - нужна глубокая препарация модуля обработки Обмена данными XML.
(21) это решение не моей проблемы.
я хочу, чтобы объект передавался только один раз и тут же исключался, чтобы не было коллизий.
А вы мне советуете совершенно не подходящее для меня решение.
Советы типо "поменяйте на файловый обмен" я и сам дать могу, только мою проблему это не решает.
Тем более я знаю, что можно после передачи удалить регистрацию и спрашиваю только о месте, куда воткнуть. За это и даю деньги. Самому поковыряться час и найти можно, но лень.
сделай обмен двухсторонним, т.е. из Розницы тоже что-нибудь выгружай в УТ по этому же узлу обмена. Настрой расписание выгрузки из Розницы в УТ, дабы очистка регистрации изменений была автоматической.
а за чем удалять регистрацию в ручную? обмен через com отлично снимает регистрацию сам, только надо правила в обратную сторону настроить, если обмен обратно не нужен, достаточно указать пустые правила, создав их в конвертации.
(38) ну что мы ходим по замкнутому кругу-то?
речь идет о том, если обмен спотыкается и не получает ответа.
тогда он начинает повторно выгружать с начала...
(39)так это правильно, иначе у вас будут не все данные загружены, обмен пометить их выгруженными только в том случае когда можно будет проверить что все выгрузилось успешно, иначе надо переписывать обработку ОбменДанымиXML так что бы при выгрузке каждого объекта снималась регистрация, но мне почему то кажется что это не самый правильный путь.
1. В обработке ОбменДаннымиXML в модуле объекта есть
функция ВыгрузкаОбъектаВыборки (..........)
далее идет ВызватьСобытияПослеВыгрузкиОбъекта(Объект, ПравилоВыгрузки, Свойства, ВходящиеДанные,
НеВыгружатьОбъектыСвойствПоСсылкам, ИмяПКО, Отказ, ИсходящиеДанные);
после поставить условие если не отказ то необходимо удалить регистрацию изменений вот так:
// найдем сначала узел обмена из которого надо удалить данные например так
узел = ПланыОбмена.ПоМагазину.НайтиПоНаименованию("Центр");
// далее собственно удаляем из регистрации изменений для обмена
ПланыОбмена.УдалитьРегистрациюИзменений(Узел, Ссылка);
// собственно "ссылка" - должна быть именно ссылка на объект не сам объект в этом модуле тогда надо ее получить.
Как то так.
В итоге мы получаем: после успешной выгрузки одного элемента мы удаляем данную ссылку из обмена. (данную обработку обмен данными XML смотрел в УПП но в УТ она такая же с незначительными изменениями)
Добрый день.
Есть типовая обработка Регистрация Изменений Для Обмена. В УПП она есть. Также есть на данном сайте. Если не найдёте могу бросить на почту
Кстати, при обмене по правилам через ком. принцип передачи данных все равно тот же - через файлОмена. Просто он создается в темпе и удаляется потом. но сперва так же идет запись по правилам в хмл-файл, а потом идет его разбор.
очищается обработкой обмена данными, когда она прочитает ответ об успешности загрузки объектов в базе приемнике.
У меня десятки обменов по этой схеме работают, правда удаленность баз конечно хорошая, поэтому COM-соединение не подходит. Ничего плохого в этой схеме не вижу. Решения вам уже писали, куда воткнуть - нужна глубокая препарация модуля обработки Обмена данными
после поставить условие если не отказ то необходимо удалить регистрацию изменений вот так:
// найдем сначала узел обмена из которого надо удалить данные например так
узел = ПланыОбмена.ПоМагазину.НайтиПоНаименованию("Центр");
// далее собственно удаляем из регистрации изменений для обмена
ПланыОбмена.УдалитьРегистрациюИзменений(Узел, Ссылка);
// собственно "ссылка" - должна быть именно ссылка на объект не сам объект в этом модуле тогда надо ее получить.
В итоге мы получаем: после успешной выгрузки одного элемента мы удаляем данную ссылку из обмена.
Теперь о деле. Я вижу только извращенный немного способ. Не смотря на то, что обмен идет по КОМу, сам КОМ при загрузке ты не выцепишь. Но ничто не мешает после успешной записи объекта открыть новый ком в базе приемника к базе источнику. Параметры подключения при обмене можно все собрать. При разборе хмл правилами в нем есть GUID ссылки в источнике, не помню насколько он доступен будет при загрузке. Если доступен, его можно использовать, если нет придется цеплять его же из рег. Соответствие. Открыв обратный ком уже можно снимать регистрацию для ком-объекта по написанному выше раз 20 методу.
Если такой вариант не катит, то тогда мне кажется самым логичным останется тот, о котором писали, выкидывать список гуидов в файлик при записи объектов в приемнике, а потом его считывать где-то в конце цикла обмена.
Точнее не так. Память немного подводит. Но тут порядок обмена имеет еще свою особенность:
сперва вызывается обработка загрузки из удаленной базы (для обмена через файл чтение ответного файла) тут как раз иприходит квитанция о придыдущем обмене ( и тут-то и нужно снимать с регистрации те объекты которые были выгруженны в прошлой итерации обмена, если обмен был успешен то типовой механизм квитанции здесь ее и снимает собственно)
И уже вторым шагом проводится выгрузка в в удаленную базу объектов в соответствии с регистрацией на узле
Следовательно если мы будем после прохода типовой квитанции проверять наличие файлика и если он найден то получать по нему ссылки, которые нужно снять с регистрации (ЗначениеИзСтрокиВнутр() -На всякий случай напоминаю метод) то в выгрузку они уже не пойдут, что собственно и нужно. Тогда остается только заполнять этот файлик после успешной
Вообщем вывод таков сделать это можно одним из двух способов, оба реализуемы на уровне правил, какой удобнее и лучше нужно тестировать скорость (как бы ком слишком не тупил). Кстати ком оптимально открывать в глобальном событии ПередНачаломЗагрузки() и вешать в параметры правила, которые доступны всем остальным обработчикам
Если появятся вопросы по конкретики, что где реализовать лучше - пиши, посмотрим, самому уже интересно, только времени пробовать пока нет)))
Еще мысль - если ком не устраивает а файлик не удобен. Можно захреначить и в иточник и в приемник константу строковую неограниченной длинны. При успешной записи документа добавлять гуид в константу через разделитель. Потом засунуть в обратные правила ПКО для константы и переносить тем самым в источник. А перед Выгрузкой из источника делать тоже самое что и для файлика в посте выше, только брать из константы и очищать ее после этого
В обработке ОбменДаннымиXML есть процедура ЗаписатьВФайл(Узел), которая вызывается при отправке очередной порции данных в приемник. Вот ее текст:
Если ТипЗнч(Узел) <> одТипСтрока Тогда ИнформацияДляЗаписиВФайл = Узел.Закрыть(); Иначе ИнформацияДляЗаписиВФайл = Узел; КонецЕсли;
Если НепосредственноеЧтениеВИБПриемнике Тогда СтрокаОшибкиВБазеПриемнике = ""; ПередатьИнформациюОЗаписиВПриемник(ИнформацияДляЗаписиВФайл, СтрокаОшибкиВБазеПриемнике); Если Не ПустаяСтрока(СтрокаОшибкиВБазеПриемнике) Тогда ВызватьИсключение СтрокаОшибкиВБазеПриемнике; КонецЕсли;
Иначе ФайлОбмена.ЗаписатьСтроку(ИнформацияДляЗаписиВФайл);
КонецЕсли;
Название процедуры не должно пугать: в случае COM-соединения никакой записи в файл не выполняется (в этой ветке было предположение, что идет запись во временный файл, но на самом деле это не так).
В этом месте в переменной "Узел" по форме - либо строка, либо объект типа ЗаписьXML, из которого после выполнения метода Закрыть() получается строка. Что в этой строке - все-таки надо уточнять. В процессе выгрузки, как правило, там собственно и находится выгружаемый объект, т.е. то, что ограничено тэгами <Объект>... </Объект> (включая сами эти тэги), либо набор записей, ограниченный тэгами <НаборЗаписей>... </НаборЗаписей>. В случае COM-соединения все тэги должны быть закрыты, иначе данные не будут прочитаны.
Теперь посмотрим на процедуру ПередатьИнформациюОЗаписиВПриемник(). Вот ее текст:
Если Не ПустаяСтрока(СтрокаОшибкиВБазеПриемнике) Тогда ЗаписатьВПротоколВыполнения("ЗАГРУЗКА В ПРИЕМНИКЕ: " + СтрокаОшибкиВБазеПриемнике, Неопределено, Истина, , , Истина); КонецЕсли;
К сожалению, переменная УспешноПереданыДанные, отвечающая за успешную загрузку на стороне приемника, никуда не передается, однако есть однозначная связь: УспешноПереданыДанные соответствует пустой строке СтрокаОшибкиВБазеПриемнике, что, собственно и используется в вызывающей процедуре ЗаписатьВФайл().
В этом месте в переменных ИнформацияДляЗаписиВФайл и Узел находится вся информация о передаваемых данных, в т.ч. если это объект базы данных, то можно определить, что это за объект. В случае набора записей там содержится информация об отборе и о каждой записи набора.
Таким образом в процедуре ЗаписатьВФайл() можно, во-первых, проидентифицировать отправленный объект, во-вторых - сделать вывод об успешной/неуспешной его загрузке в ИБ-приемник.
В УТ настроен обмен с Розницей по правилам обмена через COM-соединение.
Хочу, чтобы при выгузке из УТ в Розницу (из базы-отправителя в базу-получатель), когда документ передан в базу-получатель и зарегистрирован в отложенных движениях, чтобы он удалялся из плана-обмена базы-отправителя (УТ).
Т.к. иногда выгрузка не доходит до конца, или же не получает подтверждения, чтобы данные повторно не гонял
Покамись решил вопрос просто.
В настройке обмена вместо шагов Загрузка - Выгрузка поставил шаги Загрузка - Выгрузка - Загрузка
это должно снизить вероятность коллизий.
до вмешательства в обмен руки пока не дошли. дойдут - проверю
Сорри, что не читаю всех сообщений. Буквально месяц назад настраивал схему обмена между УТ и БП. В (67) не понимаю, зачем делать повторно загрузку. Если хотите поковыряться в правилах - могу выслать. У меня из БП грузятся только платёжки, несколько справочников и регистров. Всё весело и без проблем летает.
Соответственно нужно вызвать метод (УдалитьРегистрациюИзменений (<Узлы>, <Данные>))
где в качестве данных указываете номер этого сообщения.
Конечно, можно удалять регистрацию по элементам как предлагают выше, но в этом случае возможно рассогласование данных.
Описание из документации Если в качестве первого параметра указан одиночный узел, то в параметре может быть указан номер сообщения. В этом случае метод УдалитьРегистрациюИзменений удаляет из всех таблиц регистрации изменений все записи относящиеся к указанному узлу, у которых номер сообщения меньше или равен значению второго параметра.
Односторонний обмен ЗУП(2.5.52.2) в УПП работает. В ЗУПе в ОбщиеМодули.ПроцедурыОбменаДанными в процедуре "ЗафиксироватьЗавершениеОбмена" добавил код перед коментарием "// надо изменения отразить в обработке автоматического поиска"
// регистрирует что обмен был произведен и фиксирует информацию в протоколе
Процедура ЗафиксироватьЗавершениеОбмена(СтруктураДанныхНастройкиОбмена, Знач СтрокаСообщенияОбОшибке = "",
Знач НеВыводитьИнформациюПользователю = Ложь, ОбработкаОбменаПриемника = Неопределено)
Если УдачнаяЗапись Тогда
ЭтотУзел = ПланыОбмена.Z_ЗУП_УПП.ЭтотУзел();
УзелОбменаУПП = СсылкаНаНастройкуОбмена.УзелИнформационнойБазы;
Если СтруктураДанныхНастройкиОбмена.ТекущийУзелПланаОбмена = ЭтотУзел Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбменаУПП, УзелОбменаУПП.НомерОтправленного);
КонецЕсли;
КонецЕсли;
Исключение
КонецПопытки; //sergoff. Конец
// надо изменения отразить в обработке автоматического поиска
В Конвертации Данных есть обработка для очистки изменений, РегистрацияИзмененийДляОбмена82. Там все возможные варианты работы с планом. В вашем случает только ПланыОбмена.УдалитьРегистрациюИзменений(мУзловВыгрузки,Объект). Однако даже в одностороннем обмене желательно бы получать квитанции о загрузке. Иначе будут проблемы с "Объект не найден" (гарантирую) - а выправлять их долго и нудно даже обработкой (так как перед этим тестирование ссылок и их последующим удалением делать надо). Все же лучше выправить обмен чтобы завершался всегда.
У меня месяца 4 уже работает через COM-обмен УТ10 - Бухгалтерия.
В обмене включены Загружать данные, Выгружать данные. Из бухгалтерии передачу документов и справочников запретил, правила загрузки на всякий случай обнулил. Подтверждения приходят нормально, регистрация снимается.
Проблемы с выгрузкой были сначала по справочнику контрагентов - оказалось с предыдущих обменов испорчено 2-3 элемента, да так, что даже в бухгалтерии если зайдешь в справочник в этот элемент-виснет. Убрал ошибки, зараз выгружал тысяч по 30 документов-сбоев не вижу. Три-четыре раза обмен запущу-все регистрации снимаются.
Вот интересно с COM-соединением: если приемник что-то не возьмет-он по всем высланным объектам снимет регистрацию или по части?
Автору уже все на блюдечке приподнесли, что делать какими процедурами - осталось только часик на отладчик убить - а вопрос открыт уже полгода. И не стыдно автору быть настолько ленивым? :)
Если на 100% уверен, что док передался, тогда можно почистить обработкой: РегистрацияИзмененийДляОбмена82, там же есть все методы для работы с планами обмена. Но лучше все-таки получать квитанции нормально, и все будет чиститься само-собой.
Попробую обновить тему. При одностороннем обмене выгрузка же проходит успешно, о чем и сообщает большая зеленая галка. Зачем же еще ответа какого-то ждать?