Россыпь мелких вопросов

[savl]

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

Там Execute используется для создание дока, это код в библиотеке. В той базе пользователи являются депозиторами.

 

[erdi]

но все-равно ведь изначально от пользователя идет. после Execute добавьте agent.runonserver или код по запуску агента добавить в Execute

 

[savl]

agent.runonserver или код по запуску агента добавить в Execute

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

 

[rinsk]

Задача: Ускорить запуск этих агентов.

На сколько ускорить? Минимум для шедульных агентов - 1 минута.
Если по почте - то Predelivery Agent.
Он уже через консоль запускает нужные агенты обработки.
Интересно кста - если Predelivery будет работать 2 мин - что будет делать роутер...

 

[savl]

Минимум для шедульных агентов - 1 минута.

хм... после сохранения все равно 5 встает.
Впрочем, 5 минут и так быстро.

Если по почте - то Predelivery Agent.

before new mail ? вот пока идея именно такая... Но да вопрос с роутером...
Запросы генерятся достаточно быстро...

Вопрос снимаем, не будем пока ничего менять

 

[lmike]

КМК а DOTS можно перехватывать события

 

[rinsk]

хм... после сохранения все равно 5 встает.
Впрочем, 5 минут и так быстро.

Эт обман зрения Надо ставить 1 минуту, сохранить. И и не паниковать по поводу 5 мин на экране)

before new mail ? вот пока идея именно такая... Но да вопрос с роутером...

