All software products should work 100%, 100% of the time. We get that and we try to hold BITeamwork to that same mantra. Every now and then an un-certified configuration, a custom modification, or an incorrectly adjusted configuration setting happens. And, thus is life. We know BITeamwork works just as it has been certified. So, this document is here to ensure that some solutions to common issues are easily accessible.

If you have a more complex issue, we hope that you are an Enterprise Edition customer so that we can support you fully. You can also try accessing our support site for further assistance beyond this document.

Once BITeamwork is installed it should render in the browser if the installation instructions are followed correctly.

If you are using Internet Explorer there is a possibility that users do not see the BITeamwork collaboration pane or the BITeamwork toolbar that shows in the OBIEE Global Header. This is mainly caused by the Compatibility Mode settings found in Internet Explorer 8+. As described in this Microsoft document on IE Compatibility, using Compatitibility View in Internet Versions 8+ renders the browser with support for Internet Version 7. Internet Explorer 7 is NOT SUPPORTED by BITeawork and this is the cause of BITeamwork not showing in an Internet Explorer 8+ browser.

To quickly test to ensure that BITeamwork is installed correctly, simply use a different web browser such as FireFox or Chrome to see BITeamwork components render which will validate that BITeamwork is correctly installed on your BI Server.

IE browsers often have global settings configured by the Network Administrator which are not reconfigurable by the individual employee/user using the browser. We've often seen that during testing of BITeamwork, the Intranet settings and Intranet settings of the browser are configured where the Intranet settings are by default set for all Intranet websites to have Compatibility View turned on.


  1. Use the Internet Explorer tools > Compatibility View Settings
  2. Uncheck the box for Display Intranet sites in Compatibility View in the Compatiblitiy View Settings prompt
  3. Click the Close button

If you receive an "Invalid or Expired Session" response when using BITeamwork to submit or receive information from Salesforce Chatter the reason for this is that your session has expired on the Salesforce Chatter Social Vendor portal. This is a default setting configured by either you or your Salesforce Chatter administrator.

Extending Chatter Session Timeout

  1. Navigate to the portal and login
  2. Click on your name in the upper-right corner of the page to expose the dropdown menu
  3. Navigate to Setup > Security > Controls > Session Settings
  4. Update the Session Settings to reflect your general corporate standards or extend the length for sanity of users

This indicates that the user attempting to create the bookmark does not have the appropriate permission to create a bookmark. Because bookmarks in BITeamwork are based on inherent Oracle BI controls the Oracle BI privilege for creating bookmarks must be set for the user attempting to do so. The ability to create bookmarks was first released in BITeamwork version 1.5.

This indicates that the BITeamwork system is having an issue connecting to the Oracle BI Server. Common causes for this is the URL value entered in the Web Services section of the BITeamwork console is either incorrect or the IP address or network name of the server is not pingable or not pointing to the correct Oracle BI server.

In order for the BITeamwork privileges to work properly, the Web Service Configuration section of the BITeamwork administration tab in the Oracle BI Administration page must be configured. Once configured the Sync Manager section of the BITeamwork control panel must then be accessed to run the "Refresh Application Roles" sync. After the sync completes, the BITeamwork administrator may then manage the BITeamwork Privileges.

Upon initial installation of BITeamwork the Manage Privileges section of the BITeamwork Management Console will appear as below.

Getting the Application Roles to show:

  1. Navigate to the Web Service Config section
  2. Update the Web Service URL path and input the credentials of an Oracle BI administrator account having the BIAdministrator Application Role

    The account really just needs privileges to the SOAP protocol which is managed in the OBIEE Manage Privileges page

  3. Navigate to the Sync Manager section
  4. Click the Sync link button by Refresh Application Roles to begin the sync with the Oracle BI Web Service
    • A status prompt will appear when the sync is finished
  5. Navigate to the Manage Privileges section
  6. Begin or Continue with the BITeamwork privilege security assignments

It is possible for your authorization access for communicating with Salesforce Chatter to expire. In this case, you, as a user, will need to refresh your authorization with Chatter from BITeamwork. Simply follow the instructions or the navigation links shown to you from the BITeamwork panel to refresh your Chatter access.

You may notice that as you are prompted with any messages and actions to refresh your Chatter access that one or more feeds or items may not have loaded. This again is due to your Chatter access requiring a refresh.

BITeamwork leverages the Java Persistence API (JPA) for scalability and enterprise architecture to comply with JEE standards and best practices. Part of the application leverages JPA 2.0 protocol functionality which WebLogic Server 11g supports only partially. Although these functions are supported, WebLogic still finds the need to warn about the usage and does so repetitively in the output log files of the Managed Server on which BITeamwork is deployed.

This version of OpenJPA cannot read a persistence.xml document with a version different from "1.0". Found: version "2.0" in "zip:G:/Oracle/FMW/user_projects/domains/bifoundation_domain/servers/bi_server1/tmp/_WL_user/BITeamworkOBI11g_1.6.20130121.319/a5ty1j/war/WEB-INF/lib/_wl_cls_gen.jar!/META-INF/persistence.xml".

The warning appears as in the image below:

Figure openjpswarning_1

There warning causes no issues and does not disrupt service of the Oracle BI 11g application or the BITeamwork application or functionality. No fix or specific ability to turn this warning off at present time exists. Oracle BI 11g will remain with WebLogic Server 11g for the foreseeable future so this warning will most likely always be present while operating BITeamwork.

