Hello,
First of all our customer using IFS Cloud 23.2.8 version.
In this case, we try to print a Work Order Report for 13 lines of work orders.
There is an error occured which is “Error When Printing to Aurena Agent Timeout” and nothing happens, dialog closed.
Log records in below;
Application - CMD(2): timeout in agentcall after 60000 ms
Application - CMD(2): toast({"type":"error","msg":"Error when printing to Aurena Agent ${error.Message}"})
Does anyone know reason or solution for it?
All calls/uses of the Aurena Agent, by default, times out after a 60 seconds. If something it does takes longer, IFS Cloud will show this error. Sometimes whatever was needed to be done is already done, and all is good, but that doesn't seem to be the case here. I wonder what is happening that takes so long time here.
In report printing, the Aurena Agent can be used to print a report locally. Is that needed here?
All calls/uses of the Aurena Agent, by default, times out after a 60 seconds. If something it does takes longer, IFS Cloud will show this error. Sometimes whatever was needed to be done is already done, and all is good, but that doesn't seem to be the case here. I wonder what is happening that takes so long time here.
In report printing, the Aurena Agent can be used to print a report locally. Is that needed here?
I was just wondering why and it’s good to know the limitation.
We have, what we think, problem with the same timeout (see image)
We have users that get this error when they are in the process of check-in Documents. The users, for various reasons, takes more than 60 seconds to select the document to check-in and then they get the error. If they then select a document to check-in nothing happens since it seems the Aurena Agent has lost connection to the application.
Hej Ove!
You (as a customer) cannot control this today. The default timeout is hard-coded in the client framework.
We can override the default timeout in each agent call/command however. And we have done that, for the upload and download agent commands, because we don't want the agent call to timeout when we do a large file transfer, right?
For the file selection however, which has it's own agent call, we didn't foresee that users would go and grab a cup of coffee instead of picking the file... 
If I were me, I would not accept this as a bug, or at most it's a P3 bug because the workaround is easy and there's basically no harm, more than some confusion.
How about adding an idea in the Ideas section here in IFS Community? The change is not very hard, but it needs to be done in a lot of places, so will require a bit of time from that perspective…
In the meantime, you simply need to educate your users that they have "only" 60 seconds to select a file.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.