Ошибка при обмене сообщениями в риб

РИБ ошибка при обмене

Я
   filterhouse

28.02.13 — 14:56

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

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

Конфа БП+БИТФинанс.

   hhhh

1 — 28.02.13 — 15:00

F7 нажимал в конфигураторе?

   filterhouse

2 — 28.02.13 — 15:02

Да, нажимал. В подчиненной все обновилось.

   Kreont

3 — 28.02.13 — 15:03

еще раз попробуй, может файл старый, или кто без тебя ЦБ правит втихую :)

   filterhouse

4 — 28.02.13 — 15:05

Повторно тоже попробовал, та же беда.

   lxndr

5 — 28.02.13 — 15:07

версии платформ центра и периферии совпадают?

   Serg_1960

6 — 28.02.13 — 15:08

(подсказака) Может быть ты снял  «признак» подчиненного узла и забыл его восстановить?

   Kreont

7 — 28.02.13 — 15:08

Еще раз по пунктам, так делаешь:

1. Изменили ЦБ, получили файл ЦБ_РИБ

2. Обмен на РИБ файлом из п.1.

3. Применение изменений конфигурации.

4. !!! Самое главное, аналогично п.2:  Обмен на РИБ файлом из п.1.

5. А вот только теперь файл РИБ_ЦБ обратно в центр передаем

   lxndr

8 — 28.02.13 — 15:11

(7) даже если пропустить п. 4 ошибки «Изменения конфигурации не могут быть получены из подчиненного узла распределенной ИБ» быть не должно..

   Kreont

9 — 28.02.13 — 15:13

(8) да нет, п.4. как раз самый главный,

хотя есть еще вариант что кто-то РИБ конфиг правил

   filterhouse

10 — 28.02.13 — 15:16

(7) Делал без п.4. Сейчас буду пробовать. (9) РИБ конфиг никто не правил.

   filterhouse

11 — 28.02.13 — 15:17

(5) Версии совпадаю. И сравнением конфигураций различий не нашел.

   del123

12 — 28.02.13 — 15:25

(9) Если бы не был выполнен пункт 3 или 4, то ошибка была бы такая  «Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла, для которого зарегистрированы изменения конфигурации.»

А такую ошибку как у ТС что то в первый раз вижу..

   filterhouse

13 — 28.02.13 — 15:31

(12) Два раза все переделывал. Что можно еще попробовать сделать?

   del123

14 — 28.02.13 — 15:35

ну хз, попробуй изменить главную еще раз и еще раз обновить дочернюю)

   Serg_1960

15 — 28.02.13 — 15:45

Файл сообщения обмена из подчиненного узла посмотри «напрямую».

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

Если нет там никакого изменения конфигурации — то посмотри внимательно на «идентификаторы» конфигурациий в заголовке.

PS: «Демоническое рассогласование конфигураций». Сам придумал термин для демонического обновленияи. И, увы, уже давно.

   ilkoder

16 — 28.02.13 — 15:53

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

   Kreont

17 — 28.02.13 — 16:44

(12) а ну да, согласен, невнимательно текст ошибки почитал.

хотя п.4 все равно обязателен )

   cons74

18 — 28.02.13 — 19:39

вот прям щас такая же беда случилась. По удаленке настраивал РИБ. Обмен через каталог. А в качестве такого — Dropbox.

Обновил головную, выгрузил файл на 27мб, загрузил в периферийную, нажал F7. И запустил повторно обмен в периферийной. И она выгрузила вместо 1кб «все ок» — файл 27мб «изменения конфы».

Основная конечно такой файл не съела и выдала вышеописанную ошибку. После чего основная выдала снова файл 27мб. Я его снова скормил периферийной- и о чудо! Она ответила 1кб «ок», в конфигураторе F7 не просит.

В общем мысль такая: если после обновления периферийной ей не дали снова «тот самый первый файл» 27мб — она гонит и выгружает «изменения в конфе» обратно.

   cons74

19 — 28.02.13 — 19:41

доп. пояснение: настраивал авт. обмен — запуск при появлении файла обмена. При этом после чтения оного 1с:Бухгалтерия удаляет его. Чего не случается при ручном обмене.

   filterhouse

20 — 01.03.13 — 06:30

(16) Победил =) Снял признак подчиненной, загрузил cf-ник, и обмен прошел.

Всем спасибо за советы.

   Serg_1960

21 — 01.03.13 — 08:48

filterhouse, я рад за вас :)

PS: хотелось бы один момент уточнить. После обновления конфигурации подчиненного узла вызывали сеанс «1С:Предприятия» для запуска обработок обновления или минуя это делали обмен данными?

  

filterhouse

22 — 01.03.13 — 16:28

(21) Не совсем понял что вы имели ввиду: «вызывали сеанс «1С:Предприятия» для запуска обработок обновления», может уже под конец пятницы голова не соображает.

Снял признак подчиненной, загрузил cf-ник, в Предприятии обработкой вернул на место признак подчиненной, и произвел обмен.

Наверное я не ответил на ваш вопрос =)

Здравствуйте, уважаемые читатели нашего блога SoftMaker.kz! Сегодня поговорим об исправлении двух ошибок, которые могут возникнуть при обмене в распределенной информационной базе (РИБ). Такие ошибки могут возникнуть, если вы изменили конфигурацию вашей базы и пытаетесь передать эти изменения из центральной базы в периферийную. Например, способом, который был описан здесь. Давайте приступим!

Вот такие сообщения могут появиться при попытки сделать обмен при помощи РИБ:

