• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Связь сервера и клиента Lotus

  • Автор темы D400
  • Дата начала
D

D400

Всем доброго времени суток.
С лотусом начал работать недавно, а потому возник такой вопрос:
существует ли возможность отправки сообщений с сервера Domino (например из агента) определенному клиенту и получения от него ответа? Если да, то как ее можно реализовать средствами Java.

На всякий случай, краткое описание прикладной задачи:

Аген на сервере должен вывести на клиенте форму для запроса данных, после чего получить и обработать ответ пользователя. Желательно все сделать на Java. В крайнем случае Lotus Script.

Спасибо всем, кто откликнется
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 940
609
BIT
210
мы говорим про http?
вывести форму - не проблема (тока тонкости есть)
получить ввод, с обработкой кодом (ежели не "собачьим" или JS), можно тока в агенте (вызовом его, прямым или через WebQueryOpen Доминошной формы) - тогда что java зовите, что LS
есть сервлет мэнеджер, встроенный, но он слабенький
можно подключить сторонний

ежели речь про Нотус клиента - вывод формы программно исключён (без хаков), только документ Нотуса
вызов кода возможен любой, напрямую java не вызвать, но можно через:
аплеты (криво)
LS2J (хэлп вам в помошь)
 
A

Akupaka

существует ли возможность отправки сообщений с сервера Domino (например из агента) определенному клиенту и получения от него ответа
нет, лотус поддерживает общение клиент-к-серверу, как, я полагаю, любое клиент-серверное приложение :)
если надо получать указания от сервера, то придется его опрашивать с определенной переодичностью.
это можно сделать либо включив локальные шедульные агенты, и соответствующим агентом опрашивать сервер.
либо используя сетевые протоколы, с пом java / WinAPI или как-нить еще...
 
D

D400

мы говорим про http?

Нет речь исключительно о взаимодействии агента на сервере с агентом же или плагином на клиенте.

если надо получать указания от сервера, то придется его опрашивать с определенной переодичностью

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

Опрос сервера - самый крайний и неудобный вариант. Как я понимаю, в этом случае придется выделять некий буфер (например Notes document), к которому будут обращаться клиенты. При этом клиент должен будет сделать запись о том, кто он, и когда прочитал сообщение (чтобы гарантировать доставку последнего имено тому, кому надо). Но возникает следующий вопрос: а как клиент будет отсылать назад свой ответ? Через запись в тот же буфер, и серверу тоже нужно его периодически читать, или же существуют другие способы?
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Агент посылает письмо с нужной формой. На ней кнопка, которая шлет результат обратно. Обрабатываем его.
Или я что-то не понял? :)
 
D

D400

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

Omh

Может в сторону $Alarms посмотреть?
Типа создаёшь у человека Alarm документ, а у чела он, по идее, будет проверятся.

А чтоб вот так в реальном времени - чёт не уверен.
Если ещё при условии какой-то открытой базы, то реализуемо (типа таймер на PostOpen, который что-то там опрашивает), а что бы глобально во всём лотусе - :) .
 
A

Akupaka

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

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

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

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

объясни задачу более глобально, возможно тебе предложат подходящий вариант :)
 

Medevic

Что это ? :)
Green Team
10.12.2004
3 334
1
BIT
4
Может в сторону $Alarms посмотреть?
Типа создаёшь у человека Alarm документ, а у чела он, по идее, будет проверятся.

А чтоб вот так в реальном времени - чёт не уверен.
В реальном не будет работать. Плюс у пользователя агент может быть отрублен, тогда никакого алярмса не будет. :)
 
O

Omh

Akupaka
Которые по умолчанию отключены :)

Кароч, делаем сторонюю тулзу, которая раз в n секунд опрашивает некую базу на предмет появления документов адресованых пользователю.
Если находит - материт.
Алармс - в печь.
 
D

D400

Ага. Так вот по поводу задачи:

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

Тут и начинаются проблемы:
А. Как дать пользователю знать что серверный агент ждет его реакции? (Вопрос определения "нужного" пользователя тоже открыт, хотя и является второстепенным).
Б. Как передать агенту ответ пользователя?

Что я "нарыл" из возможных подходов:

1. На каждом клиенте поднимается агент, опрашивающий сервер на предмет запроса. Обмен данными происходит через некую базу. Самый неэффективный и громоздкий способ, на мой взгляд.
2. Попробовать задействовать средства самого Lotus. Например Lotus Administrator хранит у себя все открытые коннекты. Может отсылать любому из них "Broadcast message". Как он это делает? Если бы получить доступ к этим сообщениям, задачу А можно было бы считать решенной.
3. Написать клиент-сервер на Java для реализации обмена сообщениями. Но тогда возникает вопрос В: как прикрутить java к лотусу? (влезть в его интерфейс, получать доступ его агентам, использовать его канал связи - все это пока кажется мне малореальным).

