Home >Documents >White Paper - Siebel BI Publisher Integration Concepts

White Paper - Siebel BI Publisher Integration Concepts

Date post:19-Nov-2014
View:607 times
Download:7 times
Share this document with a friend

Integrating with BI Publisher release and earlier, requires wrapping of the Siebel Web Service with Java code so that it appears as a Web Service with the desired parameters as simple type parameters. This is because Siebel CRM exposes web services with complex type parameters and BI Publisher does not support web services with complex type parameters - it does support web services with parameters of simple type.

BI Publisher and later supports complex type Web Services as a data source and therefore you do not need to complete the java wrapping step. http://download.oracle.com/docs/cd/E10415_01/doc/bi.1013/e10416/bip_misc_10134.htm# BABIJJHD For details on the BI Publisher web services available see the following document section 23 Oracle Business Intelligence Publisher Web Services: http://download.oracle.com/docs/cd/E10383_01/doc/bip.1013/e10416/bip_webservice_1013 31.htm#CHDGIJHH In all cases when configuring BI Publisher reports using Inbound Web Services to Siebel it is recommended that BI Publisher or higher is used.

Integrating Siebel CRM with BI Publisher reports is simple when using SQL based report generation. SQL based reports are easily created in BI Publisher and can retrieve data from the Siebel base tables. It is also possible to pass through parameters from the Siebel application to a SQL based report (i.e. pass a ROW_ID for the current selected Siebel record into the SQL statement).

Note that writing SQL based reports against Siebel CRM can be difficult if you need to restrict user access to the data. The out-of-the-box view and position based visibility used by Siebel CRM can be very complex to write manually. For this reporting requirement a Siebel Web Service is preferable, since visibility and other business logic is preserved by the underlying Integration Objects.


The high level steps to retrieve data from the Siebel application using BI Publisher and Inbound Web Services are detailed below. Note BI Publisher will need to be licensed to use it with Siebel CRM. 1. 2. 3. 4. 5. 6. Configure an Inbound Web Service in Siebel. Set the address and modify credentials to use ClearText. Generate the Siebel WSDL. Test the WSDL and endpoint using SOAP UI or similar to ensure a valid connection returns data. Modify the Siebel generated WSDL (to specify mandatory fields) so it can be used with BI Publisher. Create a new BI Publisher report with a Web Service connection using the edited WSDL. Add parameters as required. Add the ResponseData XPath parameter value if you wish to view the report output in other formats such as PDF. The ResponseData XPath parameter is available after the release. Upload a report template.


Here are detailed configuration steps in the Siebel application using the Account entity as an example: 1. 2. Ensure the Siebel Server is running and the EAI component group is enabled. Go to Site Map > Administration - Web Services > Inbound Web Services and query for example, WC_Account_BS in the Name column.



Under Service Ports in the Address column add the following URL for the Secure WSDL for example: http://siebelhost.siebel.com/eai_anon_enu/start.swe?SWEExtSource=SecureWebServices &SWEExtCmd=Execute siebelhost.siebel.com can be replaced by any host provided it has EAI running.


For Operations of the Web Service set the Authentication Type Username/Password clear text for the Execute and QueryPage method.


Now we can generate the WSDL by pressing Generate WSDL on the top of the Applet.

It is important to test the WSDL and endpoint using SoapUI or similar application to make sure the WSDL returns data.


To ensure the WSDL generated from Siebel is correct, use an application such as SoapUI to test the endpoint. 1. 2. 3. Open SOAP UI and start a new project. Enter the WSDL path to the Siebel generated WSDL file. Expand the tree and method WC_Account_BSQueryPage Double click on Request. Replace the text in the window with the following example:-


Edit username/password and click the Green arrow to run the SOAP request.



If you are getting connection errors the SOAP endpoint at the end of the WDSL might be incorrect. You can easily test a new endpoint and test the connection. Change the WSDL if the endpoint is invalid:-

Once the endpoint and connection have successfully been tested with a sample SOAP request, the Siebel generated WSDL needs to be edited for use with BI Publisher.


