Как узнать, есть ли изменения конфигурации для узла плана обмена РИБ. #612621

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

Изменения

Что Вы хотели этим сказать?

ВЫБРАТЬ ИЗ    Справочник.Банки.Изменения КАК БанкиИзменения

у каждого объекта есть таблица изменений

а какой объект и таблица изменений у конфы?

Это изменения данных, а мне нужно конфигурации.

написано для

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

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

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

хочу видеть, кто из периферии уже принял изменения конфигурации

я седелал по дате загрузкиесли она отличается от даты выгрузки на 1 час то считать узел не обновленным, но это не точный метод, есть у кого мысли?

по размеру файла обмена можешь. Файл с конфигурацией в 100 раз больше, чем обычный файлик обмена.

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

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

Метода вроде такого нет. Как костыль - запоминать номера принятых сообщений на момент обновления конфигурации, а затем сравнивать

Я логи парсил, но это было на семерке...

Парсить логи самое верное. Но в семерке я через ADO несколько мильенов символов назад отступал ибо сам лог более 100 мегов и парсинг даже 5 мегов занимает секунд 50... А если делать каждые 3 минуты и публиковать куда-то на корп. сайт, то чеще 1 раз в 3 минуты не получается...

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

ЩИТО? Запоминаем номера принятых сообщений для всех узлов где-нить в реквизите или в РС. Обновляем конфу БД. Те узлы, где номер принятого сообщения равен запомненному - ещё не отчитались об обновлении конфы, где номер принятого сообщения больше того, что запомнили - уже обновились. Так понятней?

Да понятно. Всё равно не раскрывает суть процесса. Только логи дадут кошерный результат.

+ Всю историю не запомнишь, а надо знать динамику, а не "верхушку". Данные в реквизите будут перетираться, тогда регистр придется мутить. А это - те же логи.

Можно подумать, что парсить логи быстрее, чем сравить 2 числа

Ты не понимаешь назначения такого отчета. Это от отсутствия опыта.

У меня сисадмина чуть не сожрали в срачах за обмены ибо все утверждали, что "прислали уже давно".... Спасет только история.

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

Логи парсятся автоматом и ПУБЛИКУЕТСЯ отчет в инете на закрытой части корп. сайта. Дальше бухи ипрочие могут какаться между собой не втягивая нас.

Срачи "мы всё загружаем и выгружаем" - это другое дело, тут без истории никуда, согласен

30 филиалов выгрузок с полной конфигурацией = 1 час формирования отчета. А тут каждые 3 минуты обновлять можно. парсинг - 1 минута.

Больше он никому не нужен.

+

Почему сисадмина?

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

Обмены надо автоматизировать. Исключать человеческий фактор, так сказать.

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

<Фильтр выборки> (необязательный) Тип: Неопределено, Объект метаданных, СсылкаНаОбъект, НаборЗаписей, Массив. Неопределено - фильтр пуст, выбираются все изменения по узлу; Объект метаданных - выбираются изменения в основной таблице, связанной с данным объектом метаданных; СсылкаНаОбъект - фактически, может быть выбрана только одна запись об изменении данного объекта, либо ни одной, если объект не менялся; НаборЗаписей - набор записей регистра, может быть не выбран, для фильтрации изменений используется лишь отбор набора записей; Массив - все элементы массива имеют один из перечисленных выше типов, кроме Неопределено. Условия фильтрации соединяются по ИЛИ. Значение по умолчанию: Неопределено Как тут можно отловить, что конфигурация изменялась?

Объект метаданных - выбираются изменения в основной таблице, связанной с данным объектом метаданных;

или незнаешь что такое объект метаданных

Вот именно, дашь в фильтре объект метаданных Метаданные.Документы.<Имя документа>, получишь все изменения этого объекта ДокументОбъект.<Имя документа>. Как узнаешь, что изменился код в модуле формы этого документа?

Сам пробовал использовать? Есть пример рабочего кода? Что передаёшь 3-м параметром? Если передавать просто Метаданные, то выборка пустая, даже если изменения конфигурации есть

В любой конфигурации есть константа или регистр, где хранится текущая версия. Для типовых на БСП это например РС "ВерсииПодсистем". Запись данных в эту константу или регистр происходит при первом открытии после обновления, и регистрируется для отправки дочкам. Собственно можно просто проверять, есть ли для узла зарегистрирвоанные изменения константы или РС, в котором в твоей конфе хранится номер версии. Если есть - значит узел еще не принял изменения конфы.

ты прав

Что-то ТС пропал.

Это только если конфигурация на поддержке, как я понимаю..

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

Если можешь "подправиль" выгрузки изагрузки, то идея хорошая. но лучше мутить РегистрСведений с таким же смыслом, а не константы.

46) Если можешь "подправить" выгрузки и загрузки, то идея хорошая. но лучше мутить РегистрСведений с таким же смыслом, а не константы.

Как определить версию (номер версии) конфигурации? Чтоб понять, есть ли изменения конфигурации для узла.

Если серверная версия, то можно обратится напрямую к sql серверу запросом, который получит ИД узлов, для которых зарегистрированы изменения. Далее по ПланОбменаСсылка.УникальныйИдентификатор определяем узлы.

Это пишется в запросе? Если 1С русская, поймет она команды на Инглише?

Запрос необходимо писать на языке SQL, а не 1С. Пример обращения к sql серверу из 1С

Этот метод мне ещё больше понравился, спасибо. А НЕ серверную версию, лично я вообще не понимаю, из-за реализации регламентных заданий. Не представляю как можно гарантировать непрерывный обмен с 30 филиалами на файл серверном варианте, где для работы регламентных заданий требует отдельный клиентский процесс. Это же нужно за ним постоянно следить. А вдруг чего, так всегда виноват программист.

Зарплата в три тарелки супа дает возможность программисту 1С жить на работе. Если он любит свою работу.