How to Integrate your Oracle Cloud ERP system with other enterprise applications

In this paper I will talk you through how to integrate your shiny new Oracle Cloud ERP system (Fusion Applications as it was once called) with the rest of your enterprise applications.

Integration in the “new world”

If you’ve been around ERP systems for a while, you’ll know that integrating them with the rest of your business is fairly bread and butter stuff. “Techies” like me have been doing this sort of work for years.

So why am I writing a document on how to integrate with Oracle’s Cloud ERP? The answer is simple: because it’s no longer as straightforward as you might imagine. This is not to say that the process is complicated, but it can be cumbersome to put into practice.
Remember that integrating with a Cloud-based ERP application means that you do not have direct access to the servers or the database. This is certainly the case if your Oracle Cloud ERP system is hosted by Oracle themselves and you have not implemented “on-premise” which whilst offered isn’t widely taken up if at all.

This might come as a shock to you – particularly if you come from an E-Business Suite background (like I do), where the use of tools such as SQL meant that data has always been made available. I start getting twitchy if I can’t see the data directly; so the move to Cloud has been something of a personal adjustment.  I can still see the data (if I plant my SQL query in a BI publisher report) but I can’t edit the data!

There are, however, various different options available for integrating with Cloud ERP. There are also a few decisions you can make to speed the integration process up.

What are the integration options available to me?

There are two main options available to you for getting your data into Cloud ERP:

• File based loaders
• Web Services

File Based Loaders

File based loaders (FBLs) allow users to import data into Cloud ERP via the use of import templates (spread sheets) supplied by Oracle. The process goes through the following steps (and is outlined in the diagram below):

1. Download the appropriate template from the Cloud
2. Populate the template with data (user action)
3. Upload the template to the Universal Content Management (UCM) system
4. Data is transferred to the open interface table
5. The user enacts a scheduled job in Cloud ERP. This tells it to import the data from the open interface table to the ERP base tables
6. Fixing errors in the open interface table is achieved either via ADF Desktop Integration (ADFdi) or via starting the process again and fixing the data at source.

The FBL process is not difficult to execute. But there are some important points to note before embarking on this approach:

• The import templates will not validate the data that you enter into them. However, any errors that occur later in the process (at the open interface table stage) can be corrected using ADFdi, which can perform validation checks on the data in the table.
• The process is very manually intensive.
• The process can be entirely executed by the user, i.e. there should be minimal IT support required beyond the initial configuration of the system.

It may not be a challenging process (assuming the inbound file was created using the correct template from financials in the first place and the entered data is correctly formatted) but it does require a fair bit of manual intervention – this is where Claremont can help.

We recently implemented Financial Cloud for a Financial Services company. As you might imagine, they required a fair bit of bank integration given they operate around 120 bank accounts across a raft of currencies and 5 different banks, so you can see how any manual approach to this process would quickly become fairly time consuming.

Working with the client to automate these interfaces, via the web services, Claremont ensured that the integration ran smoothly and that the time and resource required from client side was kept to a minimum.

Web Services

Web Services are programmatic interfaces in ERP Cloud, which enable both inbound and outbound data transfer.

For those of you well versed in E-Business Suite (EBS) type ERP applications, think of these as similar to the PL/SQL APIs that are available in EBS. They enable you to pass data into the application and then have Oracle validate that data.

Note: The key difference in Cloud web services is that web service calls are written using open standard languages (XML based e.g. SOAP services) as opposed to the proprietary PL/SQL language that EBS uses. This is one benefit to Cloud ERP – as it should therefore be able to connect with most other modern business applications.

For those of you who are new to Cloud systems and web services, a quick primer on what a web service actually is:

The World Wide Web Consortium (W3C) defines a web service as…

A software system designed to support interoperable machine-to-machine interaction over a network

Simple enough.

In essence, it’s a service offered by one device communicating to another. But the key to using web services as an integration approach relies on the following:

• The services are operated in open standard languages: XML-based
• The services are described in a standard manner: via a WSDL description (Web Services Definition Language)

The benefit of using web services for integration is that you can programmatically control the use of these services.

For example, let’s say you build or buy an application that performs order capture. When it comes to billing the customer for his or her orders, you could call the ERP Financials Cloud web services to create an invoice for the customer.

