Есть БД-1, в ней открыт документ. В БД-2 есть копия этого документа, как только пришло событие(уведомление)агент записывает в поле history в документе - "письмо дошло". Задача обновить это поле history в Открытом документе в БД-1. Как правильнее это реализовать?

 

закрыть документ и открыть после изменений

 

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

 

@maliy на клиенте? Я знаю только вариант про JS-таймер, который жмет кнопку на форме.
А в форме уже код, который делает "что-то"... Даже не знаю как это к данной задаче можно прикрутить...
Тут же дело не только в сканировании/отображении, но и "Как понять, что уведомление именно к этому документу?"
Если это обычное письмо, да еще и из интернета...

 

корреспондент

P.S. Суть

здесь правильный вопрос - когда корреспондент ответит?
и что делать если документ уже закрыли?
если время измер. секундами - не вопрос - запускаем агент, создаём очередь на сервере, агент в неё пишет результат, клиент мониторит очередь

 

Если это обычное письмо, да еще и из интернета...

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

 

@savl можно на after arrive (в мэйл боксе) зашить код, вопрос в надежности почтовых отправлений впринципе
можно листнер (при открытии формы поднять) на к-л порту (через java)

 

нет, не почта кидает сообщения. у меня появилось сообщение в текстовом файле, агент в БД-2 в документ в history -записал это сообщение из текстового файла в документ в БД-2. Далее нужно синхронизировать history из документа БД-2 в документ БД-1. Если документ в БД-1 закрыт, то синхронизировали поле и все. а вот если открыт?

можно листнер (при открытии формы поднять) на к-л порту (через java)

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

 

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

http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html как-то так
НО через LS2J может обломаться - там с мультипоточностью м.б. засады (запуск второго такого дока проблематичен)
с др. стороны решение с JS может опрашивать очередь, а агент пишет в очередь
но реализацию проверки сообщений в очереди я не видел (на СиАПИ)
опять же - никто не мешает создать очередь в java - надо курить сингелтон и размещение в jvm/lib/ext

 

еще варианты - смотреть в сторону composite application или xpages

 

"а вот если открыт?"(с)
напр по JS timer жать на кнопу каждые 5 сек напр,
в кнопе - чтение чо нужно из копии дока в БД-2\сравнение с тем же полем открытого дока\если не равно - переоткрыть, а луче выдать мессагу и тут же прописать в UI, если он эдит канеш
ну и конфликты разрулить )
если ток чтение - мессага и переоткрыть

ЗЫ
ващщета авторелоад в UI должно работать

 

апр по JS timer жать на кнопу каждые 5 сек напр,

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

 

@lmike "малевич не придет?"(с)
с 5 сек и одной кнопкой не придёт )))
пяток доков тож потянет
можно "монитором ресурсов" протестить в винде как nlnotes.exe память ест: если минут за 5 цифры не увеличиваются - норм

 

@lmike "малевич не придет?"(с)
с 5 сек и одной кнопкой не придёт )))
пяток доков тож потянет
можно "монитором ресурсов" протестить в винде как nlnotes.exe память ест: если минут за 5 цифры не увеличиваются - норм

@lmike, за авторством @alexas1 : Про утечки JS и как избежать

 

@savl я помню - @alexas1 выкладывал для классики наработки... , еще с лайвсерч

 

@maliy, вот всё, что уважаемые участники вам понасоветовали - это жесть.
Осмелюсь предложить более приземленный вариант.
1. Принимаем как данность, что любая запись History - это отдельный документ в БД№3 "History Log" (БД ХЛ). Эта запись содежит помимо смысловых полей (Дата\Время, Subject, Кто выполнил и т.п.) еще и уникальное для вашего документа значение-код. Это может быть как его UNID, результат @Unique или любое удобное вам значение.
2. В БД ХЛ как минимум одно из view должно быть категоризированно по "значение-код" и оформлено в соответствии с вашими пристрастиями.
3. В БД №1 и №2 в форме вашего документа вместо поля добавляем встроенный взгляд из БД ХЛ (например на отдельную вкладку таблици) с формулой в show single category.
4. ... Дайте пользователю кнопку обновить этот встроенный взгляд или попробуйте управлять авторефрешем по своему усмотрению

Польза:
- Одна запись истории сразу будет доступна из всех мест существования вашего документа (неожиданно появятся еще 100 БД с ним)
- Меньше конфликтов репликации при одновременном редактировании.
- Обходим ограничение на текстовое поле (если оно у вас текст)
- Выравнивание строк взгляда + вообще произвольный набор данных для лог-записи.
- Управление доступом к истории на уровне Readers\Authors полей и ACL БД ХЛ (что бы запретить рукотворчество)
- А может быть и статистику\аналитику собирать станет намного проще.

Как то так.

 

@Domino-Designer, Внедренная View - это конечно хорошо. Но внедренные вью очень тормозят открытие карточек(лотус-документов), в особенности если стоит авторефреш у этих внедренных View. А если таких внедренных View на форме несколько, да и еще авторефреш у них - то это полная жесть(тормоза). Поэтому не очень хочется использование внедренных View.
На данный момент пробую приладить JS-таймер. Дальше посмотрим что из этого выйдет.

 

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

 

На уровне идеи.
Если задача стоит уведомить пользователя онлайн, что что то пришло, наверное запускать нотес таймер и мониторить пришедшее (сам пока не пробовал)
Если задача стоит разрулить возможные конфликты - то идея в том, что мониторить изменение полей в открытом документе и сохранять только те поля, которые изменились. Таким образом условно можно разделить поля в документе на серверные/агентские и на пользовательские. Поставить признак merge/no conflicts. И если надо, добавить проверку на то что другой юзер успел поредактировать (на днях планирую такую задачу реализовать)

 

Задача стоит уведомить пользователя онлайн.