The WSDL file generated from Siebel has to be altered for use with BI Publisher. The way BI Publisher works with Siebel Web Services is to parse the WSDL and then obtain the list of fields to be used in conjunction with the filtering parameters. For example, if the parameter is Account Name in the Siebel Web Service, we allow a user to modify the filter value to generate a different query for the report based on the parameter. The WSDL generated from Siebel can contain thousands of optional Integration Object fields, which can cause BI Publisher usability issues. For example, from Siebel's WSDL definition, if the SOAP request only allows non-mandatory fields, the WC_Account_BSQueryPage only has one mandatory field, which is:

This field alone is not sufficient to query Account. If non-mandatory fields are generated from the WSDL, then there would be thousands of non-mandatory fields and attributes the in SOAP Request. All these fields are translated in BI Publisher as editable fields on the UI data source. It would be very hard for a user to scroll through all these fields.


All fields that are required for use in the report need to be set to mandatory in the WSDL. In order to make a few fields mandatory, you need to edit the WSDL generated from Siebel. To make a field mandatory we set the minOccurs parameter from minOccurs=0 to minOccurs=1. In this example, the Account list object and two related fields are set to mandatory for use with a BI Publisher report that uses Inbound Web Services. In order to make the "WC_Account_BSQueryPage_Input" element that contains "ListOfWc_Account_Io" fields as mandatory, we change the WSDL as follows:


Fields related to the Account entity are under the Account element:-



Once we have located this section of the WSDL, to get fields from Account we need to make ListOfWc_Account_Io mandatory, scroll down a bit and make the change below.


Next step is to make the Account element mandatory.


We can see from the WSDL that WC_Account_BSQueryPage has "xsdLocal3" as namespace, so all the related fields should have a prefix of "xsdLocal3:". To include fields in the report output, set them to mandatory. Make the Name field mandatory for xsd:string and also xsdLocal3:queryType:



If the endpoint needs to be edited, this resides at the end of the WSDL e.g.

By sending the request with the mandatory Integration Object fields to Siebel, the query result will include those defined Integration Object fields. For example, in query request, if we send "Name" as the query field, then the result would include "Name". Otherwise, the "Name" field won't exist in the result.

Once the WSDL file has been edited, we can use it with BI Publisher.


To create a report in BI Publisher that uses Inbound Web Services, follow these steps: 1. 2. 3. 4. 5. 6. Login to BI Publisher and create a new report Create datasource as Web Service Select Complex Type as True, WS-Security = 2002 Enter Username/Password credentials Type in WSDL URL location (select the WSDL xml file) If required, set the ResponseData XPath parameter accordingly for example:/WC_Account_BSQueryPage_Output/ListOfWc_Account_Io

NOTE: The "ResponseData XPath" parameter only appears after the release and it is necessary if you wish to render a report in certain formats, e.g. PDF. If you don't specify a value for this field, then the Web Service data source is determined from the SOAP response generated from the Siebel Web Service, which starts from the SOAP response root element. The reason for specifying "ResponseData XPath" is for the RTF template to render the report data. The RTF template renders the XML data from the root level. Viewing the report in data format does not require the XPath parameter, because it always should generate report data in XML format. However for viewing a report in PDF format, the RTF template has to be used to render the report data and without the root element, the report won't be able to generate in this format.

7. 8. 9.

Pick the right Web Service Pick the right Method i.e QueryPage Parameters will be automatically filled in for you from the WSDL. If the mandatory fields/parameters do not have a value then an error will be displayed when running the report. e.g. ensure the Record Count, Page Size and Start Row Num have values.


NOTE: When navigating between pages within BI Publisher always click the Save button to make sure any edits/values are not lost. Sometimes this can happen when navigating away from the Data Model > Data Set page because the values are loaded from the WSDL each time this view is accessed.

10. Default parameters can also be added in left menu pane to appear at runtime on the report.


11. Save, and execute the report by clicking the View button. Click View to see the Data output, you can enter dynamic query strings for the report as shown in the image below:

In the image above a value for the Search Spec parameter has been specified [Name] LIKE A*. It is also possible to enter default values, for a field parameter i.e. LIKE A* for the Name field.

If no

Popular Tags:

Click here to load reader

Embed Size (px)