Непонятная выдача результата doc.NoteID

[Ficoos]

Доброго дня, форумчане! Есть такая штука, как программный запуск агента на сервере с передачей параметра NoteID.
Так вот, в параметр передается только несколько значимых символов из doc.NoteID. Ну например: в свойствах документа NoteID = "NT0000128A", а в качестве параметра doc.NoteID или Cstr(doc.NoteID)
передается "128А". Это глюк у меня или это просто решается путем вычисления длины строки и добавление нулей впереди переданного параметра?
Я уже решил как это сделать, но хотелось бы понять природу такого поведения команд.

 

[savl]

Доброго дня, форумчане! Есть такая штука, как программный запуск агента на сервере с передачей параметра NoteID.
Так вот, в параметр передается только несколько значимых символов из doc.NoteID. Ну например: в свойствах документа NoteID = "NT0000128A", а в качестве параметра doc.NoteID или Cstr(doc.NoteID)
передается "128А". Это глюк у меня или это просто решается путем вычисления длины строки и добавление нулей впереди переданного параметра?
Я уже решил как это сделать, но хотелось бы понять природу такого поведения команд.

Это особенность работы Fornula / LS / Java.

Formula вернет NTXXXXXXXX
LS и Java только последние реальные цифры
Dots (если знаете) может вообще вернуть не hex запись, а decimal , например 25323 и потом надо в hex преобразовывать.

 

[Ficoos]

Это особенность работы Fornula / LS / Java.

Formula вернет NTXXXXXXXX
LS и Java только последние реальные цифры
Dots (если знаете) может вообще вернуть не hex запись, а decimal , например 25323 и потом надо в hex преобразовывать.

Значит придется решать путем заплаток на код...
Прикольно, что в хелпе для Notes Designer написано, что NoteID для класса NotesDocument возвращает строку 8 символов. Вот прохвосты! )))

 

[VladSh]

Краткий ID, типа "128А, в пределах той же самой базы работает без проблем. Если нужно вызвать агент из другой базы и передавать ему документ, тогда лучше делать временный документ и записывать туда UNID.

 

[Ficoos]

Краткий ID, типа "128А, в пределах той же самой базы работает без проблем. Если нужно вызвать агент из другой базы и передавать ему документ, тогда лучше делать временный документ и записывать туда UNID.

В агенте документ выбирается из представления. а код: db.GetDocumentByID(noteid) или db.GetDocumentByUNID(unid) не всегда находят документ даже в собственной базе, особенно, если этот документ новый и только что сохранен в базе. А представление можно сначала обновить, а потом в нем можно найти документ по ключу.
Спасибо за помощь, идеи и разъяснения!!!

 

[VladSh]

Да, с видом бывает такое, но с NoteID. В таких случаях можно получить документ, взять его UNID и получить документ по UNID.
Если брать доки из вида перебором, то NoteID при перепросчёте вида могут сбиваться. В таких случаях перед взятием документов желательно сделать NotesView.AutoUpdate = False, а после работы с видом вернуть обратно в True. Я уже и не помню, чтобы такие проблемы были.

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

 

[lmike]

Да, с видом бывает такое, но с NoteID. В таких случаях можно получить документ, взять его UNID и получить документ по UNID.
Если брать доки из вида перебором, то NoteID при перепросчёте вида могут сбиваться. В таких случаях перед взятием документов желательно сделать NotesView.AutoUpdate = False, а после работы с видом вернуть обратно в True. Я уже и не помню, чтобы такие проблемы были.

P.S. Краткий 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 возможные...