Simple Introduction to using the Enterprise Manager SOA/BPM Facade API


There may be times when you need to expose just a small section of what is displayed in the Enterprise Manager console for SOA/BPM (EM console).

A simple example can be where stakeholders on the systems integration or customer teams want to monitor a dashboard of statistics on how many instances of a composite have been created and how many have faulted.

You can see this in the EM, as shown below


Some of these stakeholders may not have knowledge of  EM console and they just want a quick view into the statistics, without having to navigate EM.

This post describes how to use the Oracle Fusion Middleware Infrastructure Management Java API  for Oracle SOA Suite (also called the Facade API)  to build a custom ADF page to display this information. If you want a quick introduction in using the Facade API, this post is for you.

To keep it extremely simple, I am going to create a single page which displays the same information as in the EM/soa-infra/Deployed Composites page. I don’t want the user to have to sign in, because this  runs in an internal network  and that way they can bookmark it and we don’t have to create a user id for each of these users.

This is how I want it to look, yes, ugly…but…quick and has the utility value and serves its purpose.


Coding the Model

Here’s the code I use to retrieve the statistics for Composites. I’m using the EM API. You can find it at EM Facade API Reference

The is the main entry point for the Facade API. It allows us to search for component instances, components and composites and do lifecycle operations. The CompositeStatsView you see in the code snippet is just a custom javabean I wrote to pass back some data to the UI layer.

You can see that I get an instance of the Locator using the LocatorFactory.createLocator (jndiProps). I’m passing in JNDI properties which helps the LocatorFactory create the Locator from the soa server JNDI. I’m planning to run my app on a separate server, which is why I need to pass this in. If you plan to run this on soa server , you can use the other createLocator () method on LocatorFactory, where you don’t have to pass in the JNDI properties.

What about Security?

Assume you create a data-control from a class that contains the code above and then drop the getCompositeStats method shown above as a read-only table (If you are absolutely new to ADF and want to see how I did this, I will soon be adding associated links to show how I did that).

When you run the ADF page you will see an issue. It doesn’t return any composite statistics. You may see a page like this, when you try to execute the query.


This is because you need the Admin role to execute these methods in the API. If you look at the model code closely, I have commented the following lines

Why did I comment these? Wouldn’t everything have worked just fine if I kept those in and  connected as ‘weblogic’ or whichever user has the Admin role. The answer of course is , yes, it would have worked. But I didn’t do it because its impractical. In a real deployment environment, I’m not going to know the user id/ password of a user with the Admin role.

One way to deal with this is to have this code run as a user with the Admin role. To do this, I have wrapped this code in an Stateless Session EJB instead of a POJO. In an EJB, I can use the @RunAs annotation to have the code behave as if it is being run by an Admin.

Here’s how my EJB code looks

Notice that I have a @RunAs (“admin”) , where “admin” is custom role I made up. All I have to do now is to map the “weblogic” user (or any user with the Admin role) to the “admin” role in  the weblogic-ejb-jar.xml

Here’s how my weblogic-ejb-jar.xml looks

Once I had the EJB in place, I created a data-control from it and dropped the getCompositeStats as an ADF Readonly Table in the JSP to display the information.

This works when I know about a user id with Admin role ( like “weblogic”) . What do I do when I don’t know which user id has an Admin role (for example in a production environment where I may not have that kind of visibility).  What should I do if I want to make it configurable so that the user id can be changed as per the deployment environment?

Using a Deployment Plan

You can use a deployment plan to map the user id as per the environment into the weblogic-ejb-jar.xml. I have shown what my deployment plan looks like below. I use this deployment plan with the ear file I have for my application. The ear file includes the ejb module and also the web module.

I have created a variable called var-run-as-principal-name and assigned it a value of “weblogic”. This should be whatever user has the Admin role.

and here’s the section that maps this user id to the “admin” role for my ejb.

When I deploy my ear file with this deployment plan the methods execute successfully without any issue around permissions and I can see my Composite information.



EM Facade API Reference

Programmatically Managing SOA Composite Applications with the Facade API

Understanding WebLogic Deployment Plan Contents