The OrderFlow Print Server serves two purposes.
Its primary purpose is for document printing. The Print Server is optimised for printing of shipment batches, allowing large numbers of documents to be printed with little or no user intervention.
For document printing, a typical configuration will involve one instance of the Print Server for each site connecting to an OrderFlow system. However, it is possible to use multiple Print Server instances for this purpose, if volumes dictate.
The other main use for the Print Server is for integrating with third party courier label printing systems. Examples include:
- UPS Worldship
- DPD Ship@ease
- Yodel DeskDispatch
These systems are all desktop applications which run on Microsoft Windows. They interface directly with label printers on the warehouse floor. They are typically not internet enabled, but instead data is shared with these systems by writing files to and reading files from the local file system.
As the Print Server is also installed on the local network, it is able to communicate with these systems on OrderFlow's behalf, typically to trigger printing of shipment labels and to capture tracking references.
Concepts and Architecture
As mentioned earlier, OrderFlow does not print directly to printers on a local network. Instead, printing is either accomplished via Java applets, or through the use of Print Servers.
A key concept that is used in OrderFlow printing is the print queue. When a printable document, or print item, is created on OrderFlow, it is published to a print queue. The document will be retrieved from the print queue, either via the applet or by a Print Server, and then printed to a local printer.
Print queues are associated with printable items in a number of ways. See the Orderflow Configuration section for more details on how this is done.
Print Servers are well suited to high volume printing environments in that they support a flexible scheme for distributing high volume printing among multiple printers. The Print Server also supports offline download of print jobs, which themselves can be generated automatically via scheduled jobs.
The architecture for the Print Server is shown in the diagram below.
In the architecture diagram above, two Print Server instances, possibly on two local area networks, are connecting to a single OrderFlow instance.
- Print Server 1 connects to Printer 1 and Printer 2.
- Print Server 2 connects to Printer A and Printer B.
OrderFlow (typically) does not maintain a direct mapping to printers. Instead it publishes print jobs onto queues. Print Servers monitor these queues, and can map these queues to specific printers. In our example above, four print queues are used.
Note that every print item that OrderFlow generates is associated with a logical print queue. By convention:
- documents which are designated for printing via Java applets are sent to the queue
- documents which are designated for direct PDF printing are sent to the queue
- documents sent to other queues are typically consumed by Print Server instances.
The identification of a particular print queue can be done in a number of ways:
- for print jobs involving shipment batches printed on a centrally located printer in the warehouse, the shipment batch type will typically be associated with a print queue.
- for printing of shipment documents directly to workstations (e.g. packing desks), the print queue may be set up through an OrderFlow Workstation property.
Normally, in a single site environment, each OrderFlow print queue should only be monitored by a single Print Server instance. If multiple Print Servers are downloading jobs from the same queue, it can lead to some confusion, as the destination of individual print jobs is not easy to predict.
The Print Server is distributed as a self-contained Java application via a zip file.
A copy of the Print Server installation file can be obtain on request from Realtime Despatch technical support. For customers, it is also available from the Published Documents page on the support portal.
The installation steps involved as as follows.
- download and unzip the zip file
- copy the config directory
- test running the application
However, before beginning, it is worth installing (or verifying the installation of) the prerequisite software.
The Print Server recommends the following software to be installed on the host computer.
- Microsoft Windows
- Team Viewer
Our typical customer uses a Windows workstation hosted in the warehouse environment as a Print Server host. While we will support or even encourage the use of Linux as a Print Server host operating system, this document only covers the setup of the Print Server on Windows.
We do not mandate a particular version of Windows, except to say that it needs to support the running of Java below.
Note that the workstation used must have network access to the OrderFlow server, potentially hosted offsite.
You will need to be able to run applications, as administrator in some environments, depending on local network security policies.
The Applet Printing section contains some detail on downloading and installing Java. The Print Server also runs on Java, although as a server, rather than simply as a browser-embedded plugin.
We recommend that the latest available version of Java be used at the time of setup. Our commitment is to ensure that the Print Server will always run on the latest available version of Java. However, the Java version on which the Print Server runs typically does not need to be upgraded after install, except when requested by OrderFlow technical support.
Java can be downloaded from the Java web site.
TeamViewer software is used by Realtime Despatch for remote desktop access when supporting the Print Server. TeamViewer allows OrderFlow technical support staff to gain access to the Print Server environment to check configurations, diagnose issues and perform other support tasks when required.
As configuration of the Print Server involves modifying text files, we recommend that you install a text editor that works nicely with the Print Server configuration files.
An example is NotePad++.
Download and Setup
Download print service, and unzip it into C:/RealtimeDespatch, as shown below. The use of the C:/RealtimeDespatch folder for hosting the Print Server is not required, but is recommended as a convention which makes it slightly easier for us to support your Print Server environment.
Once you've unzipped the zip file into C:/RealtimeDespatch, copy the config directory contained within the printservice-xxxxx-jetty, and paste it into C:/RealtimeDespatch, as shown in the diagram below.
The reason for the above step, which only applies for the initial install, is so that subsequent upgrades of the Print Server can reuse the previously set values in the config directory. The config directory contains the main configuration files used to customise the Print Server. Basic instructions on configuration changes suggested for these files follow in the next section.
Once the directory structure has been set up, it is a good idea to set up a shortcut.
Simply right click on the file startup.bat, and click 'Create shortcut'. Copy the shortcut to the desktop, to make it easier to launch the application, as shown below.
Optional steps once the shortcut has been created are to rename the shortcut, or to modify the shortcut icon. Once the shortcut has been placed on the desktop, the application can be launched by double clicking on the shortcut icon.
Before starting up the Print Server, you will need to set the value for the configuration parameters, in order to connect successfully for OrderFlow, to monitor the correct print queues, and to set the necessary print queue to printer mappings.
Note also you will need to restart the Print Server
Note that configuration parameters that are commented-out (i.e. those that have a '#' at the beginning of the line) will take the default value built into the Print Server application.
#The site identifier for the site/warehouse in which this print service is based. #Corresponds with the appropriate site identifier on orderflow fetch.site=DEFAULT #The friendly name for the Print Server, used to help identify the source of jobs fetch.friendly.name=PRINT1 #The base URL, user and password of the OrderFlow instance fetch.base.url=http://localhost:8081/web/remoteprint/ fetch.user=print fetch.password=print
fetch.site is the OrderFlow site. If connecting from more than one site to a single OrderFlow instance, different
Print Servers will have different values for
fetch.friendly.name helps to identify the print server in a user-friendly way.
fetch.password are fairly self-explanatory. They need to be
set correctly in order to connect successfully to OrderFlow.
This configuration file is used to set the print queues to monitor on OrderFlow, and the mapping from logical print queue to printer.
#The comma separated list of queues which this Print Server is interested in for direct printing or downloading print.queues=LABEL11,DOC11 #The mapping from queue name to printer name. The right hand side of the first equals sign #contains a comma separated set of pairs of queues to printers print.queue.printers=LABEL11=ZDesigner GK420d,DOC11=A4 Laser
Note that the in the example above, the Print Server has been set up to poll the OrderFlow print queues LABEL11 and DOC11. The documents published onto LABEL11 are then routed to the printer ZDesigner GK420d, and those published onto DOC11 are routed onto A4 Laser.
Note that you can also use the special value DEFAULT as a printer name, which will route documents to the default printer on that workstation as per the Windows setup.
The above example would also work if the ZDesigner GK420d printer is also the default Windows printer.
Print Server monitors print queues in the background.
scheduler.poll.interval property is used to control the polling interval.
scheduler.poll.delay is used to control the delay after startup.
This file contains Java system properties that may need to be loaded at startup. The main entry of interest here is the line below:
The above line contains a reference to the module definitions file which controls which Print Server module are loaded at startup.
If a non-standard module configuration needs to be applied, this will normally be done with additional instructions provided by a member of the Realtime Despatch support team.
Running the Application
As described earlier, the Print Server can be started simply by double clicking on the shortcut icon
On startup, the Print Server will:
- connect to the configured OrderFlow instance, and register itself with with OrderFlow
- download resources, especially label icons and logo images, for use locally in print jobs
- initiate a schedule to poll for print jobs
A terminal window will be visible if once the application is running.
Once started, the Print Server will be ready to download and print jobs to local printers, and to perform other integration tasks on the local network.
Typically, the Print Server is started on port 8181, so you can navigate to the Print Server by pointing your browser to the following address: http://localhost:8181/web/. (To change the port on which the Print Server runs, edit the startup.bat file referenced by the shortcut).
The next couple of sections describe how to verify the Print Server installation, using features available both on the Print Server and OrderFlow.
Verifying on the Print Server
As well as supporting printing operations, the Print Server user interface includes a number of support screens which can be used to verify the configuration and setup.
- the fonts installed on the Print Server
- the image resources downloaded from OrderFlow
The screen below shows the Print Server configuration, which is essentially a visual representation of the configuration values loaded from the config directory.
Verifying on OrderFlow
We can also verify on OrderFlow that a Print Server instance has successfully connected, from the Reports -> Print Items - Print Servers menu.
Note that each Print Server which connects to OrderFlow periodically sends a heartbeat message. The page above shows the Print Server instances connecting to the current server, the print queues being monitored, and when the last heartbeat message was received.
In the example above, the print queue DEFAULT is being polled by the Print Server with the 'friendly' name PRINT1, with the last heartbeat message received six seconds ago.
Testing the Print Queue
Once the above test has been successfully performed, you can test printing to the print queue from the Setup -> Print Queues menu.
First, navigate to the print queue you wish to test. The select a resource, and site. Note that the site needs to be the site to which the Print Server is connecting. In a multi site environment, you will need to make the correct choice there.
After clicking on the 'Test' button, you will see output as shown above.
On the Print Server workstation, you should see your document print if the configuration is correct there too. You should also be able to inspect the console output shown on the print server, and see output such as the following.
2016-06-23 14:34:41,684 INFO [MultiStatusBatchFetchingPrintManager] Received 1 jobs from reader 2016-06-23 14:34:41,684 INFO [MultiStatusBatchFetchingPrintManager] Printing job 114-test_a4.xml 2016-06-23 14:34:41,684 INFO [BaseBatchFetchingPrintfileWriter] Printing job 114-test_a4.xml using printer: DEFAULT 2016-06-23 14:34:41,709 INFO [DownloadingPrintDetailSource] Time taken to download print item '114': 23 milliseconds 2016-06-23 14:34:43,510 INFO [BaseBatchFetchingPrintfileWriter] Update print status to 'sent' for 114 via resource updatePrintStatus.xml
Upgrading the Print Server
Occasionally an upgrade to the Print Server will be required, to take advantage of new features and bug fixes.
The steps involved for performing an upgrade are as follows.
- Stop the existing Print Server by closing the terminal window in which it is running.
- Download the more recent release of the Print Server, and unzip it into C:/RealtimeDespatch as for the initial install.
- Delete the existing shortcut icon from the desktop, and replace it with a new shortcut icon which points to the startup.bat file in the newly unzipped printservice-XXXXX-jetty directory.
- Double click on the new shortcut icon to restart the application.
The screenshot below shows an example how the directory structure will appear after the upgrade.
Note that there is no need to copy the config directory after the upgrade. The application will continue to use the config settings in the directory under C:/RealtimeDespatch. In other words, existing settings will be preserved.