Sunday, 29 May 2016

FDMEE and DRM integration - Part 1

The 11.1.2.4.200 PSU release for FDMEE added new functionality to allow integration with DRM, the integration provides the following capabilities:
  • Import chart of accounts values and hierarchies from source ERP systems to Data Relationship Management

  • Map ERP source values to EPM target dimension members within Data Relationship Management

  • Export ERP source to EPM target member mappings from Data Relationship Management to FDMEE
Here is my simplistic view on the flow between FDMEE and DRM


It is important to note that FDMEE currently only supports loading metadata from the following source systems
  • Oracle E-Business Suite

  • Oracle Fusion Financials

  • PeopleSoft Enterprise Financial Management
This means if you want to use the export metadata from FDMEE to DRM then you will need to be using one of the above source systems.

Even though importing data load mapping from DRM to FDMEE is aimed at mapping from ERP systems to EPM applications it is still possible to use the functionality if the source is not an ERP system.

To be able to integrate with DRM then not only do you need to be on FDMEE 11.1.2.4.200+ you also need to be running at least DRM 11.1.2.4.340.

Assuming you are running the required versions then there are a number of other prerequisites that need to be in place before you can jump into the FDMEE and DRM integration.

In this first post I am going to go through getting DRM up and running with Web Services as this is the core mechanism in the integration between the two products.

DRM has two types of Web Services available, the Web Service that has been around for a long time which uses the SOAP protocol and requires Oracle Web Services Manager (OWSM) and the latter addition which is the DRG Rest Service for use with the EPM mobile application.

FDMEE integrates with DRM using the SOAP protocol which adds a lot of configuration overhead compared to the REST service, hopefully one day Oracle will standardise and convert DRM to only use REST which seems to be more favourable these days and in my opinion a lot easier to work with.

The documentation provides a good architecture diagram to show how DRM all fits together with the Web Services

I will be focusing on the FMW App Server area in the diagram to get the Web Services up and running.

The assumption I am going to take is that DRM 11.1.2.4.340+ has been installed and configured to use Shared Services for authentication.

To be able to use the Web Services functionality the following areas need to be completed:
  • Metadata Services Schema (MDS) creation for OWSM.

  • OWSM configuration.

  • WebLogic configured to use an external provider.

  • Deploy the DRM Web Services application.

  • Attach OWSM security policy.

  • DRM API configuration.
So let us start with the MDS schema creation for OWSM, to create the schema the Repository Creation Utility (RCU) is required and as EPM 11.1.2.4 uses FMW 11.1.1.7 then that is the version of the utility that should be downloaded.

You should be able to download this from Oracle Software Delivery Cloud or the Oracle Technology Network.

The utility can run from any machine that has access to the database where the MDS schema will be created.

Once the utility is started the steps are to Create, enter the database connection details and then on the select components step choose “Metadata Services”


The remaining steps are relatively straight forward though if you need detailed information refer to the RCU documentation


Now that the schema is available OWSM can be configured.

OWSM is installed but not configured by default in 11.1.2.4

To configure OWSM start up the Fusion Middleware Configuration Wizard on the foundation server by running:

<MIDDLEWARE_HOME>\wlserver_10.3\common\bin\config.cmd/sh

Select Extend an existing WebLogic domain


Select the domain directory


Select “Oracle WSM Policy Manager”


At the “Configure JDBC Component Schema” section enter the database connection information to the MDS schema.


Accept the default settings through the remain sections and all being well the domain should be extended to include OWSM


Now that OWSM has been configured the next step is make the deployment available and this is done through the WebLogic admin console.

Log into the console and go to deployments and then locate “wsm-pm” and select Start > Servicing all requests.


You may need to restart one of the managed servers but all being well the state of the deployment should show as active.


To verify the policy manager status a validation web page can be accessed.


Right on to the next step which is to an external provider in WebLogic admin console to allow authentication in the Web Services.

The configuration has to match that of an external directory configuration in Shared Services.

In my example I am using a MSAD connection which has already been configured in Shared Services.

In the WebLogic admin console create a new authentication provider and select the type of provider.


I usually set the control flag as sufficient for both the newly added provider and the default authenticator to stop authentication issues with multiple providers.


“SUFFICIENT—the user is not required to pass the authentication test of the Authentication provider. If authentication succeeds, no subsequent Authentication providers are executed. If authentication fails, authentication continues down the list of providers.”

Then it is just a case of populating the provider connection information, the problem with WebLogic is you never know you have got it right until a restart.

Once the admin server has been restarted you should be able to view users from the external directory.


If you don’t see the directory users then analyse the errors in the admin server logs.

Now time to deploy the DRM web services application.

The web application should be located in the api directory of the DRM installation.


In the WebLogic admin console install a new deployment and go to the above path and select the web services ear file.


Install the deployment as an application and then select the target cluster to deploy to.


As I am going to be using the Web Services primarily with FDMEE I chose that as the target.

The remaining configuration screens were kept as default.

Activate the changes and restart the target managed server if it is running.


Start servicing all requests and the state should then change to active meaning the DRM Web Services application should be running.


Now that the application has been configured an OWSM security policy can be attached to protect the Web Service

The documentation provides which policy to apply for integration with FDMEE


“This policy uses the credentials in the WS-Security UsernameToken SOAP header to authenticate users. Both plain text and digest mechanisms are supported.”

It is possible to attach a policy through Enterprise Manager or the WebLogic Scripting Tool (WLST)


Policies can be directly attached to Web Services or globally attached by creating a Policy Set, I am opting for the Policy Set method.


Enter the EPM WebLogic domain name and DRM Web Services application name.


Attach the policy that FDMEE requires when integrating with DRM


Once saved the policy should be applied the next time the managed server is restarted.

Next the API adaptor requires configuring the DRM configuration console.


Enable the API enable and then verify using the test URL


One final configuration I usually add is to the OHS configuration to allow the DRM Web Services to be accessed through the web server.


On to testing to confirm all these configuration steps have been successful.

First to verify the Web Service can be accessed through the web server and that the policy has been attached which can be done by accessing the WSDL


The WSDL is returned which confirms the DRM Web Services are running and can be accessed through the web server, the policy has also been correctly attached.

Finally to test one of the Web Services operations using Enterprise Manager, it is a bit clunky but does its job.


Enable OWSM security policies and use a valid external directory user that has been provisioned in DRM.


To be able to execute the operation successfully a header is required to be inserted into the XML view which defines the parameters for the DRM API adaptor.


If all is well no errors will be generated and a successful response should be returned.


I am going to leave the post here as the Web Services have now been confirmed to be running as expected.

In the next part I will go through the steps to start integrating FDMEE with DRM and look in more detail at what is happening behind the scenes with the Web Services.

3 comments:

Boss Hogg said...

Hi John, hope your keeping well.

For info, I've been having a play with the DRM to FDMEE integration and there is a fundamental problem if your running FDMEE on Linux. The FDMEE Interface as it stands calls out to a BAT file!

Bug has been raised but if you have access to filesystem (I dont as it is OMCS) its a simple BAT to replicate as a shell script and have the py call it.

Hope this helps.

John Goodwin said...

Hi Dave,

Yeah I did notice there is only a .bat deployed with the patch and have mentioned it in the second part.

Boss Hogg said...

Good stuff (as usual).

I note from Part 2 that you also found the typo in the FDMEE template which I raised as a bug. It should be in patch 341 when it becomes available but is a simple search and replace EMPMA with EPMA .