The Direct Print service monitors the print queue in Business Central to detect new print jobs waiting to be printed. It does this by polling the print queue directly and using a signaling hub.
When polling the print queue directly, the Direct Print services uses an API on the Business Central server. It identifies itself using a service name. The API scans the print queue to see if any jobs are waiting for this particular service. It checks if there are any waiting jobs and if the service has the local printer connected and set for the print job.
Polling via the API in Business Central has two timing elements. The first is the waiting time between two consecutive polls. The polling pauses for a bit before the next poll to ensure that the API is not keeping the Business Central server too busy. This is called the local wait time between polls. Another element is the time the API takes until it concludes that no jobs are waiting. If no jobs are waiting for the polling service, the API can return immediately or wait for some time to see if any jobs appear within the next couple of seconds. This is called the remote wait time. The benefit of using a remote wait is that there are fewer polls and that the printing reacts faster to new jobs. On the downside, it keeps the API session busy while the wait is active.
Even though the polling via the API puts a load on the Business Central server, it is most likely not noticeable. Nevertheless, there is an alternative option that has a smaller footprint on the Business Central API performance. This is called the signaling hub.
A signaling hub is event-driven messaging seen from the Business Central side. When a print job is placed on the print queue in Business Central, a signal is sent to a signaling hub. The Direct Print service polls a signaling hub to detect new print jobs. Whenever a signal is detected, it polls the API to see if the job matches the criteria for the service. Using the signaling hub minimizes the polls to the API on Business Central.
While both of these polling methods have their benefits, a combination of the two is often the preferred strategy. When the Direct Print service is installed, it comes with a default strategy for mixing the two ways of polling. However, you might want to change the default behavior to better match the requirements of your installation and application of direct print.
Configuration Files
You can use a configuration file to control the polling strategy for the Direct Print service. When the service starts, it looks for a file in the following location:
C:\ProgramData\ForNAV\Direct Print\Configuration\config.json
The content of a configuration file is a JSON string describing the default polling strategy or specific strategies for specific environments.
Here is an example:
{
"Version": 1,
"Environments":
[
{
"Name": "default",
"Strategy":
{
"SignalHub": {
"Intervals": [
{ "Duration": 0, "LocalWait": 0 },
{ "Duration": 60, "LocalWait": 1 },
{ "Duration": 600, "LocalWait": 2 },
{ "Duration": 3600, "LocalWait": 3 },
{ "LocalWait": 10 }
]
},
"PrintQueue": {
"Intervals": [
{ "Duration": 0, "LocalWait": 0, "RemoteWait": 10 },
{ "Duration": 120, "LocalWait": 0, "RemoteWait": 10 },
{ "Duration": 3600, "LocalWait": 30 },
{ "LocalWait": 60 }
]
}
}
}
]
}
This shows the default strategy for polling a signal hub and the print queue API. For both the signal hub and the print queue, the strategy contains a list of intervals. These intervals describe how long to use a specific timing before moving on to the next interval.
For example, let’s look at the following definition of an interval:
{ "Duration": 120, "LocalWait": 0, "RemoteWait": 10 }
This means that for 120 seconds, the strategy is to wait 0 (zero) seconds between each poll. Each poll to the API waits 10 seconds on the server-side before returning if nothing happens.
Because there is only one strategy named Default in the configuration above, the same configuration applies to all environments connected to this Direct Print service.
You can create specific polling strategies for each connected environment if needed. To do this, you add new strategy sections and name them after the service name.
{
"Version": 1,
"Environments":
[
{
"Name": "default",
"Strategy":
{
…
}
},
{
"Name": "SERVICE NAME 1",
"Strategy":
{
…
}
},
{
"Name": "SERVICE NAME 2",
"Strategy":
{
…
}
}
]
}
The strategy named default is the fallback strategy if no matching name is found.
It might be necessary to restart the Direct Print service in some versions after modifying the configuration.
