We have a Time Off database where employees request time off and the manager approves it. This database also calculates the employee vacation accruals. If a user submits 2 time off requests, the second request will not have the accurate vacation accrual amount because the first request wasn't approved/denied yet. We don't want employees to have a negative vacation balance. The best place to update the vacation balance, is after the request has been approved. We can do this when exiting the request, but the manager's client has to wait for the agent to run and update the employee's vacation balance - thus taking a processing "hit" and locking the client until the agent is finished.
Is there a way to trigger a background agent immediately after the approval where the manager's Notes client doesn't have to wait through the processing time?
I'm not sure if RunOnServer is the option we are looking for (documentation doesn't say if this command will lock the client while processing). Maybe there's some other way we can accomplish this?
Yes, you can use run on server.
If you save the document, you can then call an agent with the document as a parameter and "run on server" properties. Run on server will not lock up the client, but your challenge may be in knowing when the agent is complete and informing the end user at that time.
Regards
We've tried the RunOnServer and it still locks up the user's client. The process takes about 15-20 seconds but it's an uncomfortable amount of wait time for the user. Adding a message "Updating Fred's vacation balances..." in the lower left while it's running doesn't help because the user isn't looking there. It would be nice to just have a clean break from the process and the Notes client.
15-20 seconds does seem like a long time to perform such as task. Perhaps there is optimization in the code / views that could improve this? We have a time sheet application with over a million documents and the processing time for calculating balances is less than 2 seconds.
Do you views have anything using @Now or @Today in the SELECT section as this will cause a serious performance hit when the view is being accessed in the client or programmatically.
Programmatically called agents will lock the client during the agent runtime. RunOnServer will typically be more performant than client side execution.
I have employed the use of a queue approach to work where there is an agent that checks for work to perform to assist in activities that do not require real-time operation. This being said, that same agent can be called and pass a noteid in for single purpose execution where it is time sensitive.
If there are multiple managers doing the approving and and you are going to use the RunOnServer method as suggested above, n=make sure the agent is thread safe per the following KB article -
https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0091117
You could write a Lotusscript agent and in your query save event on the client, have that agent called from there. You can pass the noteid (Uniqueid) of the document if you'd like as well. This way the agent run from the client would run on the server and not on the client.
Try this url for information:
http://www.setgetweb.com/p/portal61/info/WPF61/c_domino_invoctn_agents.htm#c_domino_invoctn_agents__invoke_agent
I also wanted to mention that I had to do some processing on a notes client and the number crunching was too much, similar to yours. I used an agent that was called from the client, and just before the agent was called, I would save a backend document with the data in it that needed crunching. Then I'd pass the UNID of that document to the background agent. The agent would process the data and delete the temporary document after it was done as well.
If you think this is what you need, I could dig up the code and pass it along.