Thursday, 8 September 2011

Bouquet of BI functions

I thought of putting OBIEE, BI Publisher, APEX and BPEL together. There can be a requirement where we intend to hide BI Pub functions like createReport and createFolder from certain users and give them access to functions like runReport and scheduleReport. Such a user might also need functions to run OBIEE reports.
This article describes a process to do this.
I have selectively picked 2 BI Pub functions (login and getFolderContents) and bundled them in a custom wrapper webservice. I didn’t have an access to an OBIEE server from my BPEL server so I couldn’t include OBIEE in this BPEL process. The only change required to include OBIEE in this webservice will be to add an extra partner link of OBIEE. Adding an extra partner link is just a drag and drop operation.
My previous article described the process of creation of a BPEL process in detail so I intend to start from where I left in my previous post.
This article differs from the previous one in the following ways
  1. I am defining a custom WSDL for the client so that it can expose multiple functions.
  2. I am using a pick activity to provide conditional branching
Before I introduce these concepts, I want you to have a look at the BPEL code so that you understand various parts of it

 This is a pick activity. It makes the decision of picking one of the 2 lanes which follow it. Each lane corresponds to one of the functions defined in the webservice used by the ManyOperations partner link

is an onMessage branch of the pick activity. Pick activity has an onAlarm branch as well but we don’t need it. Lets not discuss about it. We can have as many onMessage branches as we need but 1 is mandatory. Each onMessage branch corresponds to each function defined in the webservice used by the ManyOperations partner link

is the invoke activity. This was used in the previous article as well. It invokes an external partner link

Stands for external partner link. You can see 2 of these in the pic above. One(BI_Pub_PRS) represents BI Pub’s PublicReportService web service and the other(ManyOperations) is exposing our implementation to the outside world.

Logically, the partner which is exposing our code to the external world should primarily do the following things
  1. Get the response from our code (Done by a reply activity in our case)
  2. Know the xsd (XML Schema Definition) which defines the type of response it will get. The response can be a simple string or can be a complex structure. (We are importing the schema defined in PublicReportService in our custom WSDL file to do this)
  3. It should declare the functions implemented in the code (This is done in the custom WSDL file. This has been copied below for your convenience)
  4. It should define its partner. In our case, it is our implementation (Part of the code lying in the white region here. We are doing this in the create partner link wizard in step 6)
Let me describe how partners work. When I say ‘a partner’, I am talking about the things apart from my implementation. Everything outside the white region is a partner to the thing in the white region.
Now our code in the white region needs a face to present to the external world and the ‘ManyOperations’ partner does the same.
We are now going to design the face, and as discussed, this face should have the 4 essential features mentioned above.This designing is done by writing a WSDL which can be imported in this partner link.
In the below code.
  1. The most import part is the importing of the PublicReportService. It helps a lot by not having to create a separate xsd, defining messages for custom types and then doing assignment from one variable to the other. Good BPEL programmers hate this approach and they are right, but I am just trying to make my example simpler J
  2. Xmlns defines the namespace
  3.  ‘portType’ tag declares the functions of this custom webservice and their input and output types
  4. This webservice will be used for the MAnyOperations partner link. So it is defining ManyOperations as its partner.This is done by partnerLinkType tag
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="ManyOperations"
            <import namespace=""

    <portType name="ManyOperations">
        <operation name="login">
            <input  message="pub:loginRequest" />
            <output message="pub:loginResponse"/>
        <operation name="getFolderContents">
            <input  message="pub:getFolderContentsRequest" />
            <output message="pub:getFolderContentsResponse"/>
    <plnk:partnerLinkType name="ManyOperations">
        <plnk:role name="ManyOperationsProvider">
            <plnk:portType name="client:ManyOperations"/>