Дабы не держать роутер - SentConsoleCommad("tell amgr run... "

 

[erdi]

ну ок, и в чем тогда выгода?

ну, не знаю как у вас реализована логика..но у меня реализовано по похожей схеме и точно по таким же причинам что и у вас.
клиент формирует некое задание-документ, в котором описывает что он хочет сделать с документом(ми), сохраняет его в базу заданий и запускает там агента на обработку своего задания
данный агент вызывает на сервере уже другой агент, который и будет анализировать данное задание, а т.к. первый агент вызвал второй агент, то пользователь который запустил 1-й агент не ждет выполнения 2-го, а завершает работу. При этом 2-й(главный агент, в котором вся логика) продолжает еще работать на сервере
2-й агент видит документ задание выполняет там Execute код, который ему оставил клиент и потом выполняет свой код по анализу документа, отчетов, запуску других сервисов и т.д.
в результате:
- пользователь нажал кнопку и вышел, не ожидая выполнения всех агентов/сервисов
- получили монопольное изменение документа только агентом на сервере + некая последовательность обновления документа + блокировка если текущие изменения меняют важность прохождения документа

 

[erdi]

по похожей схеме, но не по содержанию обновляется справочники сотрудников в разных системам и серверах(ERP, АБС, бух-ких, web-порталов, LDAP и т.д.)
при этом пользователь не ждет пока это все обновится - нажал кнопку и ушел
можно было по событию и оставить агента, но добавил еще и таймер, чтобы если не выполнился/не запустился агент по событию - через 15-30 минут самостоятельно повторил операцию

 

[savl]

а т.к. первый агент вызвал второй агент, то пользователь который запустил 1-й агент не ждет выполнения 2-го, а завершает работу

Так... Разве не ждет? У меня было иначе, ручной агент в кнопке, в коде вызывался runOnServer другой агент.
Клиент ждал, пришлось заменить на SentConsoleCommad

 

[savl]

Коллеги, 2 вопроса:
1. Как программно перестроить вьюху?
У меня в колонке формула изменения цвета текста, зависит от текущей даты.
Документы править ночью нельзя, поэтому решили сделать так.
Нашел совет послать команду на консоль: {load updall yourdb.nsf -t yourview -r}
Сомневаюсь, что стоит делать на все вьюхи... Что посоветуете?
2. Необходимо сделать отображение документов-ответок из другой базы к текущему документу.
Есть основной документ, есть группа "ответных документов".
Эти документы в другой базе.
Подумал отображать через фреймсет, чтобы можно было этот фрейм скрыть при необходимости...
Вопрос как отобразить эти документов во фреймсете, да еще и по категории...

 

[alexas1]

По второму вопросу:

сделать отображение документов-ответок из другой базы к текущему документу

- значит в "другой" базе доки "ответки" связаны с текущим доком его юнидом. Так?
Делаем в "другой" базе форму ("FormWithView", к примеру), на неё - embedded view с категорией UNID парента и single cat. по ней.
Открываем в фрейме в основной базе эту форму из "другой" по формуле:
Type -> NamedElement
Value -> Computed:
Formula for kind of named element -> "Form"
Formula for database -> что-то типа так:
server := @Subset(@DbName; 1) ;
path := @LeftBack(@Subset(@DbName;-1);"\\") +"\\nd.nsf";
@If(server != "";server + "!!" + path; path)
Тут первая и вторая база лежат в одном каталоге (сервера или клиента)
Formula for name of named element -> "FormWithView"

Точно также можно открывать фреймы из другой базы с кучей барахла для работы.

UNID в "другую" базу передаём через личный профайл (не важно в какой базе) или MessageQueue или JavaScript между фреймами, что больше нравится.
=================
Но я бы делал через xpages, так проще и первый вопрос решился бы автоматом (без перестройки view).
Кста, хэпаги в классике, для смешанной техники, можно открывать не только в отдельном окне, но и в фрейме: открывается в фрейме форма, на ней браузер, а в нём, при открытии грузится нужная хэпага (естественно из любой базы и любого сервера). Открывается даже быстрее чем в нотусовом бровзере.
В общем, xpages решают все проблемы.

 

[savl]

общем, xpages решают все проблемы.

Сам бы так делал, но нужен клиент 8,5+ Standart, у нас есть пользователи с 7-ой и 8-basic.
9-ку накатить на них нет варианта (технопарк страдает), выводить базу в web нет возможности (только в будущем проект есть)

 

[lmike]

у нас есть пользователи с 7-ой и 8-basic.
9-ку накатить на них нет варианта (технопарк страдает)

если у них канал "достаточный" перевести их на терминалы

 

[savl]

если у них канал "достаточный" перевести их на терминалы

Обсуждалось, нет такой возможности... И вкладываться не хотят.

 

[lmike]

Обсуждалось, нет такой возможности... И вкладываться не хотят.

они удаленные с плохим каналом? или просто терминал лицензии "дорого"

 

[savl]

@lmike,
Сервера там есть, просто старое все. Там все менять будут, но позже.
И сервера и машины, проект готовят.
Сейчас домены там решили объединять, потом структуру сети могут поменять.
Полная переделка.

 

[lmike]

Сейчас домены там решили объединять, потом структуру сети могут поменять.
Полная переделка

т.е. вопрос ценой от полугода и более...
а что за железо и кол-во таких клиентов?
[DOUBLEPOST=1431075785,1431075559][/DOUBLEPOST]я понимаю что ИТ вряд ли согласится...
просто если есть компы, в офисе, у кот памяти 8Гб - можно их нагрузить виртуалкой с нужной доминой

 

[alexas1]

общем, xpages решают все проблемы.
Сам бы так делал, но нужен клиент 8,5+ Standart, у нас есть пользователи с 7-ой и 8-basic.

Говоря об xpages, я имел ввиду не только удобство программирования UI, но и другой подход в создании дизайна для классического клиента нотус. Чтобы встраивать HTML дизайн (хотя бы для отдельных контролов) вовсе не обязательно использовать встроенный фреймворк. Достаточно иметь запущенный HTTP сервер на домино и (или) запущенный nhttp.exe на клиенте (он есть в семёрке basic), а выполняться HTML может вычисляемым Pass-Thru HTML или во встроенном в форму браузере (загрузкой подготовленной под веб формы или страницы) или нотусёвым браузером в отдельной вкладке. И писать HTML врукопашную, используя любые JS либы (в том числе для показа tree view).
Не понимаю упорства использовать ТОЛЬКО встроенные элементы дизайна, имея возможность воткнуть в форму ЛЮБЫЕ. Можно, конечно, и на джаву смотреть но HTML & JS работают шустрее, прогить проще и уже наработанного море.

 

[savl]

а что за железо и кол-во таких клиентов?

по новому железу не скажу, просто не знаю.
Клиентов, примерно 1,5 тыс душ.
Про 8 гигов: максимум видел 2 гига, winXP...

прогить проще и уже наработанного море.

Вот у меня наработанного нет, в в будущем как раз предстоит.
Делаем интранет систему...