Привет!

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

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

Проблема только в том, что после репликации сервер держит базу и стандартным скриптом ее не скопировать, получается скопировать батником, а затем заархивировать и послать.
И при этом нету полной уверенности, что в реплике, которую держит сервер, закончились все процессы и база будет правильная при копировании батником.
А если будет включен транзакшн логгинг, среплицируются туда сразу документы или с какой то задержкой?
сервер 5.5, консольные команды недоступны из скрипта, а если в батнике прописать путь\nserver -c "dbcache flush", то не срабатывает адекватно (идет задержка и в консоль перестают выдаваться другие данные).

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



Заранее благодарю.

 

а не легче ли просто кросссертифицировать сервера и включить репликацию?

 

есть еще момент - дать права доступа к папке домино сервера и потом просто тупо переписывать бд

 

Ну если уж все так... эм.. не просто... Может имеет смысл перегонять документы или всю базу в xml?
Смотря что удобнее

 

или вообще проще поставить сервер поновее... хотя бы 7-8

 

а не легче ли просто кросссертифицировать сервера и включить репликацию?

Связь только по электронной почте. Обычная репликация невозможна.

 

Gandliar
XML только с 6-ки...
Если только самому в TXT писать все что изменено/удалено/создано и отправлять...
Придумать свою схему файла:
НачалоФайла
UNID, имя поля=значение, имя поля=значение
UNID2, имя поля=значение, имя поля=значение
UNID3, имя поля=значение, имя поля=значение
...
КонецФайла
Но хз...

А если продолжать ваш вариант - > надо точно подгадать время.

 

Gandliar
XML только с 6-ки...
Если только самому в TXT писать все что изменено/удалено/создано и отправлять...
Придумать свою схему файла:
НачалоФайла
UNID, имя поля=значение, имя поля=значение
UNID2, имя поля=значение, имя поля=значение
UNID3, имя поля=значение, имя поля=значение
...
КонецФайла
Но хз...

А если продолжать ваш вариант - > надо точно подгадать время.

так тоже не пойдет. Тут нарисуется проблема с RT-полями.
Так что, автор, поднимай версию сервера, а потом уж код точи!

 

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

 

млин... да здесь реально проблематика в серваке.... остальное - дело перепрогивания скриптов... +и так лотус юзает РОР3 и т.п. порты, смотри настройки сервака по настройке мыльников

 

Связь только по электронной почте.

Следовательно, провода есть...

Обычная репликация невозможна.

И что же мешает, раз провода уже есть?

 

если репликация невозможна из-за идиотизма ИТ/секурити служб - есть способ создать канал, на любой порт удаленного/промежуточного сервера, нужно продумать архитектуру
НО, лучший метод - накапать начальству и заставить открыть порты административным способом

 

Связь только по электронной почте. Обычная репликация невозможна.

ну да, а почта у вас в конвертах приходит

 

если репликация невозможна из-за идиотизма ИТ/секурити служб - есть способ создать канал, на любой порт удаленного/промежуточного сервера, нужно продумать архитектуру
НО, лучший метод - накапать начальству и заставить открыть порты административным способом

Это так и есть. И такой путь в процессе решения.
Просто мотивы у секурити таковы, что им надо хранить пересылаемые данные.

Добавлено:

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

Примерно так и сделано сейчас. Проблема в том. что лотус держит базу после репликации. Был бы метод db.Close было бы прекрасно.

 

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

 

Добавлено:

ну да, а почта у вас в конвертах приходит

Ну судя по всему - у них по SMTP почта ходит.

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

Обычная проблема - закрыты порты UDP. Нормальная практика.
Все зависит от политики безопасности компании.
Это еще нормально. В некоторых компаниях еще и к IP адресам пользователей привязываются

 

Примерно так и сделано сейчас. Проблема в том. что лотус держит базу после репликации. Был бы метод db.Close было бы прекрасно.

М.б.:
result = s.SendConsoleCommand(s.CurrentDatabase.Server,"dbcache flush")
result = s.SendConsoleCommand(s.CurrentDatabase.Server,"dbcache show")

 

Обычная проблема - закрыты порты UDP. Нормальная практика.
Все зависит от политики безопасности компании.
Это еще нормально. В некоторых компаниях еще и к IP адресам пользователей привязываются

типа это никак нельзя решить?
TCPIP открыт?
назначить лотусу любой другой порт
да можно даже через роутеры пробросить NRPC через 25й порт

 

типа это никак нельзя решить?
TCPIP открыт?
назначить лотусу любой другой порт
да можно даже через роутеры пробросить NRPC через 25й порт

Интересно.. 25 порт для обмена почты и 25 для репликации. Сомневаюсь что это будет работать

 

как я уже сказал - ничего невозможного нет
если сервер подконтролен - можно запускать java ssh-server
ну а там - никаких проблем сдалать проброс портов...
на удаленном серванте:
тушим консольно смтп лиснер, биндимся к 25-ому порту, реплицируемся, отключаем ssh, включаем лиснер

с "клиентской" стороны ssh -4 user@server -p 25 -L1353:localhost:1352
теперь удаленным сервером будет localhost:1353
а данные (шифрованные) потекут через 25 порт
ну и не забыть 127.0.0.1 прописать алиасом на имя удаленного серванта (либо создать специфичный док-коннекшн)
в случае если с промежуточным клиентом - не будет надобности подменять порт на 1353 (ибо его локально не будет слушать сервер)