Тем не менее, возможность отправки "Broadcast message" (п. 2) вселяет оптимизм и надежду, что хотя бы половину задачи можно будет решить изящно и средствами самого Domino. Быть может кто-то подскажет с какого конца к этим connection можно подступиться?
 
30.05.2006
1 345
12
BIT
0
А. Как дать пользователю знать что серверный агент ждет его реакции? (Вопрос определения "нужного" пользователя тоже открыт, хотя и является второстепенным).
Б. Как передать агенту ответ пользователя?
1.Сёрверный агент не может ждать реакции пользователя, у него UI нету (и не может быть); UI - только на клиенте.
2.Агента на сервере можно связать с клиентом ВНЕ-лотусовыми средствами (по ip к примеру). На время ожидания ответа клиента сервер (не агент) будет завешен (потенциально - навсегда)
 
A

Akupaka

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

про Lotus Workflow поищи, почитай, если с документтооборотом не работал. может реализуешь похожее попроще сам, а может предприятие купит Workflow, либо найдете аналогичный продукт...

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

это моя точка зрения :)
 
D

D400

Ну на самом деле изложенная здесь проблема - лишь часть большой общей задачи. Которая (задача) как раз и строится по схеме:
а может лучше организовать классическую схему документооборота? ))
агент обрабатывает документ (который предварительно создал пользователь), приходит к выводу, что нужно решение пользователя, документу присваивается статус - обработка пользователем, пользователю уведомление, по которому, он пойдет к документу, и вынесет решение, документ переводится в статус - обработка сервером
ну и так далее...
Но существует необходимость получения ответа от пользователя как можно скорее. Пусть у него что-то мигает, звенит, бьет в колокола, лишь бы он побыстрее сделал то, что от него требуется. Тем более, что это действие, как правило будет сводиться к простому выбору из нескольких вариантов. Типа нажать одну из трех кнопок. Такая срочность вызвана тем, что предполагается одновременная работа большого числа (нескольких сотен) пользователей. И если дожидаться пока каждый из них проверит свою почту или зайдет в базу текущих дел, то весь процесс растянется на годы.

Сёрверный агент не может ждать реакции пользователя

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

Агента на сервере можно связать с клиентом ВНЕ-лотусовыми

А можно с этого момента подробнее? Как это сделать (где почитать) и, главное, что это даст? Сможет ли плагин на клиенте зарегистрировать Listener в серверном агенте? Как они вообще смогут узнать о существовании друг друга? При этом не хотелось бы полностью отвязываться от Лотуса, т.к. в нем есть и виртуальная машина, и среда выполнения java кода, да и серверные агенты тоже написаны на java.
 
K

K-Fire

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

Гмм, а что это за мега-крупное такое предприятие, где одновременно и постоянно с докоборотом будет работать несколько сотен пользователей? Можно без имен :)
Я честно говоря затрудняюсь себе представить такой бизнес-процесс, чтобы одновременно сотни людей должны были не отвлекаясь работать с информационной системой.

Кстати говоря, именно поэтому, задача сама по себе кажется странной. Ну допустим пользователь создал документ, отослал его на обработку. И после этого он выключает клиент (или даже компьютер), уходит обедать, уезжает в командировку. И как при этом сервер должен от него получить какой-то ответ?

PS. ИМХО самое простое и дешевое решение, если уж поставку задачи не изменить, это отсылать почтовые уведомления. Настройте клиенты, чтобы опрашивали почту раз в 5 минут и выдавался диалог. А пользователь уже пусть сам соображает что к чему.
 
A

Akupaka

Пусть у него что-то мигает, звенит, бьет в колокола, лишь бы он побыстрее сделал то, что от него требуется
NotesMinder знакомая вещь? сделай такую же!
единственный вопрос - как ее запускать.
например, если удасться запустить из запущенного лотуса java-код, который будет сканировать раз в 60-120 сек базу с уведомлениями о задачах, то авторизация будет осуществляться еще при запуске notes, если так не удастся, то внешнее приложение, которое уже будет использовать Notes-объекты посредством COM/Java (по аналогии с COM, не знаю как правильно называется)/CORBA/WebServices, но при запуске необходимо произвести авторизацию.

на сервере есть возможность запустить Java-код при запуске сервера с пом. RunJava Addin, можно ли аналогичным способом на клиенте запустить Java-код, я не знаю... lmike може знает :) он один из Java-лотусистов :)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!