«Данные принимаются от узла, для которого зарегистрированы изменения конфигурации. Необходимо произвести перенос изменений конфигурации в узел.»

«Конфигурация узла распределенной ИБ не соответствует ожидаемой!»

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

    1. Возьмем файл конфигурации с обновлением, откроем центральную базу в Конфигураторе и загрузим его (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
    2. Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
    3. Зайдем в режим 1С:Предприятие и сделаем выгрузку в файл для периферийной базы:
      • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
      • Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выбрем пункт «Записать изменения…».
      • В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
    4. Теперь займемся периферийной ИБ. Откроем ее в монопольном режиме, чтобы никого из пользователей не было, а также закроем Конфигуратор. Теперь необходимо запомнить узел, который является главным для текущей базы. Откроем Операции-Планы обмена-Выбрать ваш план обмена (например, «По складу»). В списке планов обмена главным узлом является элемент с желтой пиктограммой. Эта информация пригодится нам в седьмом пункте. Откроем обработку УстановкаГлавногоУзлаБД.epf и нажмем кнопку «Отменить назначение главного узла».
    5. Теперь откроем периферийную ИБ в Конфигураторе и загрузим тот же файл конфигурации, который мы загружали на первом шаге в центральной базе (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
    6. Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
    7. Теперь опять откроем периферийную ИБ в монопольном режиме 1С:Предприятие, чтобы никого из пользователей не было, а также закроем Конфигуратор. Откроем обработку УстановкаГлавногоУзлаБД.epf и выберем план обмена, который мы хотим установить главным узлом (в четвертом пункте мы запоминали этот узел). Затем нажмем кнопку «Установить главный узел». После этого текущая ИБ снова станет периферийной.
    8. Теперь в текущей ИБ (периферийной) откроем планы обмена и загрузим файл с обменом из Центральной базы, который мы получили на третьем шаге:
      • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
      • Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
      • В диалоге выберем файл обмена. Нажмем кнопку «ОК».
    9. Если все прошло успешно, то сделаем выгрузку обмена для Центральной базы в текущей ИБ (периферийной):
      • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
      • Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выберем пункт «Записать изменения…».
      • В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
    10. Теперь попробуем загрузить этот файл в Центральной базе, откроем ее в режиме 1С:Предприятие:
      • Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
      • Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
      • В диалоге выберем файл обмена. Нажмем кнопку «ОК».

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

ПОДПИСКА

Конфигурация узла распределенной ИБ не соответствует ожидаемой. Одна из самых популярных ошибок РИБ. Приведены стандартная методика устранения (уже публиковалась ранее) и расширенная (для сложных случаев).

Для начала привожу список используемых мной сокращений:

  • РИБ — распределенная информационная база
  • ЦБ — центральная база, корневой узел РИБ
  • УБ — удаленная база, БД удаленного узла РИБ

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

  1. во время приёма файла сообщения в УБ «упала» база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
  2. под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций

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

Для исправления использую 2 методики, в зависимости от ситуации.

ПЕРВАЯ МЕТОДИКА

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

Последовательность действий:

  1. выгружаем из ЦБ cf-файл;
  2. отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
  3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню «Загрузить конфигурацию из файла» (а не сравнением-объединением!!!);
  4. восстанавливем признак РИБ для УБ.

В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда…

ВТОРАЯ МЕТОДИКА

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

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

Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги «Профессиональная разработка в системе 1С:Предприятие 8» дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.

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

Итак, последовательность действий: 

  1. выполняем действия 1 — 4 первой методики;
  2. выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
  3. выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
  4. в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
  5. производим загрузку файла из 4-го пункта в УБ;
  6. обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
  7. для проверки делаем несколько последовательных обменов.

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

Блок файла обмена из ЦБ

            <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
               <v8de:Version>106.0</v8de:Version>
               ...здесь идут блоки описания изменений конфигурации...
               <v8de:Digest1>1cf680807e97a5dc0d1ed7f901b07392</v8de:Digest1>
               <v8de:Digest2>038211651cf680807e97a5dc0d1ed7f9</v8de:Digest2>
           </v8de:Config>

нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен «00000000000000000000000000000000»!!!)

            <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>106.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2>11651cf680807e97a5dc0d1ed7f901b0</v8de:Digest2>
</v8de:Config>

Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!

В остальном могу только пожелать удачи!

Обработка ошибок, возникающих при обмене данными в распределенной информационной базе

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

Когда у меня возникает ошибка при обмене данных я сперва  обращаюсь к  статье  http://its.1c.ru/db/metod8dev#content:2265:hdoc    в поисках пути решения. В этой статье  рассматриваются  те ошибки, которые так или иначе имеют отношение к обмену данными в рамках  распределенной информационной базы .  В  статье  показан список сообщений об ошибке и  возможные пути исправления ошибки.  Если возможные пути решения  возникшей  ошибки в этой статье недостаточны, то я рекомендую искать в форумах по описанию сообщения об ошибке. Например,  одна из самых распространенных ошибок при РИБ –  Конфигурация узла распределенной ИБ не соответствует ожидаемой!.   Возможные пути решения к этой ошибки также описаны в статье  http://infostart.ru/public/65456/

Понравилась статья? Поделить с друзьями:
  • Ошибка при обмене со службой лицензирования localhost 756 атол
  • Ошибка при обмене со службой лицензирования localhost 756 frontol
  • Ошибка при обмене с сайтом на битрикс
  • Ошибка при обмене с пфр сзв тд
  • Ошибка при обмене с ключом