BI Publisher Integration

Welcome to the world of BI Publisher. BIP reports can be soother for those who are bitten by actuate. Architecture wise both works same but the key ease is in the development of report template for BIP. A typical comparison between Actuate and BIP is depicted below.

With Siebel 8.1.x.x release and BIP Enterprise server 10.1.3.4, we have tightly coupled integration with BIP reports just like actuate. However users on earlier versions can still avail benefits of BIP reports. Reports can be written in BI Publisher using web services or SQL to retrieve data from the siebel application. The reports can be executed from siebel application on button click with flexibility of passing parameters at run time.

The attached document from oracle unearth the secrets of executing reports.

Happy Reporting!!

Authentication for Siebel Reports

The best part from oracle is they keep coming with patches and tough part is we need to adhere them. In siebel 8.0 we were not having built in integration with BIP reports so one has to resort to either web service call or SQL strategy for executing BIP reports. With advancement of 8.1.x we have tightly coupled integration with BIP reports.

With integration comes authentication. Typically there are several options to choose for configuring security and authentication for Siebel Reports. When using WebServices or SQL based reports generally "Web Single Sign-On Authentication" mechanism is used as it requires Users logging into BI Publisher via its administrative interface.

However this authentication fails when one is using integration based approach which comes with Siebel 8.1. Since the release of Siebel 8.1.1.1 and BI Publisher 10.1.3.4.1 a new security model is introduced in BI Publisher, Siebel Security. When using the Siebel Security model, BI Publisher relies on Siebel for its authentication and authorization. This is primarily used for IO based reports. But now the question arises if we want to run webservice/sql based reports in conjunction with tightly coupled BIP reports which authentication to go for.

The intermediate solution is LDAP authentication which supports both types of reports in conjunction. The key points to implement here are:

1) Users logging into Siebel sould be authenticated via LDAP

2) Any reports requested by Siebel users and executed in BI Publisher should cause BI Publisher to request authentication via Siebel (and hence indirectly via LDAP). This will be for Tightly coupled IO based reports.

3) Users logging into the BI Publisher administrative interface sould be authenticated via BI Publisher’s own LDAP authentication mechanism. This will be for reports based on the WebServices or SQL.

However, The BI Publisher LDAP Security model has one disadvantage, it requires hardcoded LDAP Security Groups like XMLP_DEVELOPER,XMLP_ADMIN. BIP gurus can definitely throw more light on this.

Happy Reporting!!

Different Query Mode in Edit List

I crunched one. This post is an addendum to one of my previous "Food for Thought" post where the main challenge was to display different columns in Query Mode when applet is displayed in Edit List Mode. with some configuration-Scripting-Luck i am able to achieve this scenario.

The key ingredient here is the usage of Dynamic Toggle. Following necessary steps are required to achieve desired solution.

1 - Create a clone of the list applet which should be displayed in Query Mode. Remove unnecessary Columns which are not required to be displayed while querying. Consider two applets are:

a) SR List Applet

b) SR Query List Applet

2 - Make the "SR Query List Applet" as the default applet to be displayed in the view.

3 - Create a calculated field in the Service Request BC with following values:

Name: QueryCalc

Value: IIF(GetProfileAttr('QueryMe') = 'Y','Y','N')

4 - Now create a dynamic toggle in the "SR Query List Applet". Set the "SR List Applet" as toggle applet with following Value in the condition.

Auto Toggle Field: QueryCalc

Auto Toggle Value: Y

5 - Once toggle is created, its time to set Profile Attribute. Following piece of code is required in below applets:

a) SR Query List Applet

Following script is written to toggle to SR List Applet.

function WebApplet_PreInvokeMethod (MethodName)

{

if(MethodName == "ExecuteQuery" || MethodName == "UndoQuery")

TheApplication().SetProfileAttr("QueryMe","Y"); //This is used to toggle back to Applet with More Fields

}

function WebApplet_Load ()

{

TheApplication().SetProfileAttr("QueryMe","Y"); //This is used to toggle back to Applet with More Fields

}

b) SR List Applet

In this applet we will create our own custom method and will invoke NewQuery.

function WebApplet_PreInvokeMethod (MethodName)

