Передача параметров агентам

[lmike]

Краткий NoteID генерируется потому, что при вызове агентов любая строка, переданная в качестве ParameterDocID режется до нескольких символов (4 или 5, не помню). Если передать туда, к примеру UNID, то в агенте там будет только начальный кусок. Это неприятно. Лучше бы сделали вместо передачи NoteID передачу строки с более-менее вменяемой длиной, в которой можно было бы передавать параметры (NoteID и др.), но имеем то, что имеем...

ну теоретически: надо перейти на РЕСТ и спокойно передавать "что угодно"...
или писать док в ящик (как часто организуют), а внешняя тула пущает агенты (по расписанию счупает или адын+эктманагер)
самый "простой" вариант domino-jna/domino-jna/src/test/java/com/mindoo/domino/jna/test/TestAgentExecution.java at master · klehmann/domino-jna
проверял, работает..., в несколько потоков не тестил
можно:
- поднять РЕСТ сервис очереди (например с прешаренным ключом, для сесуриту), на springboot
- из нотусни/домины даём сервису юнид дока (если надо) и/или параметры (боди РЕСТа), в Auth - ключ (токен, для сесуриту)
- к аппе прикручиваем domino-jna
- профит...
PoC (Proof of Concept) пока не набрасывал, но там несложно, основным будет - аккуратное общение с доминой (чтобы в мультипотоке не залочить)

 

[VladSh]

@lmike
Сама идея наверное классная, но такое не пробовал пока. runWithDocumentContext и runOnServer как-то попроще будут.
И код какой-то стрёмный. Видно, чувак писал его 7 лет назад, когда recycle был обязателен; и при этом у него только в этом классе 4 гарантированные утечки и ещё 2 возможные...

 

[lmike]

@lmike
Сама идея наверное классная, но такое не пробовал пока. runWithDocumentContext и runOnServer как-то попроще будут.
И код какой-то стрёмный. Видно, чувак писал его 7 лет назад, когда recycle был обязателен; и при этом у него только в этом классе 4 гарантированные утечки и ещё 2 возможные...

там recycle в обертке часто (final)
и это тесты - там не нужно об утечках думать
там в тестах я заметил есть "ляпы"...
в ACL наткнулся на несколько
например lookup выполняется с учётом только 64бит, как результат - ошибка на 32бит
в getEntries - тоже непонятка, но судя по симптомам - трабла с битность ("корка" на нативном вызове)
я разрабу писал, но он занятой (в HCL работает) и ждать патчей или к-л продвижения не стоит

WithContext хорош только до момента межпроцессного взаимодействия, увы
и все штатные методы ЛС не обладают асинхронностью, а это большой "-"
остаётся привлечение внешних программ и живо встаёт вопрос уровня взаимодействия и скорости + безопасности для платформы (домины)
Т.к. падение внешней проги мало затронет саму домину - можем задействовать СиАПИ
Удобнее юзать обвязку через java, т.к. там уже "всё написано".... да, есть ошибки, да - есть JNX (с поддержкой от HCL), но там свои тараканы
отсюда - вариант с JNA наиболее "жизнеспособен"

 

[savl]

я osgi-плагин сделал, который агенты пускает.
Да, на него передаётся unid документа, где всё прописано, а сам плагин просто берет базу, агента и запускает его над этим же документом.
По факту агент теперь работает в http, как следствие - несколько копий одновременно.
И наследует все прелести и не очень, включая тайм-ауты.