Всем доброго времени суток! Было: Сервер MS SQL + сервер 1С + PostgreSQL + Сервер взаимодействий Конфигурация УНФ подключена к локальным взаимодействиям Нужно: перенести все это добро на новый сервер На новом сервере установили весь софт из дистрибутивов. На MS SQL и PostgreSQL развернули бекапы баз (база 1С и база 1cs-ce) Первый вход в базу - платформа сообщает, что не может подключиться к северу взаимодействий (думаю, ключевой проблемой является изменение подсети - адрес нового сервера другой... кроме того, никто не помнит, какой адрес использовали при регистрации на сервере взамиодействий - имя/айпи/...) Провели регистрацию заново. В результате, все обсуждения и чаты - пропали Вопросы: 1. Есть ли возможность узнать, на какой адрес пытается подключиться платформа к серверу взаимодействий? 2. Как правильно перенести историю обсуждений на новый сервер? Спасибо!

Сервер взаимодействий. Перенос на новый сервер

4. mike.kondr 17.02.20 16:44 Сейчас в теме

(2) да, тоже обратил внимание на таблицу public.application

К сожалению, повторная регистрация с тем же пользователем и именем базы - создает ещё одну запись (с новыми application_id, subscriber_id и т.д.)

Экспериментальным путём удалось:

1. Отменяем регистрацию перенесенной базы
2. Регистрируем повторно (введенные данные могут не совпадать с исходными - это не важно)
3. Закрываем 1С, останавливаем сервер взаимодействий

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

4. Во всех таблицах баз public.* и vb_subscriber_*.* выполнить замену в столбцах application_id, subscriber_id на значения новой регистрации
5. Старую запись регистрации в таблице public.application удалить
6. Запустить сервер взаимодействий и 1С

Эта последовательность действий привела к требуемому результату.

2. davealone 165 17.02.20 16:27 Сейчас в теме

(1) Кто регистрировал можно посмотреть в базе 1cs-ce таблицу public.subscriber
Но более интересна таблица public.application и колонка tilte.
На сколько я помню, регистрация базы с тем же именем, должна дать доступ к сообщениям.

4. mike.kondr 17.02.20 16:44 Сейчас в теме

(2) да, тоже обратил внимание на таблицу public.application

К сожалению, повторная регистрация с тем же пользователем и именем базы - создает ещё одну запись (с новыми application_id, subscriber_id и т.д.)

Экспериментальным путём удалось:

1. Отменяем регистрацию перенесенной базы
2. Регистрируем повторно (введенные данные могут не совпадать с исходными - это не важно)
3. Закрываем 1С, останавливаем сервер взаимодействий

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

4. Во всех таблицах баз public.* и vb_subscriber_*.* выполнить замену в столбцах application_id, subscriber_id на значения новой регистрации
5. Старую запись регистрации в таблице public.application удалить
6. Запустить сервер взаимодействий и 1С

Эта последовательность действий привела к требуемому результату.

7. davealone 165 17.02.20 16:53 Сейчас в теме

(4)

К сожалению, повторная регистрация с тем же пользователем и именем базы - создает ещё одну запись (с новыми application_id, subscriber_id и т.д.)

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

Адрес куда стучатся кажись хранится в базе 1с в таблице Params. Там запись с колонкой FileName по шаблону ecsreg_
Вот в BinaryData этой записи помимо прочего и адрес ws, куда регистрировали базу

8. mike.kondr 17.02.20 16:58 Сейчас в теме

(7) спасибо! проверю такой сценарий на тестовой базе (отключиться перед переносом и подключить после переноса)

(7)

в BinaryData этой записи помимо прочего и адрес ws

а как вытащить из двоичных эти сведения?

9. davealone 165 17.02.20 17:22 Сейчас в теме

(8) я просто CAST([BinaryData] AS VARCHAR(MAX)) сделал
А вот перед ws похоже ID из client_id таблицы public.application
Видимо это и есть параметры регистрации базы.

10. davealone 165 17.02.20 17:25 Сейчас в теме

(8) Вот что пишут по восстановлению:

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

11. mike.kondr 17.02.20 18:04 Сейчас в теме

(10)

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

Судя по всему, именно в этом у меня и возникла проблема - новая регистрация базы создалась с новым УИДом

Хотя, когда внутри одного сервера (без переноса) регистрируем-отменяем-регистрируем - УИД базы сохраняется и история сообщений действительно восстанавливается

14. assa 61 04.06.24 09:31 Сейчас в теме

(4)Приветствую. У вас получилось продолжить использование СВ после этого? Я смог все перенести. Но осталось одно НО. Пользователи перестали видеть друг друга. Можно общаться в документе. Например, пользователь создает документ, появляется запись: "Юзер 4" создал документ. Юзер1 заходит в документ и может написать только Юзеру4. Ни Юзера2, ни Юзера 3 в обсуждение добавить невозможно. В личных чатах тоже самое. Можно общаться только с теми, с кем общался ранее. Но везде можно добавить в обсуждение того юзера, который зарегистрировал базу. Вот такой перенос получился.

3. davealone 165 17.02.20 16:43 Сейчас в теме

(1) А вот на какой адрес можно у менеджера системы взаимодействия вызвать ПолучитьДанныеРегистрацииИнформационнойБазы

5. mike.kondr 17.02.20 16:45 Сейчас в теме

(3) метод возвращает такой тип данных, который можно только сериализовать в XML (получим двоичные данные на выходе в base64)...
ни свойств, ни методов у этого типа данных нет

6. mike.kondr 17.02.20 16:47 Сейчас в теме

(3) судя по всему, возвращаемое методом значение можно использовать только для цели "резервного копирования" данных регистрации - т.е. получить-запомнить с целью последующего восстановления методом УстановитьДанныеРегистрацииИнформационнойБазы

12. misha-school 29 20.04.21 16:31 Сейчас в теме

Кто подскажет как перенести данные с 1СDialog на свой сервер взаимодействия?

13. Zero_nv 128 13.05.21 07:22 Сейчас в теме

Присоединяюсь к вопросу: как перенести данные с 1СDialog на свой сервер взаимодействия?