Change Context Root for xmlpserver on 11g BI Publisher

I have been researching on how to change the context root for xmlpserver on 11g BI Publisher. Since our application could not use xmlpserver as the context root extension, I would love to come up an approach with the deployment of the same application but with a new context root. This topic is an open question. I have worked out one solution explained in the current article. But I still have not figured out the best approach for the question. Let me know if anyone has any idea for the questions I asked in the article.

As far as I have touched this topic, I tried changing the context root on the fly by modifying the xmlpserver deployment configuration as below:

Login to Application console, and click on the Deployments. You should be able see a list of deployments on the weblogic server. Find the one with name bipublisher, expand the deployment, there is a web application named xmlpserver. Click on that, it will navigate to the settings page of xmlpserver showed in the picture below: (Click on Configuration Tab and navigate to the bottom)

 

This Context Root is editable and was previously set to be xmlpserver. So I changed it to newContextRoot and save the configuration. However the settings didn’t get picked up during the server restart and it was not working.

I would expect to access http://domain-name:9704/newContextRoot  instead of http://domain-name:9704/xmlpserver

  Anyone knows why this straightforward approach is not functioning as expected?

My working approach:

Here is what I do for the rest of the steps. I will firstly undeploy the current bipublisher application in enterprise manager and then duplicate a copy of existing xmlpserver.ear with the new name btmreport.ear. Later I modified a few files in btmreport.ear and deploy btmreport.ear with the same name bipublisher under the same target. (This involves a few tricks I found out during the trials and errors. I would explain them in the corresponding steps)

 Step 1. Undeploy the current bipublisher application.

 Access enterprise manger as below. By default you could access the link: http://Domain-Name:7001/em

Now on the navigation panel find bipublisher and click on Undeploy as below.

Continue the undeployment.

If you run into the same error with me as below, it means the configuration of bifoundation has been locked and you need to go to applicaiton console to release the configuration.

How to release the configuration? Simple! Go to application console. By default you access the link: http://Domain-Name:7001/console

Once login, you should be able to see that there are changes that need to be taken actions in order to unlock the configure on bifoundation domain. I have been trying out other deployments on console. So I just wanted to undo the changes to release the configuration.

After this change,  I could proceed on undeploying the application back to enterprise manager.

Now we would need to duplicate a copy from xmlpserver.ear with the name btmreport.ear. And modify two files within the ear file.

xmlpserver.ear location: <BI_middleware_home>/Oracle_BI1/bifoundation/jee/xmlpserver.ear

Now duplicate another ear under the same location: <BI_middleware_home>/Oracle_BI1/bifoundation/jee/btmreport.ear

There are two files to be modified in btmreport.ear:

   (MODIFY 1)btmreport.ear\META-INF\application.xml

 Change From Change To
<display-name>xmlpserver</display-name>  <display-name>btmreport</display-name> 
<context-root>xmlpserver</context-root> <context-root>btmreport</context-root>

  (MODIFY 2)btmreport.ear\xmlpserver.war\WEB-INF\weblogic.xml

 Change From Change To
<cookie-path>/xmlpserver</cookie-path> <cookie-path>/btmreport</cookie-path>
<context-root>xmlpserver</context-root> <context-root>btmreport</context-root>

The reason for changes of these two files could be related to the oracle document : Read More on Web Applications from Oracle Doc

Step 2 Deploy the application under the same name bipublisher. Go to enterprise manager and deploy the application as below:

Input the location of the btmreport.ear. (This could be found in the previous step)

Deploy the application under the same target bi_cluster -> bi_server1

 Now we come to the deployment page.

The trick here is to put the name as bipublisher. That is why we have to undeploy bipublisher application firstly. Since it will not allow the same application name being created twice. And the consequence of not using bipulisher as the application deployment name is that you would not be able to have a complete xmlpserver login page(It showed as a blank blue page). I would assume in the BIP software, it is hardcoded somewhere to use bipulisher as the name.

Wait until the deployment finishes successfully, and then validate the new context root(In our case, it should be btmreport)

In order to validate the link, we could go back to application console and take a look at the new deployment details:

Go under the configuration of the deployment btmreport and go to testing to view all the links:

(By default the xmlpserver port should be 9704. In my envrionment, I set it to 9500)

Anyone knows how to keep xmlpserver undeployed but deploy a new btmreport application under bipublisher?

Advertisements

