Let's talk about SSP (server-side printing)

[aidacra (Nathan your friendly neighborhood Support Engineer)]

@ckrusen

Finally, between pts 4 and 5 of the section "GUIDELINES TO IMPLEMENTING SERVER-SIDE PRINTING IN YOUR ENVIRONMENT’ you refer to 2 screenshots that appear to be missing.

Thank you, I have added those screenshots. I was drafting this in Evernote, and I had to manually copy/paste each image here afterward --I missed a few

@ckrusen

Several times you refer to the “3 seconds” delay when printing to a non-server side printer. I’ve never seen a print job render in anything under 15 seconds (maybe 10 at best). Seems that it takes at least 5 seconds from when it is first submitted, before it even becomes active. And another 5 to 10 after it completes(moves from active tab to history tab), until it is sent to the printer (or preview window). Is this normal?

The “3 seconds delay” I am referring to is technically the processing delay set on the System Agent record within the application–it could be any value between 0 and 9999 seconds. It should never be set to less than 3 seconds and setting this higher than 3 seconds is just added additional latency to any IMMEDIATE run request like most reports, which is why I just referred to it as the 3-second delay–never set it lower and doesn’t make sense to set it higher. Fun fact, in E905 and earlier, if one set the processing delay to less than 3 we treated it as 15 seconds so setting it to 2 seconds actually is a longer delay than setting it to 3. Maybe not really fun.

This processing delay really is the polling frequency of the task agent configurations. When the taskagent configuration starts up, it makes a connection to the appserver to determine a number of things from the database and the frequency in which it checks for new requests to process is this processing delay. A value of 3 here means that every 3 seconds after the taskagent configuration is started it will check to see if there are any scheduled/immediate run requests that need to process within that cycle. If not, it just ends the cycle. If so, it will move to ACTIVE up to the number of concurrent tasks set on the taskagent configuration and any number of tasks exceeding that concurrent tasks threshold is set by that taskagent configuration as “PENDING” (all capital letters) in active tasks.

All of this context is to say that sometimes this polling frequency has a huge impact on total “submit print to actual printer time” and other times, it doesn’t. If your processing delay is anything other than 3, I would recommend changing it and restarting your taskagent configurations.

Also note that sometimes the line between server-side printing AND IMMEDIATE printing AND IMMEDIATE RUN REQUESTS can be a little confusing–IMMEDIATE printing requires server-side printing to be enabled but they are not the same. This polling frequency applies to all background processing tasks (printing, processes, etc) where it wasn’t triggered by an IMMEDIATE queued autoprint BPM even if server-side printing is enabled. IMMEDIATE queued autoprint BPMs (which require a server-side printer to submit it to) will immediately submit the report to the server as soon as it is done being rendered. IMMEDIATE RUN REQUESTS aren’t immediate in the technical sense–in fact with the exception of autoprint BPMs set to IMMEDIATE, everything else that is processed through the System Agent is really asynchronous and when the system will start processing them is based on what the processing delay is on the System Agent.

@ckrusen

Also, does having the System Monitor window open slow down the time between when it is finished processing(goes from active to history tab), and it renders? Maybe it’s a psychological thing (“watched pot never boils”) that just makes it seem to take longer. But seems like it doesn’t render until I close the SysMonitor.

Let’s sidestep whether or not it’s in your head for a moment and instead make some adjustments to return completed reports back to your workstation sooner regardless.

If you open your System Monitor > Actions > Configurations. There are three values:

I am going to talk about them out of order:

• Priority: By default, it is 3 seconds. When the user session submits a print request, it starts this priority client to appserver polling mode so it checks “hey any print requests that belong to my workstation method on the company maintenance record, are you done?” If so, it pulls the request back to the client.

NOTE: Always change the workstation method to literally anything other than the default for every company. My preference is Machine Name + Domain User as it is most likely to be the most unique.

• Duration: By default, it is 15 seconds. This is how long the priority mode lasts. What this really means is that every 3 seconds, for 15 seconds, the System Monitor will try to return back to that client any print requests that complete within that 15 second period.
• Normal: By default, this is 30 seconds. If the System Monitor isn’t in “priority” mode, it is how frequently the system monitor polls for reports to bring back to this client session. That means that the System Monitor will only check for reports to bring back to the client every 30 seconds.

So for client-side printing, if your report takes 16 seconds to process on the server, you won’t see it be returned to the client until 45 seconds after the print request was submitted (the normal frequency starts as soon as the priority frequency ends–15 + 30 seconds).

For it to not be in your head, one of two things would need to be happening:

1. When the System Monitor is closed, the client makes a call to the appserver to return any completed reports back to the client
   OR
2. The polling frequency with the System Monitor being open is different than the polling frequency of the System Monitor not being open.

I tested this in 10.1.600 by adjusting my normal frequency to 60 seconds to make it easier for me to keep track of it, then enabling the UI trace and the Powershell get-content “UI trace file name” -Wait command against my UI trace file–I couldn’t duplicate either of the two things that could be causing what you are saying to happen. (the call I was looking for was ReportMonitor.GetRowsKeepIdleTime). This isn’t to say that at some point in the ERP history that we didn’t do one of the two things above, but, not seeing it in 10.1.600.

That being said, you can use your observation and just change how the system works with the System Monitor is open or closed and just make some adjustments to the three values above so you don’t have to worry about it. If you were to change the duration from 15 seconds to 60 seconds, for any report that takes less than 60 seconds to process from the perspective of the appserver process it will be returned to the client within 3 seconds instead of up to 44.9 seconds if the report were to take 15.1 seconds to process.

You can edit the values on the server’s copy of the .sysconfig file in the clientdeployment folder, so the next autoupdate of the clients brings down the updated values. You would change the SystemMonitorPriorityPollDuration to 60000 instead of 15000.

@ckrusen

Is there any advantage (or disadvantage) to setting up a printer that is connected to a workstation (and shared on the network) as a server side printer? Besides other users being able to print to it. If that workstation is disconnected, would E10 show an error to the user that initiated the print job?

If the printer is simply powered off, an error wouldn’t present to the user that submitted the request because from the ERP side, the report was successfully processed and we handed it off to the printer without the printer throwing an error–once we submit it to that printer, we have no awareness of what happens from that point on.

From the printer’s perspective, it is just sitting in the queue and as soon as the printer is powered on it will start processing.

If the workstation is off, I suspect you would see the following error message because we can’t hand off the report to the printer, and if anything goes wrong, it’s this error:
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Settings to access printer '\\machinename\sharedprinter' are not valid.

And to test it, I enabled a taskagent configuration on my interactive appserver server (win2016) and powered off my dedicated taskagent server (win2008R2) with my Printer record pointing to my shared win2008R2 printer. Submitted a book listing, and it stayed in ACTIVE tasks as ACTIVE for much longer but after ~30 seconds it failed with this error:
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Settings to access printer '\\hv-win2008r2svr\Brother_MFC-7860DW_Printer' are not valid. Stack Trace:

Not sure if either of the two behaviors would be considered advantages or disadvantages–I’ll let you decide that