We can now switch to the BPEL code.

  1. Start by making an empty BPEL process (We had made an asynchronous process here). We are making an empty project because we intend to create the client wsdl on our own

  1. Right click on the ‘Integration content’ folder and select ‘New’

  1. Create a wsdl file as shown below. The contents of this file should be the same as the one mentioned above with obvious changes for the environment. You may change the names if required.
  1. Now go to ManyOperations.bpel (ManyOperations is my bpel project name) and drag a PartnerLink from the component palette (available in services in the component palette) as shown in the figure below. Drag it all the way to the gray region.
  1. A popup called ‘Edit Partner Link’ will come up when you drag a  partner link activity in the gray area. Give it a name and click on the torch icon. Select the newly created ManyOperations.wsdl (custom WSDL created above) from the list, as shown below.
  1. Click the apply button. Your Partner link should look like the following. It is important to select ‘My Role’ otherwise you will not be able to see operations when you try to link the reply activity to this partner link in step 13

  1. Drag another partner link to the right gray region. We are now creating the BI Pulisher partner link. We can create any number of partner links like these. We can have an OBIEE partner link as well
In a multipoint WSDL Partner link type specifies the service to be used in it. So it might look useless in case of BI Publisher but it is important in case of WSDL’s like that of OBIEE. Below screen shot shows OBIEE service as a partner. (We will not be using OBIEE as a partner because I cannot access OBIEE’s presetation server from my BPEL server, network problems J )
In case you want to use OBIEE, then your url should have the following structure
I intend to use the PublicReportSerivce webservice. BPEL creates a local copy of the WSDL so your Crete Partner Link wizard might have the address of this local copy in the ‘WSDL File’ text box, as shown in the pic below. You have to the put your PublicReportService’s wsdl in this text box
The URL of WSDL of PublicReportService is
If you get a few prompts after clicking the apply button then click ‘yes’ in them. Your final BI Pub partner link will look something like the following. If you do not select ‘Partner Role’ then you will not be able to see the list of function provided by the webservice when you connect it to the invoke activity in step 11.

  1. Now drag a pick activity available under process activities in component palette and put it in the white region. Match your implementation with this .
  2.  Once this is done, expand the pick activity and delete the onAlarm branch of it. Create one more onMessage branch by right clicking on the pick activity. One branch each for the 2 functions of PublicReportService (login and getFolderContents) which we intend to encapsulate in our custom web service.
  3. Put an invoke activity in both of these branches.
  4. Connect both these invoke activites to the BI_Pub_PRS partner link. If you have an OBIEE partner link then you can create one invoke to it. At this point, it all depends on your requirement. Select the desired operation. I selected ‘login’. I have defined my wsdl in accordance to it. You cannot randomly pick a process here. Your wsdl and bpel should be in agreement. Connect the 2nd invoke to the service and select getFolderContents as the function. Create input and output variables in both the invokes by clicking on icon. I have created all variables as global variables.

  1. Put a reply activity in each of the branches
  2. Connect the reply activity to ManyOperations partner link as shown here.A popup comes up. Select a operation name (You should be able to see ‘login’ and ‘getFolderContents’ in the select list. You had defined your WSDL to have these 2 functions under the ‘portType’ tag) . Select one of them. Leave the Fault section blank. Your Reply activity should look like the following. Click on the torch icon next to variable and select the output variable which you had created while defining the invoke activity above this reply activity. In my case, login_InputFromBIPub is the output variable in my invoke activity (see step 11)

  1. We have created our webservice with selected functions and it is the time to test it. Deploy the code. This has been discussed in detail here
I got the following response when I tested my functions. You can also test your webservice from APEX’s web service reference


John Minkjan said...

Nice one! Keep up the good work!

Vishal Pathak said...


I feel honored and absolutely delighted to get appreciation from you

I will do my best


Anonymous said...

Good Post Vishal!! Really Helpful...

Vishal Pathak said...

Thanks to you (Someone who is not so anonymous :) )

Andreas Nobbmann said...

Very good one, Vishal ! That's really fun to read, continue to provide us with this stuff.

So long,

Vishal Pathak said...

Thanks Andreas. Knowing that people read through my stuff and appreciate the content encourages me like nothing else :)

Please keep reading and I will continue to try to post material worth reading :)


Anonymous said...

Keep up the good work,Vishal!

Vishal Pathak said...

Sure .. suggest me some kool topic .. i haven't been able to find some good topic to write on