Hopp EBS – Migrating into Oracle eBusiness Suite

– migrating into Oracle eBusiness Suite

This note highlights key features of Hopp EBS, an extension of Hopp that makes data migration into Oracle EBS from any legacy system much faster, cheaper, and better. The focus is on applying the Hopp generic bridge framework to Oracle EBS as the target system. 

For general information about Hopp Bridge or background information for this article, please see Hopp Bridge. 

Introduction

The Hopp EBS Bridge—or Hopp EBS for short—is created to apply Hopp's rich functionality to Oracle EBS when migrating data from any legacy system or previous version.

Out-of-the-box, Hopp EBS contains a Hopp Target Map for Oracle EBS and the functionality needed to insert data correctly in Oracle EBS using Standard Oracle APIs.

With our Hopp EBS solution, you get most of the code and control features you need, giving you a head start on your Oracle EBS data migration.

Recap of dataflow in migFx

Not to repeat information elsewhere (you can read about this elsewhere on www.hopp.techhelpful) it might be useful to mention a few things about how Hopp manages the dataflow to position Hopp EBS correctly.

Just as a reminder, recall that:

• Legacy Source System data are mapped into migFx using the separate Source Map functionality in migFx
• The Source System is matched to Oracle EBS Target Map through the migFx EBS Target Interface
• The migFx EBS Target Map pulls definitions from Oracle EBS through the Valueset Provider and delivers Oracle EBS data compliant with the established definitions
• The API Packages then create The Target System Objects and inserts them in to Oracle EBS
• Error messages are fed back from Oracle EBS to migFx to ease error tracking

This coherent execution flow will improve the quality of the end-to-end flow by resolving dependencies and identifying any issues before or when insertion into Oracle EBS is attempted. 

Issues are returned to Hopp, flagged and can be dealt with in a structured and supported way before another attempt is made.

Hopp Bridge applied to Oracle EBS

From migFx there are standardised extensions used as part of a bridge to any target system as described in more details in our note on the generic migFx Bridge.

The short version is that any bridge like the Hopp EBS is a collection of features specifically developed to deliver a fully workable end-to-end data migration solution out of the box.

The Hopp EBS solution comes with an EBS Target Map that contains all the mapping (structures, rules, and validations) and delivery mechanisms needed to deliver high-quality data directly into Oracle EBS—you don't need to code anything yourself.

migFx EBS contains the functionality to create EBS data structures that meet the requirements in Oracle EBS.  

It is important to remember that Hopp EBS creates and holds the target data for each business object as an XML element. This element contains the child business object hierarchy—each business object in the hierarchy contains all target data for that object, like a customer with its addresses, account with entries, project with tasks, etc. Objects are mapped as single entities, validated, and processed across the data migration flow as one unit.

EBS Providers

The generic Hopp Bridge contains the elements that are needed to integrate with the given Oracle EBS. A migFx EBS Bridge contain a Target Map and a set of Extensions - here called Providers.

Hopp EBS Target Map

• Hopp EBS make use of the Hopp software Target Map to structure the logical business entities as business objects the different Oracle modules
• It contains the validation and rules needed to ensure the only high-quality and consistent date are passed on to Oracle EBS
• We deliver a full target map for Oracle EBS so your project can focus on applying and extending it, not starting from scratch
• The Oracle EBS target map is setup in a way that is easily understood by any Oracle EBS business consultant should modifications or extensions be needed

Metadata Provider

Changes to tables or API requirements are The Hopp EBS metadata provider ensures that any changes to tables or API requirements are made visible to the target map. Validation ensures that the new or changing metadata definitions raise a flag in Hopp EBS, and action can be taken.

Valueset Provider

In most Oracle EBS data migrations, it’s important to validate against or enrich data with data already in Oracle EBS. 

The Hopp EBS Valueset Provider pulls data as value sets from Oracle EBS and makes them available for use in rules and validations in Hopp EBS.

Let’s look at what the different bridge elements do and how they are positioned in Hopp EBS as illustrated in the Figure 1 below.

Figure 1. Hopp EBS Components 

Starting with the generic migFx Bridge framework it is straight forward to apply it to Oracle through the EBS Providers and Delivery mechanism.

Delivery Provider

Hopp EBS delivers data to Oracle EBS through a well-defined Delivery mechanism. It stages the target data and inserts it into Oracle EBS object by object, maintaining the business integrity created in Hopp. The flow runs as follows.

• Hopp completes an iteration of the migration, it outputs a csv file per business object
• Each csv file is used as an external table in Oracle EBS, i.e. it can be queried using SQL as if it was a table
• A request set is run which processes each of these no source files in turn
• The source files are then copied to staging tables, which have the same columns as the files
• An API for that object is then called, using the columns of the staging table as parameters

In every subsequent iteration, for each row, every column of the source file is compared with the corresponding column in the staging table.

If there is even one difference or the row doesn’t exist in the source file, the object is deleted from Oracle using the delete API, and the corresponding row from the staging table is also deleted.

This results in each row being re-copied from the source file and, therefore, re-created correctly in Oracle EBS.

This way, after every iteration, the objects in Oracle EBS correspond precisely to the source files.

Testing the delivery

Testing using migFx EBS can to a large extent be done without loading data onto Oracle EBS. How?

Iterations can be done multiple times in migFx EBS without using Oracle EBS to test. As migFx hold the source data, Valuesets and the target map data can be processed in full or any part to test and verify that data passed through migFx EBS meets all requirements and are consistent.  

When data are ready migFx EBS, they will be pass as objects on to migFx EBS Delivery mechanism who insert the data correctly into Oracle EBS.

A secondary user test can be performed in Oracle EBS to finally ensure that quality is as expected for a given test phase or signoff.

What runs where?

Hopp is always installed on a Windows platform using SQL Server. The migFx Extension is sitting across the Microsoft platform and the Oracle platform with the EBS Target Map and EBS Interface on the Microsoft side and the Valueset provider, Delivery and API Package on the Oracle side. 

Target System objects covered

The Target System objects that can be created by migFx EBS cover all of Oracle EBS. We have a prototype available to demo (which has Project Headers, Tasks, Customers, and Key Members implemented) and we would be happy to extend it to cover any Objects in Oracle EBS.

Depending on the projects scope - all or some of these objects will be included. The Target System Objects covered by migFx EBS are shown in table 1 below.

Table 1: The Target System Objects Covered by migFx EBS