Part 2: Merging Reports using the Archive Merging Utility

In the first part of this series, we discussed how to merge reports using subreports.  Today we are going to take a look at another method: Merging Archives.

Generating a report as an archive file is a great way to save a snapshot of that report to file for later use. The resulting file, when viewed, is an exact replica of the original report output when it was generated without the need for data or report manipulation.

The simplicity of archive files make them the perfect starting point for the next part in our series of merging reports. With the use of the built-in Archive Merging Utility, merging multiple archive files into a single file is an almost trivial task.

Whether numerous archive files are already saved to file or database or multiple reports require quick merging without redesign or further code, merging archives is a handy tool to have in your merging arsenal.

See the following article for how to utilize the Archive Merging Utility (TppRAFMerge class) to easily merge multiple archives into one.

https://rbwiki.digital-metaphors.com/output/archive/merging-archive-files/

Pros:
– Archive files are easy to generate and are proven to contain correct output.
– Archive files print/export quickly due to zero overhead and merging requires minimal code.
– Once merged, exporting an archive to different file formats is simple using existing RB architecture.

Cons:
– Creating archive files adds a new step when another file format is needed.
– Archive files are not “live” reports
– Editing archive files once created can be time consuming

Merging archives is yet another useful way to combine separate reports into a single document. While this method really shines when archive files have already been created, it can also be used to simply merge reports even when archive files are not ultimately needed.

The next post in our series (Merging Files) is coming soon, stay tuned.

Happy Reporting!

In the reporting world, efficiency is key. Whether you’re a developer, designer, or end-user, the ability to merge multiple reports into a cohesive whole is a skill you’ll want in your arsenal.

Imagine this scenario: You’ve meticulously crafted individual ReportBuilder reports, including data, event code, calculations, etc. — but now you need to present a unified result. Perhaps you’re compiling a comprehensive report, combining contracts, or assembling a collaborative project. Whatever the reason, merging documents streamlines information, reduces clutter, and ensures a seamless reading experience.

Merging multiple reports into a single document either on screen or exported to file is a very useful and often asked for feature. ReportBuilder natively provides numerous ways to merge reports and this series of posts will address each one.

Part 1: Merging Reports With Subreports

Subreports are a fast and easy way to merge multiple reports with ReportBuilder. Subreports themselves are essentially full featured reports that can be embedded into a main report.

Start with an empty “container” report with a detail band only. Add a subreport component for each report you wish to merge. Each subreport will contain an individual report that is loaded from a template file or created manually. The use of Child or Section subreports will determine whether there is a page break between merged reports.

See the following article and example below for how subreports can be used to merge two (or more) reports.

https://rbWiki.digital-metaphors.com/design/layout-design/merge-reports-with-subreports

Pros:

1. Subreports are simple to use and provide visual design options.
2. Saving and loading report templates is quick and straight forward.
3. Reports are merged in the preview as well as when exported or printed.

Cons:

1. Not all report features are available in subreports.
2. All data, calculations, and event code must be present and valid before merging.
3. Sometimes all that’s needed is a simple merged file.

As you can see, using subreports to merge reports is a very simple an useful method and should be considered for every merging scenario.

Stay tuned for more merging tips and tricks in our upcoming blog series and in the mean time,

Happy Reporting!

Below are a couple examples of some helper routines that you may find useful.

1. Web Mail and Cloud Drive service helpers:

Setting up web mail and cloud drive services can be time consuming due to the fact that many of the necessary properties are embedded in numerous sub-classes. For instance, in order to set up Gmail using standard RB properties, the following code is needed:

ppReport.EmailSettings.ConnectionSettings.WebMail.GmailSettings.OAuth2.ClientID := ClientID;
ppReport.EmailSettings.ConnectionSettings.WebMail.GmailSettings.OAuth2.ClientSecret := ClientSecret;
ppReport.EmailSettings.ConnectionSettings.WebMail.GmailSettings.OAuth2.RedirectURI := RedirectURI;

The same would be needed to set up another web mail plugin such as Outlook.com.

With the included WebMailSetup routine, both plugins can be set up with the following code:

// Redirect URI is optional (defaults to http://localhost)
ppReport.EmailSettings.ConnectionSettings.WebMailSetup(ctGmail, ClientID, ClientSecret);
ppReport.EmailSettings.ConnectionSettings.WebMailSetup(ctOutlookWeb, ClientID, ClientSecret);

A similar helper is provided for cloud drive services.

//Set up all three supported cloud drive services
ppReport.CloudDriveSettings.CloudDriveSetup(ctGoogleDrive, ClientID, ClientSecret);
ppReport.CloudDriveSettings.CloudDriveSetup(ctOneDrive, ClientID, ClientSecret);
ppReport.CloudDriveSettings.CloudDriveSetup(ctDropBox, ClientID, ClientSecret, 'http://localhost:54321');

2. Export to file from the Viewer:

When using a TppViewer on a form to view reports, it is commonly necessary to export that report to file directly. This can be troublesome due to the fact that the Viewer itself is connected to an output device (screen). Normally, one would need to manually disconnect the screen device from the report before exporting and reconnect it after exporting has finished. The ExportToFile routine makes this process much easier.

ppViewer.ExportToFile(dtPDF, FilePath + '\Invoice.pdf');

Hopefully this gives you a bit more information on some helpful helper routines that have been added to ReportBuilder. If you find this information useful, let me know and I can make this a series of the various other helpers available. Also, if you would like to see other helper routines added, let me know that as well and we will consider adding them for the next release.

Happy Reporting!

ReportBuilder 22 introduced a number of features to make the life of a report developer easier. One of those features is the ability to easily create an EPC compliant QR Code for making payments in many European countries.

While it was possible to create an EPC QR Code in earlier versions of ReportBuilder, RB 22 added specific objects and dialogs to simplify the process.

See the following article for more information and a simple example.

https://rbwiki.digital-metaphors.com/rcl/barcode/epc-qr-codes/

Happy Reporting!

Have you ever needed to be sure a document sent is the one being read? We all know that the Internet is a dangerous place for unprotected data. Transferring any un-encrypted data is fair game to be intercepted, stolen, or altered. Digital Signatures are an excellent way to avoid some of these problems.

Digital Signatures offer a highly secure way to ensure a document or file has not been altered or tampered with after it has been created. The basis for a digital signature is the Digital Certificate. A Digital Certificate is generally a file created manually using encryption software such as OpenSSL or Microsoft IIS, or provided by a certificate authority such as Verisign(https://www.verisign.com/) or Digicert (https://www.digicert.com/). This file contains encrypted information identifying the signer in a specific way. It can be an encrypted representation of the signer’s actual signature, or simply their name and address just as long as it’s encrypted and in the proper format.

Using this Digital Certificate, a file hash is created, encrypted, and stored with the original file along with the certificate itself. When the file is later opened, the verification software will create its own hash based on the stored certificate and compare it to the hash stored with the signed file. If the hashes match, one can be sure the file has not been altered since it was “signed”.

In past versions of ReportBuilder, it has been possible to add Signature form fields to PDF files before exporting. These Signature fields allow users to digitally sign their PDF documents from within a PDF viewer such as Adobe Acrobat. Now with the introduction of ReportBuilder 21, it is possible to skip the Adobe step and sign a PDF file directly with ReportBuilder.

ReportBuilder 21 utilizes the OpenSSL library to open and process the Digital Certificate file. While ReportBuilder includes the latest build of the OpenSSL library with its installation, it is highly recommended that you download* your own version to ensure the highest security. The Indy Project provides new builds daily at the following location: https://indy.fulgan.com/SSL/.

See the following article and example for more information about this powerful feature of ReportBuilder!

http://rbwiki.digital-metaphors.com/output/pdf/how-to-digitally-sign-a-pdf/

* A note about Indy OpenSSL binaries.

The currently supported version of OpenSSL by Indy (for Delphi) is 1.0.2. This version is no longer supported by the OpenSSL Organization but is maintained by the Indy Project. The actual latest stable version of OpenSSL is 1.1.1 (until September 2023). It is possible to download this version from the Indy site under /Archive/Experimental/. Do not be deterred by the “Experimental” label, it simply implies that those versions of OpenSSL are not yet fully tested for use with Indy. While the older versions of OpenSSL are still updated with the latest bug-fixes and will function with ReportBuilder, it is strongly recommended that you download and use the latest supported version.

For more information about OpenSSL versioning, see the following web page: https://www.openssl.org/source/

Happy Reporting!

ReportBuilder has supported sending emails from within the product since version 10. This was done by registering a single Email Plugin, each of which supported a different email-sending technology. Initially it was possible to either send the email directly by connecting to a SMTP server or transfer the email (with report file attached) to the email client (Outlook) installed on the user’s machine and send from there. These plugins are called “SMTP Plugins” because they either directly or indirectly interact with the user’s SMTP server to send the message. Due to the nature of these sending techniques the restriction of only registering a single email plugin at a time was appropriate.

With the introduction of the Web Mail Plugins for version 18, it became clear that the ability to register multiple email plugins at once would be useful. This is why we decided to re-design the Email Plugin architecture for ReportBuilder 21 to make it possible.

The new feature allows multiple Web Mail plugins and a single SMTP plugin to be registered simultaneously giving the user the option to select the email service they would like to use. When multiple email plugins are registered, a handy drop-down menu is enabled making the selection process even easier. It’s also possible to select the email plugin in code using the EmailSettings.ConnectionSettings.MailService property.

Please see the following RBWiki article and demo for more information and instruction on how to utilize this new feature.

http://rbwiki.digital-metaphors.com/output/email/how-to-multiple-email-plugins/

Happy Reporting!

I was recently asked if the ReportBuilder Indy email plugin supports TLS version 1.2. The answer depended on whether Indy supports TLS 1.2, which thankfully it does! Many email providers (i.e. Gmail and Outlook) are now requiring the use of this version to connect to their SMTP servers. After researching a bit, I found that while Indy does support the use of TLS 1.2, it is not the default. Below are my findings and some sample code get this working with the current version of ReportBuilder (21.01).

When connecting directly to a secure SMPT server with the ReportBuilder Indy email plugin, it is necessary to set the EmailSettings.ConnectionSettings.UseTLS property to True. It is also necessary for the latest OpenSSL .dll files to be accessible to the application executable. (See the UseTLS topic in the installed RB help for more information).

With UseTLS set to True, an IOHandler is automatically created to make the secure connection to the server using OpenSSL. Problems can arise with newer servers as Indy uses TLS 1.0 as its default security protocol. To change this in ReportBuilder, you can use the Report.BeforePrint event to access the TidSMTP object in code.

uses
ppSMTPIndy10, ppEmail, IdSSLOpenSSL, IdSMTP;

...

procedure TForm1.ppReport1BeforePrint(Sender: TObject);
var
  lEmail: TppEmail;
  lSMTP: TIdSMTP;
begin

  lEmail := TppEmail(ppReport1.Email);
  lSMTP := TppSMTPIndy(lEmail.SMTP).IndySMTP;

  TIdSSLIOHandlerSocketOpenSSL(lSMTP.IOHandler).SSLOptions.Method := sslvTLSv1_2;

end;

Note: For now, the BeforePrint event works because it fires after the SMTP plugin is setup but before it attempts to connect to the server. For a future release of ReportBuilder, I believe a new event should be added to the plugin that fires before the connection is made which would allow logical separation of email related code and report event code.

Another option is to create your own IO handler and assign its SSL options. For this option to function, the UseTLS property must be set to False as the developer is taking care of creating the IO handler manually.

uses
ppSMTPIndy10, ppEmail, IdSSLOpenSSL, IdExplicitTLSClientServerBase;

...

var
  lEmail: TppEmail;
  lSMTP: TidSMTP;
  lIOHandler: TIdSSLIOHandlerSocketOpenSSL;
begin

  ppReport1.EmailSettings.ConnectionSettings.Port := 587;
  ppReport1.EmailSettings.ConnectionSettings.UseTLS := False;

  lEmail := TppEmail(ppReport1.Email);
  lSMTP := TppSMTPIndy(lEmail.SMTP).IndySMTP;

  lIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(lSMTP);

  try
    lIOHandler.SSLOptions.Method := sslvTLSv1_2;

    lSMTP.IOHandler := lIOHandler;
    lSMTP.UseTLS := utUseExplicitTLS;

    ppReport1.SendMail;

  finally
    lIOHandler.Free;
  end;

end;

Hopefully this gives you a better idea how to enable TLS 1.2 for the ReportBuilder Indy email plugin.  The main take-away here is that the underlying Indy TidSMTP object is easily accessible from ReportBuilder allowing for complete customization. For more information about customizing Indy from ReportBuilder, see the following Wiki article.

Happy Reporting!

How To…Customize Indy Email Settings

The ReportBuilder REST Services components provide a RESTful platform to publish RB reports to mobile iOS and Andriod clients.  Extending your existing Delphi desktop solutions via REST services is a great way to provide users with the mobile cloud access they expect.

As a desktop developer,  you may be thinking you lack the skills and/or time to implement such a solution.  The goal of the RB REST Services solution is to leverage Delphi and RB to provide a RAD (almost no code) way to enter the mobile realm.  Let’s go over a few key details.

Background
All ReportBuilder reports are created using our VCL designer.  Generally RB applications store reports as “template” or “archive” files which are loaded as needed.  The report definitions or archived reports can be stored to file, database or Delphi forms/datamodules.

RB REST services provides an easy way to view and print these same reports using FMX components on multiple platforms.  We did this by creating a VCL REST server which takes care of generating the reports, then sending them via HTTP to our FMX client for viewing/printing.

Tutorials
This might sound complex but the good news is that we already did all the heavy lifting.  If you have a bunch of saved reports in a directory or DB, you can be up and running in a matter of minutes!

1.  Create a server: Creating a server can be done in as little as 4 easy steps (with only 2 lines of code).  See the following article for more information about creating a ReportBuilder REST Server and a simple tutorial.  The finished tutorial is installed with ReportBuilder in the demos directory.

REST Server

2. Create a client: We provide three useful FMX components to make building a client as easy as possible.  These components allow for the creation of a phone, tablet, or desktop explorer/viewer with minimal code and setup.  They are also completely customizable which gives you the ability to tailor its look and feel to match your existing app.  The following link gives an overview of the components used along with simple tutorials on creating a phone or tablet client application.  Same as the server, the finished tutorial is installed with ReportBuilder in the demos directory.

REST Client (FMX)

Implementing RB REST services is extremely simple and provides a powerful way to display and print your reports from multiple platforms.  I hope this post along with the tutorials provide a starting point for creating your own mobile reporting applications.  Happy reporting!

PDF/A is a very useful and popular format used for the long term archiving of digital documents. ReportBuilder 19 introduces numerous PDF/A related features including support for the PDF/A-2, PDF/A-3, and PDF/A-3 ZUGFeRD formats (PDF/A-1 format has been available since RB 14).

PDF/A is highly restrictive in the features it allows and information it requires. One aspect of the PDF/A format that differentiates it from standard PDF is the required metadata that must be embedded into the file describing various aspects of the document itself. This metadata is formatted as XML and can contain any number of custom entries. As new PDF/A formats have been added to ReportBuilder, the necessity to customize this metadata has become increasingly important, especially for the PDF/A-3 ZUGFeRD format which is quickly becoming a standard for Eurozone invoices.  For more information about the PDF/A format, see the following Wikipedia article:  https://en.wikipedia.org/wiki/PDF/A

Starting with ReportBuilder 19.01, it is possible to customize the default metadata using the newly added TppPDFDevice.OnGetPDFMetadata event. The OnGetPDFMetadata event fires after the default metadata has been generated but before it has been written to the final PDF file. A copy of the default metadata is passed as a parameter of the event which can be altered manually or by using the Delphi XML classes. This gives developers complete control over the contents of the metadata portion of the PDF/A file.

See the following article for a detailed description and example of using this new event to alter the default metadata of a PDF/A document.

http://rbwiki.digital-metaphors.com/output/pdf/how-to-customize-pdfa-metadata/