Where’s the Print Button? Options for Fiori App Printing

[chris_scott]

We have been helping organisations define and deliver custom SAP processes since 1997.  Our journey began with SAPGUI, then moved to Adobe Forms. From there we progressed to HTML forms, and for the last few years the focus has bene on SAPUI5 Fiori apps.  Our solutions encompass this spectrum of UI approaches.

Inevitably we have seen customers move from one approach to another.   As organisations move to S/4HANA, they replace many SAPGUI transactions with SAPUI5 Fiori apps.  We also see customers replace PDF or HTML eForms solutions with SAPUI5 apps.

Over the years we have strongly encouraged our customers to get the most from their investment in SAP by adopting the latest technologies, and sometimes it has been a struggle.

In various countries/industries/processes a wet signature has continued to be required.  In many organisations a ‘hard copy’ is required.

When people use eForms, they adopt a language – you ‘fill in’ (or fill out) a form; you ‘submit’ a form; you ‘approve’ a form; you ‘file’ a form.  And indeed, the major difference between a form and an SAPGUI transaction is that a form can be saved, emailed and printed.   So, when our customers move from an eForm solution to a Fiori app, they expect to deliver the same functionality.

So unavoidably we are asked ‘Where’s the print button’, and of course, in the Fiori UX universe, there isn’t one. Just like there isn’t one in SAPGIU.

The transition from SAPGUI to Fiori doesn’t bring the question, but it’s an irritatingly common question in the transition from forms processes to Fiori processes.

There are a number of approaches.

Let’s start with, and discount, the two methods, as both can lead to hideous results:

• Print Screen

Select ‘Print Screen’ and then paste the screen image into a Word document.

• Browser Print

Select ‘Print’ through the browser menu and then select a printer or print to PDF

There are three more sophisticated approaches:

• Maintain an Output Template

For this we would typically use SAP Interactive Forms by Adobe to build a template, and then push the data from the Fiori app into the template for PDF generation or printing.

There’s a benefit of using Stelo together with Varo or Floe for this purpose, because the data set is common, so no integration is required: The output can be generated with very little or no coding at all.

However, there is still the overhead of having to maintain both the app and the output form, which is fine if you want them to look very different, but a pain if you want them to look the same.

• Re-render the Fiori app for printing.

For this option we add need to add custom CSS to the Fiori app and the JavaScript to open a new browser page, passing in the same data model, but using a print-friendly style sheet.

The user can then use the Browser Printing options from the 2^nd browser tab.

This means additional development for each Fiori app, but no need for a separate output form or additional technology.

• Plug-in solution.

With this option a plug-in solution is called to render the PDF document (or PS file) from the Fiori app page, returning it to the user as a download, or sending directly to a printer.

This is the approach we now deliver using Renda.io, which includes the code you need to plug-in to your Fiori app in order to add the print button and call the service to turn your Fiori page into a printable PDF document.