Don't see the need for this; the obvious solution would be to run the agent with SendConsoleCommand - then You don't have to wait for the agent to finish before continuing execution of Your agent.

This is a workaround. In addition, there is a security restriction on the ability to run SendConsoleCommand.
Much easier to have a second option, as I described!

Interesting idea but I think complicated to implement because it introduces synchronisation problems. There would have to be a callback function within the code similar to NotesTimer, again issues arise since the calling code may terminate before the asynchronous call completes. Could you explain why you'd like this feature as there may be an existing way ot achieving same?

1. Need to modify the response documents without the author's access to them.
2. Because of the considerable time of document processing, so as not to wait for the end of execution.

I'm voting this idea up because I think it might be useful, but I suspect maybe your code or database structure could be more efficient if you're genuinely having application performance issues. How are you updating responses? How long does it typically take?

Thanks, Mark
In the example of the response document performance problems did not exist. But they may be, if the number of response documents is large.

From what I've come across recently. Developed a custom application for organizing mailings. The user clicks a button to perform list. Newsletter uses an image, the body in html-format, the stream to form a MIME-fields. All this is done on the server and takes time proportional to the number of mailing lists. After pressing the button, after Agent.RunOnServer the user waits for the execution list.

OK so for simple updates to Author fields it shouldn't take a huge amount of time even with a large number of documents - on the other hand what you're talking about now is complex processing and mass-mailing.

My suggestion is that you don't process such requests immediately - create a separate database to act as a queue for processing such mailouts, with scheduled agent that runs every 15-30 min. When such a 'publish' occurs a request 'stub' is created in the queue database and processed on schedule. When completed the user that submitted it is notified and stub set to 'completed'. This way you also have an audit of what happened and when, which can be useful.

Dear Mark,
Initially it was implemented on a schedule agent.
But I thought it could be done better. And tried to use Agent.RunOnServer :)

How to you prevent multiple parallel execution of the server agent?
I implemented something similar to this by a small agent that was started by RunOnServer and did nothing else than a tell amgr run...
Based on experience the users will press the button over and over because
they don't get an immediate response.

Actually Peter is right Notes is not an assynchronous architecture except for the 'hopelessly fragile' NotesTimer. Voting this down.

> 9) Peter Neidhart635 (07.06.2012)
> How to you prevent multiple parallel execution of the server agent?
It is perfectly solved by using the (hard-) locking mechanism.

> 10) Mark Demicoli8588 (07.06.2012)
> Actually Peter is right Notes is not an assynchronous architecture except for the 'hopelessly fragile' NotesTimer.
Run multiple background agents and you get all asinhnonnost "problems" described by Peter.

I vote for this idea, as there are many operations where the wait for a response from the server, the user does not need. For example export data in a relational database. The user performed some action, and some data must go immediately. He does not need to wait for the result.

The easiest option for this sort of thing is to create a document which goes to a view that is monitored by an agent. Then have that agent process outstanding requests and move them out of the view.

Easier to audit that way and recover if something went wrong during agent execution.