APEX Office Print 101: Oracle APEX Document Printing

This is the beginning of a series of entries that revolve around APEX Office Print and its integration with Oracle APEX.

A usual requirement from the clients with whom I have worked, and that have applications in Oracle APEX, is to be able to print their data, reports, and forms quickly, with options for multiple formats and types of documents. Every Oracle APEX consultant has faced this issue at least once in his career, which can cause headaches since there are not many ways to do this out of the box, and the customization options are quite limited.

The decision to create Printer Friendly pages (an option that many of us considered when we were working with previous APEX versions like 3.x and 4.x) causes a huge technological debt, leaving the application at the mercy of each browser particularities and any change that the theme and templates assigned to the application may suffer in the future.

Several external solutions can help solve this problem, including BI Publisher, PL / PDF, and AOP, the latter being the one we will be checking in this post.

Presenting, APEX Office Print

AOP allows you to generate documents and reports with a highly customized format, based on templates that are sent along with the information to be included in the final document in JSON format. Such templates can be intended for Word, Excel, PDF, PowerPoint, or HTML.

Its architecture is based on a web server with the ability to scale itself depending on the number of available cores, waiting for requests that come with a JSON payload. This server can be used for both local deployments and the Cloud, and it has REST and PL / SQL APIs, as well as an Oracle APEX plugin that allows for a quick integration of the app reports with the tool.


AOP Architecture
APEX Office Print Architecture (Source: http://apexofficeprint.com/docs/)


AOP is a template-based tool, and those templates can be created in any editor and uploaded to the application files to be invoked by the plugin. The tool supports templates for multiple formats and handles different tags to define the location and manipulation of the data that is being sent to the server.

Thanks to the integration with APEX that I mentioned previously, we find several use cases:

  • Direct printing of reports and interactive grids from APEX, by simply indicating in the plugin the ID assigned to each one of them. Those are also referenced in the template with the corresponding tags, to be formatted and printed accordingly.
  • Document printing with a query from APEX, which is supported by the plugin itself. In its options, you can define a query that will be executed to extract the information to be sent to the server. This query requires a certain format so it can be interpreted and converted to JSON, but its content can be adapted to what we require in order to fill our template.
  • Document printing from the database, which can be used when more complex logic and processing is required before or in tandem with the tool. This is a more advanced option that gives total control over server calls using the PL / SQL API.

APEX Office Print Costs

You can often hear that if something is good and pretty, it cannot be cheap. Fortunately, the AOP team offers a free cloud plan for those who want to experiment with the tool. Of course, this plan has its limitations, but it serves as a perfect start for those who are evaluating how to update and improve the printing options of their applications. The cloud plans available as of February 24th, 2020 are:


AOP Cloud Plans
APEX Office Print Cloud plans (Source: http://apexofficeprint.com/)

You can see that for each plan they provide a monthly quota for the regular reports, with an unlimited number of reports in developer mode, which is included since AOP 19.1 and allows calls to be made to the Cloud server without the main credits being affected. This is perfect for testing new developments. Please note that the documents created in developer mode will include a watermark at the time of being generated, which is a common practice when dealing with these test modes.

To close this introductory post to the world of AOP, I’ll leave some links that may be helpful if you’re planning to do an initial approach to the tool:

In future entries, we will be checking some of the options that AOP provides and its use with specific cases.

See you next time!

Leave a Reply

Your email address will not be published. Required fields are marked *