Есть БД-1, в ней открыт документ. В БД-2 есть копия этого документа, как только пришло событие(уведомление)агент записывает в поле history в документе - "письмо дошло". Задача обновить это поле history в Открытом документе в БД-1. Как правильнее это реализовать?
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Проблема Ui-документ, записать данные
- Автор темы maliy
- Дата начала
-
- Теги
- lotus notes
в том то и дело не знаю когда будут изменения. Мне нужно или агентом как то закрыть и открыть документ. Или по другому, но не знаю как .
P.S. Суть - я открыл карточку документа нажал кнопку - отправился документ корреспонденту(но Карточка документа открыта), далее корреспондент мне прислал уведомление что он получил , и вот мне нужно это Уведомление каким то образом обработать - записать в открытую карточку или сообщить , к примеру "пришло уведомление, переоткройте документ"
P.S. Суть - я открыл карточку документа нажал кнопку - отправился документ корреспонденту(но Карточка документа открыта), далее корреспондент мне прислал уведомление что он получил , и вот мне нужно это Уведомление каким то образом обработать - записать в открытую карточку или сообщить , к примеру "пришло уведомление, переоткройте документ"
@maliy на клиенте? Я знаю только вариант про JS-таймер, который жмет кнопку на форме.
А в форме уже код, который делает "что-то"... Даже не знаю как это к данной задаче можно прикрутить...
Тут же дело не только в сканировании/отображении, но и "Как понять, что уведомление именно к этому документу?"
Если это обычное письмо, да еще и из интернета...
А в форме уже код, который делает "что-то"... Даже не знаю как это к данной задаче можно прикрутить...
Тут же дело не только в сканировании/отображении, но и "Как понять, что уведомление именно к этому документу?"
Если это обычное письмо, да еще и из интернета...
здесь правильный вопрос - когда корреспондент ответит?
и что делать если документ уже закрыли?
если время измер. секундами - не вопрос - запускаем агент, создаём очередь на сервере, агент в неё пишет результат, клиент мониторит очередь
если почтовые системы не уродские (кот. потртят заголовки) - можно заголовки письма смотреть
можно сабж или тело тегировать
нет, не почта кидает сообщения. у меня появилось сообщение в текстовом файле, агент в БД-2 в документ в history -записал это сообщение из текстового файла в документ в БД-2. Далее нужно синхронизировать history из документа БД-2 в документ БД-1. Если документ в БД-1 закрыт, то синхронизировали поле и все. а вот если открыт?
можно чуть подробнее что из себя представляет и как выглядит?
Ссылка скрыта от гостей
как-то такНО через LS2J может обломаться - там с мультипоточностью м.б. засады (запуск второго такого дока проблематичен)
с др. стороны решение с JS может опрашивать очередь, а агент пишет в очередь
но реализацию проверки сообщений в очереди я не видел (на СиАПИ)
опять же - никто не мешает создать очередь в java - надо курить сингелтон и размещение в jvm/lib/ext
"а вот если открыт?"(с)
напр по JS timer жать на кнопу каждые 5 сек напр,
в кнопе - чтение чо нужно из копии дока в БД-2\сравнение с тем же полем открытого дока\если не равно - переоткрыть, а луче выдать мессагу и тут же прописать в UI, если он эдит канеш
ну и конфликты разрулить )
если ток чтение - мессага и переоткрыть
ЗЫ
ващщета авторелоад в UI должно работать
напр по JS timer жать на кнопу каждые 5 сек напр,
в кнопе - чтение чо нужно из копии дока в БД-2\сравнение с тем же полем открытого дока\если не равно - переоткрыть, а луче выдать мессагу и тут же прописать в UI, если он эдит канеш
ну и конфликты разрулить )
если ток чтение - мессага и переоткрыть
ЗЫ
ващщета авторелоад в UI должно работать
вариант, для классики, неплохой
единственно что смущает - что будет при долго открытом доке и/или несколько таких открытых доков
малевич не придет?
хотя все варианты фронта на "классике" могут позвать малевича
@maliy, вот всё, что уважаемые участники вам понасоветовали - это жесть.
Осмелюсь предложить более приземленный вариант.
1. Принимаем как данность, что любая запись History - это отдельный документ в БД№3 "History Log" (БД ХЛ). Эта запись содежит помимо смысловых полей (Дата\Время, Subject, Кто выполнил и т.п.) еще и уникальное для вашего документа значение-код. Это может быть как его UNID, результат @Unique или любое удобное вам значение.
2. В БД ХЛ как минимум одно из view должно быть категоризированно по "значение-код" и оформлено в соответствии с вашими пристрастиями.
3. В БД №1 и №2 в форме вашего документа вместо поля добавляем встроенный взгляд из БД ХЛ (например на отдельную вкладку таблици) с формулой в show single category.
4. ... Дайте пользователю кнопку обновить этот встроенный взгляд или попробуйте управлять авторефрешем по своему усмотрению
Польза:
- Одна запись истории сразу будет доступна из всех мест существования вашего документа (неожиданно появятся еще 100 БД с ним)
- Меньше конфликтов репликации при одновременном редактировании.
- Обходим ограничение на текстовое поле (если оно у вас текст)
- Выравнивание строк взгляда + вообще произвольный набор данных для лог-записи.
- Управление доступом к истории на уровне Readers\Authors полей и ACL БД ХЛ (что бы запретить рукотворчество)
- А может быть и статистику\аналитику собирать станет намного проще.
Как то так.
Осмелюсь предложить более приземленный вариант.
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-таймер. Дальше посмотрим что из этого выйдет.
На данный момент пробую приладить JS-таймер. Дальше посмотрим что из этого выйдет.
"А если таких внедренных View на форме несколько, да и еще авторефреш у них - то это полная жесть(тормоза). "(с) - если вьюхи положить в таблицу с вкладками никаких тормозов не будет - обновляться будет ток вид в открытой, по необходимости просмотра, вкладке. Да и форма будет куда аккуратней...
На уровне идеи.
Если задача стоит уведомить пользователя онлайн, что что то пришло, наверное запускать нотес таймер и мониторить пришедшее (сам пока не пробовал)
Если задача стоит разрулить возможные конфликты - то идея в том, что мониторить изменение полей в открытом документе и сохранять только те поля, которые изменились. Таким образом условно можно разделить поля в документе на серверные/агентские и на пользовательские. Поставить признак merge/no conflicts. И если надо, добавить проверку на то что другой юзер успел поредактировать (на днях планирую такую задачу реализовать)
Если задача стоит уведомить пользователя онлайн, что что то пришло, наверное запускать нотес таймер и мониторить пришедшее (сам пока не пробовал)
Если задача стоит разрулить возможные конфликты - то идея в том, что мониторить изменение полей в открытом документе и сохранять только те поля, которые изменились. Таким образом условно можно разделить поля в документе на серверные/агентские и на пользовательские. Поставить признак merge/no conflicts. И если надо, добавить проверку на то что другой юзер успел поредактировать (на днях планирую такую задачу реализовать)
Обучение наступательной кибербезопасности в игровой форме. Начать игру!