EPM Integration Agent

This is huge! When I first shared this news with a data integration colleague, his reaction was “wow, this is the best thing I have heard the entire week!” (and it was Friday afternoon).

Oracle announced at Kscope19 in June that they are soon going to release an on-premise integration agent for EPM Cloud that will allow clients to connect to on-premises data sources. It will come pre-seeded with queries for EBS and PeopleSoft GL, and can also access any other data source through custom SQL queries. This integration agent will take the form of a small-footprint software, similar to EPM Automate, installed on a small server or virtual machine where it can access your on-premises source systems. The definition of the data sources, queries and filters will be stored in EPM Cloud, so the configuration that will need to happen on-premise should be really minimal.

There will be two mechanisms for how EPM cloud can communicate with this agent:

• A synchronous mode: if EPM Cloud can directly access the port where the agent is listening, then as soon as the user clicks import in EPM Cloud:
  1. EPM Cloud sends a request to the agent with a ProcessID (this is the only communication going from the cloud to the agent)
  2. The agent will request the details of the job (SQL & parameters) to EPM Cloud by referring this ProcessID
  3. The agent will process the request. Pre and post processing are also possible (similar to what was possible on-premise with FDMEE)
  4. The agent uploads the data to the cloud
  5. The data is processed the same way it would be currently with flat file or EPM Automate uploads (logic groups, mapping, validation, export, reports, etc.)

This synchronous more is straight forward, but it implies that an internal server be accessible from the public internet and will require to setup a DMZ with a firewall and an HTTP server to ensure that only this specific port on this specific server can be accessed.

• An asynchronous mode: if you cannot get the IT security approvals for the synchronous mode to work, this will be your plan B. In this mode, there is no need for any communication from the outside to the internal network. Instead the agent will poll a queue in the cloud periodically and execute requests it finds in this queue. When the user clicks import in EPM Cloud:
  1. EPM Cloud puts the request (SQL and parameters) in a queue
  2. The agent polls the queue at an interval set by the customer
  3. If a job is in the queue, the agent gest the SQL and parameters. After which the process is identical to what it is in synchronous mode:
  4. The agent will process the request. Pre and post processing are also possible (similar to what was possible on-premise with FDMEE)
  5. The agent uploads the data to the cloud
  6. The data is processed the same way it would be currently with flat file or EPM Automate uploads (logic groups, mapping, validation, export, reports, etc.)

The most important decision factor when considering whether to use the synchronous or asynchronous option is probably what can be approved by IT from a security standpoint. Oracle paid attention to concerns IT may have by minimizing communication from the cloud to the on-premise agent and by making sure any communication between EPM Cloud and the agent is encrypted using a pair of private and public keys generated when the agent starts and making sure that the agent will only accept requests encrypted with its public key.

Another factor to consider is that the drill down option where the data from the source can be shown in an EPM Cloud dialog will only be available with the synchronous mode, at least for now. The other drill down option based on an HTTP call to the source, as it exists today, will be available both in synchronous and asynchronous mode.

The pre- and post-processing options, using either Jython or Groovy, and the ability to define your own SQL queries for data sources that don’t come with pre-seeded integration will enable our clients to make direct data integration work for any source system, just like it was with FDMEE.

Oracle asked us and a few other firms to test a beta version of this integration agent. I am happy to report that after our tests, including of the pre-seeded integration with one of our internal EBS demo applications, we proposed some minor enhancements but didn’t find any major issue.

This is a big step in EPM Cloud becoming a more and more robust and mature solution, and I think this will greatly benefit the Oracle EPM community, including all the on-premise customers trying to decide when is the right time to upgrade their EPM platform. Exciting times!

You can play this webcast from Cloud Customer Connect for more details.