We believe this issue to have been resolved with the release of BITeamwork 2.0 which would remove the need to make any adjustments outlined in this section. This is believed to be an orm.xml solution fix.

BITeamwork leverages the Oracle BI 11g web services in order to dynamically access the Oracle BI Web Catalog via Oracle BI Presentation Services. Doing so requires a Presentation Services, controlled by OPMN, to be running and online in order to connect for this access.

Below is a snippet of the error that is encountered when BITeamwork attempts to access these web services but the Oracle BI Presentation Services system components are not running:

10:42:03:783 EST 2013/02/22 [WARN] AccessPrivilegeManager - Exception Trying to Run Main Access Check: HTTP transport error: Socket Closed < HTTP transport error: Socket Closed> HTTP transport error: Socket Closed at at at ( at

Make sure that the Oracle BI 11g Presentation Services system component is started.

BITeamwork connect to multiple Social Vendors and does so through standard HTTP/S protocols. If your network firewall is currently blocking certain IP address ranges or simply restricting access to certain external Intranet sites then this becomes a problem when integrating with any Social Vendor.

This is not a problem with BITeamwork. It is simply a problem with network accessibility that is most often resolved by having your network administrator open access to the Social Vendor URL or whitelist of IP addresses
List of social vendor Whitelist IP Address.

Problem Scenario:

  • The social vendor configuration has been completed in the BITeamwork admin control panel
  • You've refreshed the user logged in via the BITeamwork collaboration panel
  • Using the link to Authorize Chatter, you login in the login prompt and are return a "Success" message stating BITeamwork is connected
  • Upon closing the login prompt window you notice the BITeamwork collaboration pane does not show the Chatter feed even after the page is refreshed
  • Upon checking the BITeamwork.log after setting BITEamwork to "debug" mode, you notice a message similar to the one in Figure chatterfirewalled_1

    The warning appears as in the image below in the BITeamwork log:

    Figure chatterfirewalled_1


  1. Contact your Network/System Administrator at your company
  2. Provide her with the login URL that you use to login to the Social Vendor application and the whitelist IP list
  3. Continue to work with your Network Administrator until the issue is resolved
  4. If the issue persists, please contact BITeamwork support

Oracle Weblogic Server - Version 10.3 and later has an issue where it outputs this message for any application deployed to a WLS managed server using JPA technology that is not OpenJPA. This is an erroneous message and unfortunately is used at the INFO log level of the WebLogic Server. BITeamwork will spawn this message from the WLS server every time a database read or write is made to retrieve collaboration information so these messages could be plentiful in the WLS log file of your implementation.

The full message is:
INFO: Found persistence provider "org.eclipse.persistence.jpa.PersistenceProvider". OpenJPA will not be used.

Solution / Fix
This is a documented issue on Oracle Support (ID 1465271.1). There is also reference to it in Oracle Support IDs: 1058474.1 and 981264.1.
In order to fix this you would need to change/filter the log file by using the instructions found in the Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server documentation

This solution has been documented in step-by-step fashion on this Art of Business Intelligence post.

We believe this issue to have been resolved with the release of BITeamwork 2.0 which would remove the need to make any adjustments outlined in this section. This is believed to be an orm.xml solution fix.

By default the WebLogic Application Server does not enable wildcard SSL handshakes. As such, the WebLogic Server administrator must configure the server to enable this required configuration for communicating with social vendors.

When BITeamwork communicates with, a secure "handshake" takes place. That is to say that each server states who they are upon request and response. This ensures that the same servers complete a successful communication and eliminates any possibility of a "man in the middle" communication disruption. In June 2013 several social vendors changed their response URL during this handshake to use a wildcard certificate (* instead of the full DNS ( While this saves the social vendor money in regards to how many full DNS SSL Cerficiates they must purchase and maintain, it has caused a bit of disruption with the WebLogic Server which disables wildcard SSL verification by default for security purposes even though this protocol is completely safe and an industry standard.

Solution for WebLogic Server 10.3.5

  1. Login to the WebLogic Server Administration Console for the Oracle BI 11g implementation.
    • This by default, http://<bi_server>:7001/console
  2. From the left navigation Domain Structure menu, expand Environment and click Servers.

    Figure wls_wildcard_ssl_1
  3. Click on bi_server1 under the Servers table in order to access the managed server configuration
  4. Click on the Configuration tab and then the SSL sub-tab to access SSL configuration information.

    Figure wls_wildcard_ssl_2
  5. Click on the Lock & Edit button under the Change Center.

    Figure wls_wildcard_ssl_3
  6. Expand the Advanced section at the bottom of the SSL sub-tab configuration page. Expand the Hostname Verification dropdown menu and select None.

    Figure wls_wildcard_ssl_4
  7. Click the Save button towards the top of the SSL sub-tab configuration page.
  8. Click the Activate Changes button under the Change Center.

    Figure wls_wildcard_ssl_5
  9. Repeat steps 3 through 8 for each instance of the bi_server# where BITeamwork is deployed.
  10. Done.

Solution for WebLogic Server 10.3.6

In version 10.3.6 of WebLogic Server, an option to allow wildcard SSL verification was implemented. This option should be selected in order to solve the problem detailed at the beginning of this section.

Follow steps for the WebLogic Server 10.3.5 and substitute step #6 with the following steps:

  1. Select Custom Hostname Verifier from the Hostname Verification dropdown menu.

    Figure wls_wildcard_ssl_6
  2. Input the text, in the Custom Hostname Verifier field.


  • Oracle Support Notes