Skip to Main Content

SAP, the Cloud, and the Urgency of Print

Four decades of work in the field of Output Management have taught us many lessons. For example, we hold the following truths to be self-evident:

  1. When implementing a high-profile business-critical application or infrastructure component, large customers often overlook the need to print from this new system.
  2. By the time stakeholders realize they have no way of printing, the lack of an output management solution becomes a very visible problem among the IT and management ranks.
  3. The flexibility and scalability of LRS software make it possible to address nearly any document-related challenge in a quick and sustainable manner.

A recent incident shows how we can promptly respond to last-minute requirements. Earlier this month, a large life sciences company contacted us, saying they had built a brand new and fully sanctioned solution involving SAP in the Cloud. The application used the SAP BTP Neo environment, but this customer had forgotten to plan for a way to print from the new system.

Normally when customers need to print from SAP Cloud environments, we suggest the use of SAP Print SaaS and our VPSX beta product for BTP-PRINT-OMS. This solution, described in my most recent Blog post, is the same as the S/4HC-ES-PRINT-OMS solution.

In this particular situation, the customer informed me that although use of the SAP BTP Neo environment was fully sanctioned, other SAP Cloud environments including SAP Print SaaS were not yet permitted. They needed a reliable, trusted print solution that could be deployed very quickly.

We offered them the Java IPP interface for VPSX, a custom Java library that would allow them to seamlessly integrate SAP printing with their existing on-premise VPSX installation. HP (our partner at the customer site) was able to quickly set up a test server for them as well. Sadly, they were unable to implement the required application changes in a timely manner (SAP Cloud Connector requires use of SOCK5 proxy when communicating with TCP Backends). So as an alternative, I offered them the option of using SMTP to our Mobile Connector product. After a small application change and some adjustments to the firewall, they managed to send an email with attachment to our server. Almost immediately, their printing problems were solved.

The benefits were impressive. First, this solution does not need Windows print drivers or spooling. Also, due to LRS’s expansive product portfolio, they eliminated the need for their application to generate print-ready data. VPSX software can output a variety of printer description languages (PDLs), including PDF, PCL, ZPL, PostScript, and more. Yet there were a few benefits they liked even better:

  • They did not have to build print-related error handling or spooling logic into their solution.
  • Their new SAP environment seamlessly integrated with their existing output management infrastructure, meaning no new “surprises” for the help desk to worry about.
  • They enjoyed a very quick implementation. (As usual, configuring the firewall was the hardest part.)
  • Per customer request, all print jobs are removed from the spool if and only if the target device confirms the document is printed in its entirety. This ensures one and only one copy of a document is printed.
  • Other “finishing” options, like Simplex/Duplex, are able to be passed as parameters with the email address.
  • There is only ONE firewall entry required (corresponding to our server). If they had printed directly, they would have needed firewall entries for every printer.

Result? The customer’s IT staff and end users are happy, and the application is slated for an on-time installation. Rajneesh and Zoran if you are reading this, thanks for calling us!