Recently my team and I had the opportunity to implement Oracle’s newest offering – Enterprise Data Management Cloud Service (EDMCS). EDMCS for those of you who are not familiar provides a cloud-based solution for managing master data (also referred to as metadata) across the organization. Some like to refer to EDMCS as Data Relationship Manager (DRM) in the Cloud, but the truth is, EDMCS is not DRM in the Cloud.
EDMCS is a completely new vision of what master data management can and should be. The architect of this new cloud offering is the same person who founded Razza Solutions which was the company that developed the product now known as DRM. That is important to know because it ensures that the best of what DRM has to offer is brought forward. But, more importantly, it ensures that the learnings and wish list of capabilities that DRM should have are in the forefront of the developers’ minds.
Ok, now let’s get back to fun stuff. In the 18.05 patch for EDMCS, the REST API (v1) was exposed for public usage. The documentation for the REST API can be found here:
As I highlighted in the previous post Troubleshooting Cloud Data Management Metadata Load Errors, I had developed an automation routine to upload EDMCS extracts to both PBCS and FCCS using FDMEE and Cloud Data Management. We had been eagerly awaiting the REST API for EDMCS to finalize this automation routine and provide a true end-to-end process that can be scheduled or initialized via a single action.
Let’s take a quick look back at the automation routine developed for this customer. After the metadata has been exported to a flat file from EDMCS, the automation would upload a copy to the PBCS and FCCS pods, launch Cloud Data Management data load rules which would process the EDMCS metadata extracts, run a restructure of the database after all dimensions had been loaded, and then send a status email alerting the administrator of the result. While elegant, I considered this to be incomplete.
Automation, in my view, is a process that can be executed without user interaction. While an automation routine certainly has parameters that must be generally maintained, once those parameters are set/updated, the automation cycle should not be dependent on user input or action. In the aforementioned solution, we were beholden to the fact that EDMCS exports had to be run interactively; however, with the introduction of the publicly exposed REST API in the 18.05 EDMCS patch, we are now able to automate the extract of metadata from EDMCS. That means we can finally complete our fully automated, end-to-end solution for loading metadata. Let’s review the EDMCS REST API and how we did it.
The REST API for EDMCS is structured similar to other Oracle EPM REST APIs. By this, I mean that multiple REST commands may need to be executed to achieve a functional result. For example, when executing a Cloud Data Management data load rule via the Data Management REST API, the actual execution of the data load rule is handled by a POST call to the jobs function with the required payload (e.g. DLR name, start period, etc.). This call is just one portion of a functional requirement. To achieve an actual data load, a file may need to be uploaded to the cloud, the data load rule initialized, and then the status of the data load rule be retrieved. To achieve this functional result, three unique REST API executions would need to occur.
To export metadata from EDMCS to a flat file using the REST API, the following needs to be executed:
- Get the dimension information for the EDMCS application from which metadata will be exported
- Execute an export of the dimension(s)
- Determine the status of export
- Download the export to a flat file
Let’s explore each of these in a little more detail. First, we need to get the dimension IDs for the application from which we will be downloading metadata. This is accessed from the applications function.
When executing this function, the JSON object return includes all applications that exist in EDMCS (including those archived). So the JSON needs to be iterated to find the record that relates to the application from which metadata needs to be exported. In this case, the name of the application is unique and can be used to locate the appropriate record. Next, we need to query the JSON object to get the actual dimension id (circled in red). The dimension ID is used in subsequent calls to actually export the dimension.
Great, now we have the dimension ID. Next, we need to execute the REST API call to export the dimension.
You will notice that when you access this POST method, the dimension ID from the previous step is required:
The JSON object returned from this execution contains minimal information. It simply provides the URL to the next required REST API execution which will provide the status of the execution.
With this information, we can check the status of the export using the jobRuns function
The JSON object returned here provides us the status of the export invoked in the prior step (in yellow) as well as a URL to the actual file to download which is our last step in the process.
Once the export job is complete, the files can be streamed using the URL provided by the REST execution in the prior step.
And there you have it, a fully automated solution to download metadata to flat files from EDMCS. Those files are then provided to the existing automation routine and our end-to-end process is truly complete.
And for my next trick…let’s explore some of the different REST API tools that are available to help you in your journey with the EPM REST APIs.