10 thoughts on “Change Context Root for xmlpserver on 11g BI Publisher

  1. A BI Publisher report containing pie & bar charts was created in Oracle BI Publisher version 11.1.1.6.0.
    We downloaded the corresponding .xdmz and .xdoz files.
    These files were then uploaded in Oracle BI Publisher version 11.1.1.7.0.
    We regenerated the sample data xml file, which was generated successfully.
    But while running the report from the server itself, the charts are not displayed correctly.
    The slices in the pie charts and the bars in the bar charts are not as per the sample data saved/passed.
    Even while invoking this report from java, the same issue is faced.
    No specific error is occurring.

    Your guidance is highly appreciated.

    Thank you.

  2. Hi,
    Thanks for the excellent post. I followed the steps mentioned and I could change the context root as mentioned above

    But I’m unable to login to BI Publisher using the new link? Any idea why I’m not able to login?

    Thanks
    Kart

    1. Hi, Kart

      What was the behavior of not being able to login to BI Publisher? Did you get to the log in page but just could not log in with the username and password which flashed out on the page?

      You could use fiddler to check if the credential sets have reached server or not. Did you set the correct cookie path?

      If none of the above apply, try restart OBIEE entirely and see if it gets any better.

      Claire

      1. Hi Claire,

        Yes I’m getting the login page. But could not login with my weblogic username and password.

        Cookie path? Can you please give me more details on this please.

        I tried restarting the entire server but its not working.

        have you done any additional steps after the ones mentioned above?

      2. Hi, Kart

        I didn’t have any additional steps. The whole process has been explained in the current post and verified on both 11.5.0& 11.7.0. Since you mentioned about you could see the login page. That means you have set the correct context root.
        One question I would love to ask you is that — back on my post, I asked you to modify the weblogic.xml. And for the cookie path name tag, I asked you to change it to the same name as the context root. Did you do this?
        To check the behavior of whether your credential sets have been validated on the server side, you could either user a web debugger like fiddler to monitor the traffic or check the log files under bi publisher to see if the request has reached the server.

        Claire

  3. Hi Claire,

    I logged a ticket with Oracle support and they don’t allow or support of changing the context root to anything else!!!

    In my case, once I changed the context root, the OBIEE and BIP integration was no longer working and function!…if you login into OBIEE and try to go to the BIP report, it did not work!…Is this working for you?

    1. Hi, Frank

      Yes, I tried to connect oracle about this before I came up my own solution. They didn’t have a solution with it and my clients would try really heard to push us to implement a flexible context root. So far, my solution has been tested very well and if you read through my blog. You would find that you have to deploy a new BIP server. You could not use the exsiting one since it was linking to all the old names “xmlpserver” I am also J2EE web dev so I am pretty familar with how to code the corresponding files. Like you said, oracle would not support this type of customization code. This blog is only a work around for my clients request. I previously googled on internet and no one has done anything similar but I got people consistently asking about this .So I thought sharing my research result would be beneficial for those who needs to get things done and are wilingl to take moderate risk.

      Best,
      Claire

  4. Hi Claire

    Great post! I appreciate it is not supported by Oracle but my client also needed this solution as we are running two OBIEE stand alone applications which have their own web servers (Microsoft Win2008 via IIS), which are accessed by the same load balancer. The second OBIEE application required a unique URL to avoid routing problems with the first server URL. The first server uses /analytics and the second server uses /analyticsrep, which was changed from /analytics originally (I used your exact context-root method above to do it).

    Everything appears to be working fine except the Export to Excel 2007+ option doesn’t work anymore since the context-root change (export to Excel 2003 is working fine). Using Fiddler suggests an invalid path error so I suspect the /analyticsrep url path is causing the issue. I realise your changes were for BIPublisher but have you come across this issue? Do you have any suggestions for a fix or further investigation? Ideally, I would like to know where is the application code that fires the “saw.dll?downloadexcelfile” excel command and path variable?

    See Fiddler captures below when I hit the Export to Excel 2007+ link on a dashboard report:
    1) Development environment working fine as it still runs under /analytics:

    GET /analytics/saw.dll?downloadExcelFile&d=R1egTl8vl8eCfHq0uZndAw&ItemName=Post%20speciality%20by%20trust%20outlier%20summary%20v2 HTTP/1.1

    2) Test environment using /analyticsrep and not working:

    GET /analyticsrep/saw.dll?downloadFile&path=zjSkIwtD4hRc3l49VY7Qpg&name=Post%20speciality%20by%20trust%20outlier%20summary%20v2 HTTP/1.1

    Why is “downloadfile” being used instead of “downloadExcelFile”? Any help is very much appreciated.

    regards
    Ian

  5. Hi, Lan

    You said exporting to 2003 was working fine. Did you use fiddle to intercept the request and see if it is coming from downloadFile or downloadExcelFile for analyticsrep?

    I would guess that since downloading file to 2003 was supported in 10g. They didn’t modify the legacy code which means “downExcelFile”(still adopted in 11g) but instead write new method “downloadFile” to handle the downloading to 2007.

    You could either try the link below and see if you could customize your download link.
    http://obieeil.blogspot.com/2014/02/obiee-custom-export-to-excel-link.html

    And also check this post, I think you might be able to manage your link as an external link.
    http://total-bi.com/2011/02/external-files-obiee-dashboard/

    Good luck,
    Claire

  6. Hi Claire

    Thanks for your reply and suggestions. Unfortunately, the two customisation methods you linked to are not practical as they rely on customising all of the dashboard pages and reports and we have hundreds.

    However, I have realised what the problem is and fixed it. Basically, I had taken mistakenly used vanilla analytics.ear file and modified the context-root etc as per your instructions. Its really obvious now but the Excel 2007 issue was an Oracle bug fixed by a patch and of course I lost all the patches by reverting the ear. Therefore, all I have to do is reapply the patches. I suspect all patches will need to be removed first and reapplied.

    regards
    Ian

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s