OBIEE 11 - Configuing Web Services for SOA

As part of OBIEE there are 2 types of web services:

• Session Based Web Services
• Web Services for SOA (new in 11g)

A great reference for the entire subject of Action Famework in OBIEE is the lecture "Oracle Business Intelligence 11g Overview of Action Framework" by Antony Heljula. Reading the OBIEE Integrators Guide might help as well.

Most of what you see here is covered very well by Antony, including the topic of security I didn't cover here. Unfortunately I had some problems with the last part when following Antony (since his configuration is 11.1.1.5 style, and starting 11.1.1.6 it was changed), that is why this post exist.

Lets talk about how we can configure the second option, Web Services for SOA.

The access to web services is done by the URL http://YOURSERVER:PORT/biservices/inspection?wsil. In my case it was http://bdahab-lap:9704/biservices/inspection?wsil.

Assuming no one configured it, you will see the Error 500--Internal Server Error screen.

If you want to use the Web Services for SOA, that means you have to do some configuration.

What needs to be done is setting the credential store and updating the ActionFrameworkConfig.xml.

Configuration steps

Enter the EM (my case http://bdahab-lap:7001/em) and Right Click on WebLogic Domain / bioundation_domain and select Security -> Credentials

Select oracle.bi.enterprise and create a new key: wsil.browsing

fill the user name and password. This is the user that will always be used when running the wsil web services. For better security of this option see slides 46-54 in "Oracle Business Intelligence 11g Overview of Action Framework" by Antony Heljula or OBIEE Integrators Guide

Next we will go to MWHOME\user_projects\domains\bifoundation_domain\config\fmwconfig\biinstances\coreapplication and create the file wss_username_token_policy.xml.
with the following content:
 <?xml version="1.0" encoding="UTF-8"?>
<oracle-webservice-clients>
<webservice-client>
<port-info>
<policy-references>
<policy-reference uri="oracle/log_policy" category="management"/>
<policy-reference uri="oracle/wss_username_token_client_policy" category="security"/>
</policy-references>
</port-info>
</webservice-client>
</oracle-webservice-clients>

The last part is configuring ActionFrameworkConfig.xml that you will find in the same folder.
(When you back it up, and for some strange reason decided to save the backup in the same folder, don't save it with XML extension.) Here I had some help from Meirav Malka from Oracle ACS.

 My Original file was:

<?xml version="1.0" encoding="UTF-8"?>
<obi-action-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="afconfig.xsd">
    <aliases/>
    <registries/>
    <content-types>   
      <content-type>
        <typename>webservices</typename>
        <displayname>Web Services and BPEL Processes</displayname>
        <actionType>WebServiceActionType</actionType>
      </content-type>
      <content-type>
        <typename>misc</typename>
        <displayname>Mixed Services</displayname>
        <actionType>URLActionType</actionType>
      </content-type>
    </content-types>
    <accounts/>
</obi-action-config>



The updated file was:

(Change  bdahab-lap:9704 to whatever is relevant for your system.)

<?xml version="1.0" encoding="UTF-8"?>
<obi-action-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="afconfig.xsd">
    <aliases/>
<registries>
 <registry>
            <id>reg1b</id>
            <name>BI EE Web Services for SOA</name>
            <content-type>webservices</content-type>
            <provider-class>oracle.bi.action.registry.wsil.WSILRegistry</provider-class>
            <description></description>
            <location>
                <path>http://bdahab-lap:9704/biservices/inspection?wsil</path>
            </location>
           <service-access>
            <account>wsil.browsing</account>
            <policy>wss_username_token_policy</policy>
            <propagateIdentity>false</propagateIdentity>
           </service-access>
        </registry>
</registries>
    <content-types>   
      <content-type>
        <typename>webservices</typename>
        <displayname>Web Services and BPEL Processes</displayname>
        <actionType>WebServiceActionType</actionType>
      </content-type>
      <content-type>
        <typename>misc</typename>
        <displayname>Mixed Services</displayname>
        <actionType>URLActionType</actionType>
      </content-type>
    </content-types>
<accounts>
        <account>
            <name>wsil.browsing</name>
            <description>Account for BI WS for SOA</description>
            <adminonly>false</adminonly>
            <credentialkey>weblogic</credentialkey>
        </account>
    </accounts>
<policies>
    <policy>
        <name>wss_username_token_policy</name>
        <policyfile>wss_username_token_policy.xml</policyfile>
    </policy>
</policies>
</obi-action-config>


In this very naive (security-wise) set up I created an account definition I named weblogic (you can use any name you want). Naturally in production environment we will use better security.
We need to connect this "weblogic" account to a real user and password.

As described in chapter 5.5 of Integrators Guide, enter EM again.
In bifoundation_domain right click and select Security -> Credentials.

Create Map named oracle.bi.actions

In that map create a Key. The key should fit your account (weblogic in my case) and you should enter the username and password of a real BI user.

Restart BI Presentation Services and Weblogic "bi_server1" (or just the entire OBIEE).

Now try the URL again.

Better, open action menu, Invoke a Web Service. Now you see all the objects in catalog, available as web services.

A good question is: OK, what is it good for?
Using Web Services for SOA we can easily run any object in catalog, including agents. To the best of my knowledge, we will not see the result of the activated object, but it will run in the background.
So to my humble opinion, a clear use case is to activate agents from an analysis or dashboard.

I'll be happy to hear additional use cases.