Пока нашел только один способ - ПланыОбмена.ЗаписатьСообщение() и парсить XML. Но это достаточно затратно. Есть ли другие способы без прямого доступа к БД?

Есть такая таблица в структуре БД с именем ConfigChngR. Доступа к ней в языке запросов не сделали по понятным причинам, но в моем случае он получается требуется.

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

Как вариант. Сделай регистр сведений с планами обмена и версиями изменений. При обновлении конфы закидывай новый релиз. Отправляй в периферию. Они после загрузки записывают новую версию и отпраляют обратно. Таким образом будешь знать, где и какая версия

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

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

(4) Непонятно, как ты это собираешься узнавать в "общем" случае. Есть только два источника инфы - центральный узел и сообщения обмена.

как вариант - поднять в центре вебсервис, который будет текущий номер версии отдавать. Тогда ПБ будет точно знать, есть изменения или нет. В центре все и так понятно на основании дат принятых-отправленных

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

Для решения задачи изменения конфигурации не допускаются.

(9) ты с (5) согласен?

(9) Точнее доработки =)

(10) Твое утверждение не понял. Поэтому не могу ответить определенно.

Для платформы решение предложил следующее (для ее развития).

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

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

блин, так тебе где узнавать-то надо? В центре или в периферии?

КонфигурацияИзменена?

Узел РИБ - узел плана обмена с включенным флажком "Распределенная информационная база". Для подчиненных баз изменения конфигурации не хранятся естественно для этих узлов. Поэтому ответ на (0) в периферии лишен смысла.

(16) Мимо. Нужен ответ в отношении каждого узла плана обмена отдельно.

(17) то есть, тебе надо, сидя в центре, узнать, какой из филиалов негодяй и не загрузил своевременно обновку, так?

(19) Ну немного сужая задачу, да.

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

(20) Без кодинга и пива - никак

(22) думаю, автору без кодинга бы и не подошло

(21) В плане обмена нет никаких дат, только стандартные реквизиты.

(24) во всех типовых есть регистр ИсторияОбмена или как-то так.
Добавь, будь мужиком. Иначе получается, что ты хочешь получать информацию, которую не хранишь.
Если добавить в эту конфу прямо совсем не вариант, отрасти рядом свою, которая будет уметь и знать только, как обменники туда-сюда принимать-отдавать и пусть она запоминает эти даты.