Posted On: September 15, 2020

Custom WebADI Integrators Part I: Simplify Oracle R12 Financials AP 3rd Party Interfaces

For too long, Oracle Financials Accounts Payable users have faced a painful choice when it comes to integrating data from third-party systems:

They’ve either needed to rely on costly bolt-on applications or depend on manual labor.

Fortunately, Oracle R12 Financials users can now rely on custom WebADI integrators, which will eliminate the need for manual entry, reduce Total Cost of Ownership by removing the need for bolt-ons and, most importantly, speed payment cycles.

This is the first of a two-part blog series that will highlight WebADI integrations and provide the basics on deploying them. Part I covers pre-requisites for deploying custom web ADI Integrators, designing customer WebADI integrators and building your integrators. Part II will detail steps to take before starting the WebADI wizard and then provide insight into content sets, the uploader, the importer and value lists.

Web Application Data Integrator (WebADI) Overview

Oracle E-Business Suite has long provided users with the tools they need to enable uploads of large quantities of data via Spread Sheet Uploads. In the past, however, this functionality was decidedly user-unfriendly, especially when users needed to create custom, non-Oracle provided integrators.

For example, the first versions of this tool required users to install the ADI Desktop Client to use in tandem with Microsoft Excel. This led to Desktop ADI and Request Center, tools which a few longtime EBS users fondly remember.

Fortunately, we live in new times. Oracle R12 Financials users can simplify a long-standing data integration challenge by relying on custom WebADI integrators, as detailed below.

Pre-Requisites for Deploying Custom WebADI Integrators

Before launching a full-scale project to deploy Custom WebADI Integrators, you need to make sure your ducks are aligned.

First, you must be at the most current Oracle E-Business Suite R12 patch level. If you are behind on patching, trying to deploy Custom WebADI integrators will cause as many problems as it creates. Second, seeded WebADI Integrators must be working correctly.

Third, whoever on your team is configuring the custom integrator needs to be:

  • Experienced in working with seeded WebADI Integrators
  • Able to read and write basic SQL
  • Experienced in working with the target module

This is not a “learn as you go” type project.

Fourth, you need to have Microsoft Office configured properly to use WebADI. This is a straightforward process, but you would be surprised to see how often it is overlooked. Fifth and finally, you need to keep in mind that the custom integrator you are building will only import data.

Designing your WebADI Custom Integrator

Before you begin, you first need to obtain detailed requirements from your business users. This will allow you to be proactive in your design while avoiding “Scope Creep.” Give WebADI integrators the same level of attention that you’d give to interfaces or SQL Loaders; they’re going to form a fundamental part of your Oracle EBS solution and you should think of them that way.

Remember that while custom integrators and custom projects exist that can use API’s for loading data into seeded or custom tables, most business users are accustomed to Excel. So you should plan on using Excel as it will both facilitate faster development and foster rapid user adoption. Along those lines, your custom integrator will function and look the same as the ones that Oracle provides, which reduces your need to train users.

Remember that each custom integrator can only be tied to one specific module. Therefore, your Accounts Payable loader will only work with your AP module, and cannot be used to simultaneously load data into Accounts Receivable.

Whether you use an API or custom program to load your data, you will still need to create a staging table to house imported data prior to upload. Regardless of your choice, the best practice is to use a custom schema to house your staging data.

When designing your custom integrator, identify whether any data will need to be entered via an external look-up process. This allows you to design an upload spreadsheet that validates data as the information is being entered and alleviates the amount of programming required when building the integrator.

Oracle provides the ability within custom integrators to design pop-up windows as well as drop-down lists as a method of data entry to assure that only valid data is allowed as part of your upload. System populated look-ups allow you to control datasets.

Building Your Integrators

Oracle Desktop Integration provides you with configuration wizards to use when creating your integrator. These will guide you through the process and ensure that you do not miss anything. To access the configuration wizards, you’ll need the Desktop Integration Manager and Functional responsibilities.

The Desktop Integration Manager responsibility gives you the ability to view all of the existing integrators that are part of your system, although your views of Oracle-provided integrators will be limited to their configurations. The Desktop Integration Manager screen provides functionality for launching your integrator.

Stay Tuned for Part II

At this point, you are ready to begin building your custom WebADI integrators.

Part II of this series will take you through the step-by-step process for doing so. It will guide you through defining import destination, setting up your content sets, and working with uploaders and importers.

We will publish Part II in one week’s time, so be sure to check back.

If you need to talk with one of our Web ADI integration experts today, contact us here and we’ll set up a 1-1 call.