{

if(MethodName == "TestQuery") //Instead of Query We are calling our own custom method. Test Query

{

TheApplication().SetProfileAttr("QueryMe","N");

this.BusComp().SetSearchSpec("Id","");

this.BusComp().ExecuteQuery();

this.InvokeMethod("NewQuery");//New query is executed on the default applet in the view

return(CancelOperation);

}

}

The key here is to execute a blank query and then do New query so that the default applet in the View appears,i.e. the SR Query List Applet. Compile the objects and look out for super cool stuff. Siebel Rocks!!!

Disclaimer: There are caveats in this approach. This should be thoroulgy tested before you implement in your scenario.

Happy Crunching!!

SecUsernameFieldSubstitution - User Property

Issues are inevitable as sugar and cholesterol.

In my recent heist in configuring recipient groups i was dumbstruck with some untold user property. We wanted to add Person as recipient group for Service Request. As per siebel support we added desired values in the "COMM_RECIP_SRC" LOV table. Email started to flowing using this recepient group. But the interesting part is "Person" BC is not defined with the Recipient* user properties instead of that only one user property is defined as

Name - SecUsernameFieldSubstitution: EMail Addr

Value - Email Address

Unknown of its usage thought of throwing this to siebel forum. A little insight on this user property will be of great help.

Happy Cracking!!

Popup visibility - Division Based

It is very critical that one should have appropriate access to information available. Thus siebel has given comprehensive access control mechanism which helps in restricting data visibility. We can have visibility filter at multiple levels including View, Business Component, Picklists, Drilldowns, Links .

However the modes which we can set is restricted to following values:

All

Personal

Sales Rep

Manager

Organization

Sub Organization

Group

Catalog

Recently i was asked to have a visibility control based on the Division during the assignment of Service Request. One should see employees related to his division only when he opens employee pick applet.

We opted for Personalization to implement this as it gives a flexibility to change the filter dynamically without any srf change. Steps required are:

1 - Set the Popup Visibility Type to "All" for employee buscomp. (Please check before doing this as this will impact all Picklists based on Employee BC)

2 - Create a Personalization Rule set for "Employee Pick Applet" with below Include Expression:

"EXISTS ([Division] = GetProfileAttr('Division Name'))"

where "Division Name" is the division of Primary Position which is pulled in Personalization Profile BC using join. However this approach fails when user has got multiple positions and he changes the active position from "Change Position" View via User Preferences. In such scenarios we need to set/reset Profile attribute after Change Position is executed.

Happy Configuration!!

Hidden Methods - UpdateRecord

Siebel is mysterious. Along with those magical user properties there exists hidden methods that can do wonders for you. It is a real Archimedes-Eureka-Feeling when we encounter any of these hidden methods in siebel.

Recently i was struggling with Update Siebel Operation Step in Workflow with some context issue till i found "UpdateRecord" hidden method for "Inbound E-mail Database Operations" business service. This method is not displayed in the available list of methods for this business service but however can be comprehensively used in the workflow (we can verify with Business service simulator).

Usage:

Business Service: Inbound E-mail Database Operations

Business Service Method: UpdateRecord

Method Argument:

BusComp - Name of the Business Component

BusObj - Name of the Business Object

Id - Row ID of the record to be updated

Field: FieldName1 - Value to be updated

Field: FieldName2 - Value to be updated

Field: FieldName3 - Value to be updated

The only curse with usage of these methods is if Id is not valid it throws error in processing.

Happy Configuration!!

Cursor Modes for ExecuteQuery

Ignorance is bliss.A lot has been written about the cursor modes when using ExecuteQuery method. As a general rule by birth we are told, when using the ExecuteQuery method in scripting, the recommended cursor mode is ForwardOnly if there is no need to step backward through the result set.

But ForwardOnly cursor mode should not be used in a user interface context, for example, when the business component being queried is displayed within an applet of the current view.

I was victim of this ignorance. We had a requirement of querying on the EBC based on the query spec we get from other applet in the view. I have added ForwardOnly mode in the executequery method and to my horror query results were always returning only one record in the applet. Turning on the ForwardBackword cursor mode in the ExecuteQuery method fixed this isssue. The issue was When accessing database records with a cursor mode of ForwardOnly, only one record at a time is retrieved and kept within the Siebel Object Manager memory as a result only one record was being displayed as query result. When using ForwardBackward cursor mode, all of the qualifying records were retrieved.

Happy Crunching!!