Introduction
Applied Data Consultants (ADC) created a software system that works with auto dealership management software to manage dispatch and delivery. We talked about our integration with the ADC software in this blog post. In the following, I'd like to describe how we used existing features in RPM Remote Print Manager® (RPM) without modification to investigate exactly what we needed to do to facilitate this integration with a new dealership management system and then deliver a working solution that was replicated at other sites.
Before I continue, I'd like to thank the parts manager at the dealership in Colorado Springs, CO. I don't have permission to disclose the name of the customer, but they were a delight to work with!
In this exercise, we were working directly with Imaging Technology Group (ITG), a company which provides integration services for ADC. ITG developed the tools to inject a print job directly into the ADC system. We have worked with ITG on a number of integration projects. We were also working with our RPM product, using it as a virtual printer which the remote vendor could connect to in a variety of ways. We then relied on RPM to route the job within the auto dealership as needed.
Setting up the initial test
Going into this integration we knew the following:
- the print jobs were originating from a remote system
- they go to a specific IP address within the dealers' network, which happened to be a large Lexmark printer with multiple trays and bins
My tasks were:
- discover how the remote vendor sent the print jobs to the local auto dealership
- configure RPM to route the print jobs to the local printer in the same way
- capture copies of the print jobs for analysis by ITG
I installed RPM at the dealership; then the parts manager called the vendor and had them change the IP address they sent the jobs to, from the workstation. In RPM we have an “auto-create queue” feature which is active by default. All LPD jobs include a queue name so I was hoping to learn how the job was sent since RPM would create a new queue at that moment. I planned to use the “LPR print” function in RPM to send the job to the Lexmark the same way it was sent to us.
He initiated a print request to the system, and we waited for the job to appear. Unfortunately, nothing happened right away.
Getting results
After several minutes we guessed that the vendor's software was printing to port 9100 at the IP address. I set up a telnet port for 9100, pointing to a queue I created. In the queue, I did two things:
- use the “IP print” action in RPM to send the job unmodified to the Lexmark printer
- archive a copy of the print jobs in a folder
Before long we had a steady stream of parts-related print jobs archiving in a folder and printing as expected.
Our pre-arranged plan with ITG was to let a month's worth of jobs accumulate so we could be sure we have samples of all the data formats the dealership is likely to receive. This makes sense if you think in terms of weekly or monthly reports; you don't want to dispatch on those. Once ITG identified how they wanted to pre-process the files, they provided us with the software necessary for that step as well as the means to securely submit the result data to ADC. We added a third action to the “IP print” and archive, which was to run a script that contained the steps ITG outlined for us.
After several months of running this process successfully, we turned off the archive action as it was no longer necessary to save a backup of the files.
Conclusion
Since this initial setup, ADC and ITG have installed their system with our RPM software at many other auto dealerships throughout the US. We are proud to work alongside such innovative technology firms as these and help them facilitate a highly desirable service for their customers.
Looking at RPM as a print server you could say it has a “bunch of features” but as a virtual printer, it is a toolbox full of ways to connect from remote systems and route print jobs creatively within the customer network.