Исправление двуглавой РИБ и фильтрация обмена

Обратился один начинающий программист 1С с просьбой помочь настроить РИБ для УТ 10.3, фильтровать некоторые документы при отправке на РИБ.

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

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

Наведя курсор на замочек, я увидел надпись «Изменения конфигурации заблокированы средствами распределенной ИБ». Но ведь утверждалось же, что узел главный?

Я заглянул в план обмена и там увидел вот такую картину:

К сожалению, 1С в справке к планам обмена не пишет, что значит желтый бочонок. Зеленая точка обозначает текущий узел, гм.

Пришлось вооружиться консолью кода и проверить:

Получается, что в этой базе главным узлом является Магазин, т.е. по сути при создании РИБ были перепутаны узлы местами.

Я объяснил ситуацию программисту, спросил, он сам починит или поручит мне. Он поручил мне.

Я подключился к периферийной базе магазина.

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

Обмены делал в главной базе и на магазине:

Выполнил обмены несколько раз, пока они не стали пролетать мгновенно.

Кстати, обмен проходит через Яндекс-диск, взял себе такой способ на заметку, как самый простой:

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

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

Использую обработку «Реанимация подчиненного узла», допиленную мною:

Но тут меня ждал сюрприз:

Невероятно, но в двух базах стоит главный узел. Т.е. обмен по сути идет между двуглавой РИБ-базой. И это как-то работает. Видимо, конфигурация не меняется.

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

После этого картинка плана обмена в главной базе стала другой:

После этого захотел сделать обмены. Тут пользователи периферийного узла начали мне мешать и закрывать смену (18:52 как никак, суббота):

Благо это заняло всего пару минут. И я продолжил обмены.

Как ни странно, обмен на периферийной базе прошел нормально:

В центре тоже успешно:

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

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

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

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

Но похоже, моя обработка слегка устарела, т.к. у метода ПриОтправкеДанныхПодчиненному появился один новый параметр. Кроме того обработка ожидала, что все методы реализованы со словом Экспорт. Я поправил код:

//Отправка данных подчиненному
ОтправкаЭлемента=Неопределено;
ПериферийныйУзелОбъект.ПриОтправкеДанныхПодчиненному(Объект, ОтправкаЭлемента, ложь);
Стр[«ОтправкаПодчиненному»+Суффикс]=КонстантаОбменаВСтроку(ОтправкаЭлемента);


//Получение данных от главного
ОтправкаЭлемента=Неопределено;
ОтправкаНазад=Неопределено;
Попытка
ПериферийныйУзелОбъект.ПриПолученииДанныхОтГлавного(Объект, ОтправкаЭлемента, ОтправкаНазад);
Стр[«ПолучениеПодчиненным»+Суффикс]=КонстантаОбменаВСтроку(ОтправкаЭлемента);
Стр[«ПолучениеПодчиненнымНазад»+Суффикс]=ОтправкаНазад;
Исключение
КонецПопытки;

//Отправка данных главному
Попытка
ОтправкаЭлемента=Неопределено;
ПериферийныйУзелОбъект.ПриОтправкеДанныхГлавному(Объект, ОтправкаЭлемента);
Стр[«ОтправкаГлавному»+Суффикс]=КонстантаОбменаВСтроку(ОтправкаЭлемента);
Исключение
КонецПопытки;

//Получение данных от филиала
Попытка
ОтправкаЭлемента=Неопределено;
ОтправкаНазад=Неопределено;
ПериферийныйУзелОбъект.ПриПолученииДанныхОтПодчиненного(Объект, ОтправкаЭлемента, ОтправкаНазад);
Стр[«ПолучениеГлавным»+Суффикс]=КонстантаОбменаВСтроку(ОтправкаЭлемента);
Стр[«ПолучениеГлавнымНазад»+Суффикс]=ОтправкаНазад;
Исключение
КонецПопытки;

В итоге обработка выдала такую картинку:

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

На всякий случай проверил свой код в отладчике:

Вроде бы работает, ок.

Далее, выгружаю конфигурацию на периферию:

Ну, соответственно, принимаю на точке:

Ожидаемо сообщение об ошибке загрузки без обновления конфигурации.

На точке УТ 10.3 почему то при входе пользователя не делает авто-обновление конфигурации, делаю через конфигуратор, нажимая бочонок:

Ну, после обновления конфигурации загрузка и выгрузка прошли. Принял ответ от периферии в центре (выполнил в центре успешный обмен) и всё ОК.

Работа была оплачена по факту: 1 час и 15 минут.
Статью писал параллельно работе.

fixin

Программирую на 1С с 1999 года. В 1С просто Гений. В 2020 году ушел из офиса на вольные хлеба фриланса. Принимаю заказы.

Читайте также:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *