Oracle released a new release of the E-Business Suite last week (on April 23, to be more exact). While so far there are no official announcements in the Oracle Blog, the My Oracle Support Note describing Cloud manager (2517025.1) gives an overview of the new features – so let’s have a closer (first) look at the new release.

Support for automatic time zone setting

In the past every E-Business Suite instance provisioned through Cloud Manager was set up with an “UTC” timezone. For many customers, this did not work well obviously. So far the workaround we used with our customers was to manually run the following command:

timedatectl set-timezone Europe/Berlin on every newly provisioned (e.g restored from a backup) instance. With the latest release this is no longer necessary: The “backup utility” saves the timezone set up in the source system and then during restore, this timezone is automatically preserved:

Support for Environment Rediscovery after 12.2 upgrades

The second new feature is even more important. When previously performing an upgrade from E-Business Suite 12.1.3 to the latest 12.2.10 version the Cloud Manager kind of “lost track” of the E-Business Suite instance it is managing: The tool is still under the impression, that it is managing a 12.1.3 version of E-Business Suite residing in different directories. When then trying to e.g. “scale out” (add a second node) or create a backup or clone of the instance, the operation was failing with all kinds of errors.

This is now fixed with the 20.2.1.1 release of Cloud Manager and it is now possible to rediscover the environment after an upgrade.

In the past we had worked around this by performing a manual backup with the “lift and shift” utility and then restoring it as a new environment. This workaround though has a significant drawback by adding appx. 6-8 hours (depending on the size of the environment) to the downtime needed for the upgrade from 12.1.3 to 12.2.

Summary

Besides the new major features as usual a bunch of smaller bugs have been fixed. And more important: At least for the two customers where we have already given the release a try no new regressions came up and basic backup/restore or cloning operations are still working as expected without any problems.

A customer recently told me they would like to get away from having to print, envelope and post mark thousands of invoices manually every month. Even though we have changed their invoicing process to an electronic one for most of their customers years ago by sending out emails through Oracle SOA Suite, they still had a considerable amount of customers insisting on printed invoices delivered by post.

Let’s have a look at how we managed to get away with that paper.

Starting Point

The customer was producing his invoices using the Oracle ERP System Oracle E-Business Suite (EBS) running on OCI. For electronic invoices, EBS has for a long time passed on the invoice and eventually some more additional attachments further detailing the invoices to Oracle SOA Suite 12.2.1.4. Then an integration layer running on SOA Suite delivered the invoices to the customer by sending (in most cases) an email with one or multiple (PDF) attachments.

Customers not opting in for this electronic process got their invoice printed through a traditional E-business Suite concurrent program on a printer at the customer premises. From there, the invoice was eventually enriched with the necessary attachments, then put in an envelope and sent to the customer by post.

Docuguide

Since the process of sending, printing, enveloping and post marking paper is both a lot of work and expensive, the customer thought of outsourcing this task to Deutsche Post and its service docuguide/E-Post. They offer to print, put in an envelope and deliver/postmark a letter with a single page at 0,65€ which is far below the price for the stamp alone (0,80€).

The data can be transmitted to docuguide over various interfaces, e.g. by a special printer driver, but also using (s)ftp upload or a modern web service API (https://api.epost.docuguide.com/swagger/index.html#/Letter/LETTER_POST).

Implementation

The basic implementation was quite trivial: I modified the E-business Suite process to not only pass electronic invoices over to SOA Suite, but instead to pass everything along. Furthermore, we deactivated the printing of the invoices in EBS itself.

In the SOA Suite process, we then performed a simple “if” to send invoices that need to be delivered physically to docuguide. This can be done by using either the REST Web Service or the SFTP Adapter. Since Docuguide confirmed the traditional SFTP channel to be more flexible for now, we applied this approach for the time being:

Attachment challenges

As mentioned earlier, we had cases where not only a single invoice had to be delivered to the customer but instead we had to add 1 or even multiple additional documents to the letter. In the electronic case, this was trivial since we simply attached multiple documents (PDF) to the Email.

However, with the Deutsche Post interfaces we had to merge all these documents into a single, combined PDF. SOA Suite unfortunately does not provide any out of the box functionality to merge PDFs. Using a Java Embedding and one of many libraries to merge PDFs using Java Source Code, this can be achieved easily with the following steps:

1. Load the appropriate PDF merging library (.jar files) into WEB-INF/lib of the soa composite sending the invoices:
2. Implement a Java embedding Activity in the BPEL process similar as the following :

Integer numsI = ( Integer) getVariableData( “numAttachs”);

int num = numsI.intValue();

java.io.ByteArrayOutputStream bos = new java.io.ByteArrayOutputStream();

org.apache.pdfbox.multipdf.PDFMergerUtility PDFmerger = new org.apache.pdfbox.multipdf.PDFMergerUtility();

PDFmerger.setDestinationStream( bos);

 

for ( int i = 1; i <= num; i++) {

oracle.xml.parser.v2.XMLElement xmle = ( oracle.xml.parser.v2.XMLElement) getVariableData(

“Read_Attachment_OutputVariable”, “XxArDigitalInvoicesDocVCollection”,

“//ns10:XxArDigitalInvoicesDocV[” + i + “]/ns10:fileData”);

String nextBase64 = xmle.getTextContent().replace( “\n”, “”).replace( “\r”, “”);

java.io.InputStream is1 = new java.io.ByteArrayInputStream(

java.util.Base64.getDecoder().decode( nextBase64));

PDFmerger.addSource( is1);

}

 

PDFmerger.mergeDocuments( org.apache.pdfbox.io.MemoryUsageSetting.setupMainMemoryOnly());

String result = java.util.Base64.getEncoder().encodeToString( bos.toByteArray());

setVariableData( “base64_out”, result);

This combines all the PDFs to be sent to one customer into a single pdf that can then be sent to docuguide for delivery to the customer.

We used the https://pdfbox.apache.org/download.cgi library because it is under the Apache License 2, which is quite permissive also in a commercial environment. Be aware e.g. of libraries under GPL or even AGPL depending on your environment (e.g. itext).

Summary

The above procedure allowed us to replace a manual, expensive and error prone process (the number of pages per invoice varies making it difficult to correctly put the matching pages into an envelope) with a more convenient and way cheaper process within days. Especially, the flexibility of SOA Suite in combination with the powerful document printing means of Oracle E-Business Suite helped to implement a way better solution than the customer was running before.