The key here is that your order capture application could do this automatically for you (assuming it is itself web service enabled).

Your call to the Financials Cloud web service would validate the data that you sent over. It would then pass back a response that tells the order capture application that the invoice had been successfully created in the Cloud – or it would pass an error code and message if something had gone wrong.

It is important to note that as an approach this is not hugely different from custom applications calling PL/SQL APIs in EBS. In fact, Claremont recently enabled EBS to respond to a custom-built web application using JSON (for example).

But it’s also important to understand the different options that fall under this one approach.

Choosing a web-based approach

When integrating the Cloud with external data and systems, there are two main approaches that involve the use of web services:

#1 Loading data from files:

Web services are available which replicate the manual steps described above in the FBL process.

Originally (in release 9) separate web services had to be called to perform each of the steps in the FBL process (import file to UCM, validate file, import file etc.). But Oracle are now making services available, which act as a wrapper to the overall FBL process.
Within the ERP Integration Service a new API is available called ‘Load-and-Import-Data’. A file submitted to this service will automatically be taken through the various stages of the import process.

If you still need to exercise more granular control over the file import process, there is still nothing to stop you from using the original method of calling the various APIs separately.

#2 Loading data directly into ERP Cloud:

This approach is similar in concept to calling a PL/SQL API in EBS to create an AR invoice, for example.

Again, depending on how much control you require, there are various different objects you can use. For example, within AR there is a SDO (Service Data Object) called ‘create-simple-invoice’, which generates an invoice with charge amounts that can be passed to the customer.

If your needs are more complex, you can access other objects which separately produce invoice headers, lines and distributions – either directly or via the AR open interface tables.

There is one difference between web services and old-school PL/SQL APIs that is worth noting:

A web service can be either synchronous or asynchronous. In the case of synchronous APIs, the calling application sends over the payload and waits for a response.
In contrast, asynchronous APIs work by being called. Then the calling API will return, at some later point in the process, to find out what happened to the data passed in (although this is not mandatory) using some other web service.

This can be handy if you know that the service you are calling might take a while to do its stuff or if that service is going to ask someone for approval of your data.

Choosing the right tools for the job

In summary, the various methods for integrating into the Cloud at a high level are:

• #1 File Based Loaders:

– Pre-seeded with the product – no development needed

– Easy to use

– Time consuming and very manual to operate especially if you have lots to process, or

• #2 Web Services:

– Use open standards: you don’t need to be an Oracle specialist developer to use them

– Programmatically controlled: you can add as much logic (checks, approvals etc.) around calling the web services as you like

– Require coding

– Provides alternative ways for loading data into the Cloud: either load the file via a web service or create your business object directly using a different web service.

How can Claremont help?

Claremont has implemented Oracle Cloud ERP in various different organisations but what we have learnt along the way is that how Cloud ERP integrates with the outside world was not at the epicentre of Oracle’s focus when it built the product’s design features list.
Oracle are very quickly making up ground in this area. Options for both migrating data, and synchronously moving data to and from the Cloud, are steadily advancing but there is still work to do in this area and advances are being seen in each new release of Cloud ERP.

This is why, at Claremont, we’re building tools which make the data integration process much easier.

The increasing availability of web services means that a variety of technologies can be used to build applications outside of the Cloud (or in a different Cloud application) that automates the loading of data.

The team at Claremont are taking advantage of this. We’ve already developed web based tools that sit outside of the Cloud and help our clients to import their data both quickly and easily. These tools enable users to highlight, validate and upload data into the Cloud in the most efficient manner.

We’re also working on developing options to schedule loads, and to create sets of loads (think Request Set definition from the EBS concurrent manager if you come from that background). Organisations such as RunMyJobs provide some of these services, and at least one Cloud ERP client that we know uses this product to schedule data loads over web services into the Cloud ERP.

Integrating with Cloud ERP can be an onerous process – but exciting advances are happening to make it a little more straightforward. At Claremont, we’re proud to be part of these developments.

We already help a range of organisations realise the value of Oracle Cloud ERP; ensuring that their integration process is a smooth and seamless journey.

To find out how Claremont can help you integrate with Oracle Cloud ERP, contact a member of the Claremont team.