Siebel: Script Libraries

Siebel 8 (or ST engine to be more specific) has a elegant way of calling business service methods. Script libraries provide the ability to call functions on a business service directly, no more is the need for building property sets and setting the parameters!

If you have not already used script libraries, do take a look. The reduced coding implies lesser mistakes, debugging time and easier maintenance! The simple demo below illustrates the usage.

Step 1:
Create the target business service 'COG Test Script Lib'. A custom function 'Echo' is defined here.

Service_PreInvokeMethod:

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)

{

return (CancelOperation);

}

Echo:
function Echo (MyString)

{

return "Echoed: " + MyString;

}

Step 2:
Create the caller service 'COG Test Script Lib Call'. There is only one method here - 'Service_PreInvokeMethod', and the following code has to be input:

function Service_PreInvokeMethod (MethodName, Inputs, Outputs) {

var bsTest = TheApplication().GetService("COG Test Script Lib");

Outputs.SetProperty("Output", bsTest.Echo("abc"));

bsTest = null;

return (CancelOperation);

}

Compare this to the approach in earlier versions. In most probability you will be coding something like:

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)

{

var bsTest = TheApplication().GetService("COG Test Script Lib");

var psIn = TheApplication().NewPropertySet();

var psOut = TheApplication().NewPropertySet();

psIn.SetProperty("MyString", "abc");

bsTest.InvokeMethod(psIn, psOut);

Outputs.SetProperty("Output", psOut.GetProperty("ReturnString"));

psOut = null;

psIn = null;

bsTest = null;

return (CancelOperation);

}

And, don't forget to add a line or two in the target service 'COG Test Script Lib' to set required properties in the output propertyset. Now, a simple 'bsTest.Echo("abc")' does the job. Isn't life simpler?

Siebel: Prototype in eScript

I had mentioned about using prototypes in one of the previous posts, here's a drilldown into how things work.
Tucked away in a remote corner in the eScript reference of the Siebel Bookshelf is a single paragraph referring to prototypes. Common to javascript developers, prototype is not something that we bother about too often. Prototypes provide a highly reusable way of extending out of the box objects, with an optimal memory usage as a bonus.

How do we use Prototypes?
The best way to understand will be through an example. Let us consider a problem where we need to add x days to the given date and get the next working day (!= Saturday or Sunday).
We go about this problem by extending the Date object to support a new functionality - add x days and retrieve the next working day. For simplicity sake we keep the definition of prototype and the actual call together, however they may be located in different objects as well.
To demo the prototype define custom business service 'COG Get Working Day' in Siebel Tools or Client. Paste the following code in relevant sections:
(declarations)

Date.prototype.AddDaysToGetWrkDay = AddDaysToGetWrkDay;

AddDaysToGetWrkDay

function AddDaysToGetWrkDay(iDays, Outputs)

{

var iDateNew; var iOneDay = 24 * 60 * 60 * 1000; // day in milliseconds -
(hrs/day * min * sec * ms)
this.setMilliseconds(iDays * iOneDay);
if
(this.getDay() == 0 this.getDay() == 6) { // if sunday or saturday

this.AddDaysToGetWrkDay(1); // add one more day and check whether that falls
on working day

}

return this;

}

Service_PreInvokeMethod

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)
{
try {
var dSomeDate = new Date("1/28/2011");
dSomeDate.AddDaysToGetWrkDay(1);
Outputs.SetProperty("New Date", dSomeDate);
return (CancelOperation);
}
catch(e){
throw(e);
}
finally {
dSomeDate = null;
}
}

When executed through simulator (or a call from placed from another service), the service returns the next working day - in the above example 31-Jan-2011. Read on to find out how.


Code Explanation

1. 'Date.prototype.AddDaysToGetWrkDay = AddDaysToGetWrkDay' is the statement that tells the execution engine that there is a new prototype for Date object, and the extended functionality is provided by the function (or object) called 'AddDaysToGetWrkDay'. This is not synonymous with calling a function since there is no actual execution at this point. It is equivalent to a declaration.
2. Next, define the function 'AddDaysToGetWrkDay'. This will act on the provided date object, which is referenced using 'this'. All it does is to add the given number of days to the date, check whether the new date falls on a Saturday or Sunday, continue adding more days if that is the case, and return the final date. Recursion is used to keep on adding days until it is not required.
3. 'Service_PreInvokeMethod' just calls the extended function 'AddDaysToGetWrkDay' against the date object. When the actual call is made, the scripting engine looks at the Date object itself to check whether such a method is present, and then consults the prototype. Since such a prototype exists and points to a function, the function is executed to return the result

Note that the prototype itself may be defined only once, and the functionality is available thereon. Though this example is simple at its best, it does demonstrate how prototypes can be used to extend the objects.

Conclusion

Keep in mind the following:

• Prototypes share the same memory space. Multiple invocations do not mean multiple copies
• Prototypes can also be added later. Dynamic invocation can mean that you don't need to do everything in one place and at once
• A prototype can also be extended further. For example, I can very well define another which says 'AddDaysToGetWrkDay.prototype.ExcludeDay' to selectively exclude certain days. For example, myDate.AddDaysToGetWrkDay(21).ExcludeDay("Tuesday") can return the working day 21 days from the given date, but which is not a Tuesday
• From the above point you can observe that the methods can be executed in a 'chained' manner, which gives us a scalable solution that is easy to maintain (remember my OO reference in an earlier post?)
• Use prototypes for reusable functions, that is when they yield better results

So, how do you want to use prototypes in your application?

Siebel: Custom Functions for TheApplication

If you want to reuse code in Siebel, one of the common practices is to put it away in the business service and invoke those methods. This method, though is invaluable for complex operations, will become a painful process for simple things. When I say painful, it applies in some measure for both developers and the execution engine, reasons outlined below:

1. Additional business service objects have to be created during execution, this may put some overhead in terms of performance (business service caching kept aside for now)
2. Invoking most of the business services out there involves creation of property sets and calling them in a "proper" way. With the increased lines of code comes the increased complexity
3. Developers have to "know" about the business service. This is a big problem in the longer term since code again gets littered everywhere inspite of the same functionality in a service
   There is a way to solve some of the above issues for simple reusable code (at least partially) - custom methods on TheApplication object. This uses a simple fact - all functions written in the application object will be available in any entity and method. Let us illustrate this with an example.

Problem: I need to get the description of a specified LOV. Though developers swear by LookupValue (and other Lookup) functions, there is little one can do about the 30 (or 50) char limit imposed by the data model. It is common to use Description (or some such field) for this purpose, but the code reuse is limited.

Solution: Write a LookupDesc function in the application object. Just edit the 'Siebel Life Sciences' (or any application) that is being used by your object manager. Create a new function called 'LookupDesc' and paste this code:

function LookupDesc(Type, Value)
{
try {
var sDesc = "";
var boLOV = TheApplication().GetBusObject("List Of Values");
var bcLOV = boLOV.GetBusComp("List Of Values");
with (bcLOV) {
ClearToQuery();
SetViewMode(AllView);
ActivateField("Description");
SetSearchExpr("[Type]='" + Type + "' AND [Value] = '" + Value + "'");
ExecuteQuery(ForwardOnly);
if (FirstRecord()) sDesc = GetFieldValue("Description");
} //with
return(sDesc);
}
catch(e) {
throw(e);
}
finally {
bcLOV = null;
boLOV = null;
}
}

Now, invoking the above function is by using a single line in applet, bc or a business service -

TheApplication().LookupDesc("MY_TYPE", "My Value")

This is also available in ScriptAssist against TheApplication, to make others aware of this function ofcourse!
A note of caution though - don't overdo this. I would recommend keeping the code here simple and tight, and to those functions where lot of reuse is foreseen.

Siebel: User Defined Objects

Ever missed all the OOP goodness in Siebel? Although not used frequently, user defined objects provide you with some degree of control with hiding complexities in scripting. No, this will not help you attain OO nirvana - but you can start doing things with the custom objects and prototyping (another post for another day) to:

• Hide complexity
• Provide scalability
• Save memory while doing the above

Here’s a simple example that demonstrates use of user-defined objects. To test, you simply copy the code in a new client business service and you are all set.
First the Service_PreInvoke method:

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)
{
var qryBC;

qryBC = new GetRecord("Contact", "Contact", "[Id] = '0-1'", "First Name", "Last Name");
Outputs.SetProperty("First Name", qryBC.Values[3]);

Outputs.SetProperty("Last Name", qryBC.Values[4]);

return (CancelOperation);

qryBC = null;
}

Next comes the constructor:

function GetRecord ()
{
try {
var arrValue = new Array();
var iCount;

if (arguments.length < 4) TheApplication().RaiseErrorText("I need minimum four arguments - BO name, BC
name, SearchExpr and at least one field name.");

var bo = TheApplication().GetBusObject(arguments[0]);
var bc = bo.GetBusComp(arguments[1]);
with (bc){
ClearToQuery();
SetViewMode(AllView);

SetSearchExpr(arguments[2]);
for (iCount = 3; iCount < arguments.length; iCount++){
ActivateField(arguments[iCount]);
}
ExecuteQuery(ForwardOnly);
}

if (bc.FirstRecord()) {
for (iCount = 3; iCount < arguments.length; iCount++){
arrValue[iCount] = bc.GetFieldValue(arguments[iCount]);
}
}
this.Values = arrValue;
} // try

catch(e){
throw(e);
}

finally{
arrValue = null;
bc = null;
bo = null;
}
}

Now, the explanation:
Purpose:

Provide ability to query any given BO / BC and retrieve the specified field values

How did we do that:

First, we create an object called “qryBC”, which becomes instance of a class “GetRecord” when the constructor “GetRecord()” is executed. Since this is the very first exposure to the class/object concept, we are letting the constructor do all the work rather than splitting it up. At this time we also pass the arguments to the object, whereby the constructor will query and return you the results. For simplicity in further processing, we return an array with the query results. Note the use of ‘this’ in the constructor and the reference to the set values when retrieving results in PreInvoke method.

Never understood why OO beats procedural programming you say? You need to depend your friend Google to find out what you missed.(cross posted elsewhere)

Fusion - at last

Well, the moment we have been waiting for is here - Oracle Fusion CRM finally finds the light of the day (so as to speak) in the recent Oracle Open World. This is a new technology framework folks, put on your best armour and start preparing for all new things coming your way. You can start with http://www.oracle.com/fusion! No, no downloads yet - you should satisfy yourself with the latest sales pitch. Alternately, you can take your frustration to the Siebel 8.3 Statement of Direction (available on support.oracle.com).

Back for good

I am back after a long time, had to attend to some serious issues that would have taken away my source of income. And this is not what you want to do in these times of recession.

I have seen a couple of more projects hence and still wonder what makes project teams tick? There are a few people around who actually like what they do for living. Day by day, project by project you see the same mistakes repeated often. The same review comments given out by Oracle and the flurry of fixes. Unless you have a tight grip on ALL configuration objects or have someone interested do it, you are pretty sure to go through the 25 pager that Oracle ES doles out for minor defects in 25 objects!

Anyway, here are a few must-do's in all Siebel projects:

1. Keep Configuration and Scripting best practices handy. Get the team to go through it at least twice and once more to make sure everyone knows the game
2. Quality is everyone's responsibility. Maintain strict traceability on customization and hold team members responsible for deviations. No, I do not mean to thrash them but make them correct mistakes. Pouring over the same code again is punishment enough
3. Appoint a elite review team consisting of 20% of team members. All "critical" development decisions (do we need a separate view or shall I use applet personalization in the same view?) have to pass through these guys. Also, make them directly responsible for all objects/code reviewed
4. Organize fun events every month or so during the development period and announce prizes for people who identify deviations from established standards
5. If your organization has internally developed a configuration review tool, use it frequently during development. If you have no such tool, it is good time to consider developing one

Ofcourse this is not a comprehensive framework, but something I have implemented in a few projects and regret not implementing them in a lot of projects. Do they indeed make sense? What other ways do you follow to sustain quality deliverables? Please comment!

Tackle Siebel Performance Problems

As you read this, try to recall how many times has this happened to you. The development team has slogged for more than a few days to produce a piece of art and deploy it in dev environment. Everyone's happy and within no time it is promoted to QA. If you have a “proper” QA, there is a big chance that someone starts complaining about performance of the new/existing view. First, you try denial and try to concentrate on more immediate issues at hand, but finally comes a day when you scramble to put together resources to resolve the problem.


I have been in more than a few projects and believe me when I say this – most project teams end up in the above situation, unless they have put in a process to tackle performance problems as part of their development process. And what do you know, the biggest surprise is not many teams do that. I believe the development team becomes so engrossed in their day-to-day work, no one really finds time to do anything except create, modify, fix and forget cycle. The real bad thing here is that performance problems have a cascading effect – they inflict major damage to user community in terms of positive mind share and that damage is not easily reversible. So, it's good to start early. Let us try to outline what can be done.


>> Control UI

A client I worked with had his users believe that a list applet can only contain 20 fields. Too many fields being pulled from too many sources may be good to look at, but are they really doing anything there? Could you accomplish the same using reports (preferably OLAP!), could you convince the user that an extra click can retrieve the data but that click is going to save him 2 seconds to view most wanted data?


>> Best practices are your best friends

Never under estimate best practice just because everyone echoes the same things. Never allow non-indexed searches, control searches using home page / find dialog / custom query applets, never have MVFs without primaries, index all foreign keys, do not script for something that can be accomplished in an alternate way, but at the same time do not be afraid of scripts when they can save a bunch of queries using Siebel operation steps in a workflow.


>> Use light BC

Some of the OOB classes are heavy and come with a cost. For example, order line item updates may fire numerous queries for repricing the order. The cost is decreased by a large magnitude just by using a clone BC based on CSSBusComp class and doing a reprice after all updates. It may be interesting to note that there are several cloned business components already available OOB in v7.7+, take a look around


>> Async it!

Evaluate whether your user may proceed with his work while you accomplish work in the background. For example, clicking on Submit button changes the order status and returns control to user, while working away in the background.


>> Don't cut slack with your review process

Examine and evaluate every join, every new field exposed newly on applet, every field that needs force-active or link-specification to be TRUE. Balance these factors against the performance trade-offs. For example, consider a one off query when you can afford it instead of just turning on Force-Active an d including the field in all queries


>> Put in a robust performance measuring mechanism

Measure performance before and after proposed changes. Do not talk in terms of time or number of seconds, always do comparison using consistent gets. These gets will tell you how much work the DB has to do for retrieving the data that more or less remains the same across environments and regardless of “how much” data is present or the load on DB servers.

What I miss from Siebel 6.0

I know that this title makes some people shudder. Siebel 6.0, they say, is only perfect as a historical showpiece. I beg to differ, at least till the time required to complete this post. Sure, I agree that Siebel 7 revolutionized things around here. If something is not browser based, I would not be taking any bets on the application mortality. Nevertheless, this should no way undermine the beauty of v6.0 application.

Release in the year 2000, v6.0 aka Siebel 2000, brought in more stability and looked better than the earlier versions. Also significant was the concept of “integrated channel management” – one application to manage your sales, marketing and customer service across channels incl. web, wireless and call center. A few features mentioned below makes one fondly remember of v6.0:

• First and foremost aspect - the architecture, client-server worked like a charm. No IE, no fuss, no security concerns and no worrying about the next security patch killing everything except the manager. No worrying about different components that are at the mercy of different machines and operating systems
  
• Performance – Any Siebel 6.0 developer would laugh off performance testing and happily do some more customization
  
• Less network bandwidth – Everyone used local mode most of the time and everything ran on the local machine anyway. Even when you are connected to server you only need to ferry the data between application and db
  
• Deployment bandwidth – Deploy with zero downtime – of the local application that is. Take your own sweet time to bring up the server and let the users synchronize over the following week
  
• Usability – Responsive, access all available views through the menu (who says Sitemap is the right way?), an intuitive search and lesser screen refreshes – try navigating to the next set of records in a list
  
• Looks – Apply windows theme and change the application looks, customize it to work on VGA or revert to the way v99 looked. Also, show or hide gridlines, alternate row background colours and customize your tool bar (through options set at the individual level, not through Tools)
  
• Extendibility – You want anything not supported OOB? – just write some script, no worrying about server/browser scripting and the server-client round trips
  

Sure, there are not many points - v6.0 was no match for the "CEM" attitude of today. But for a time it did successfully held & expanded the forte of Siebel through the 'difficult' period for IT in the year 2000. All said, I have no love lost with the latest and greatest v8.0. After working on v6, albeit for a short time, I enjoyed the transition into the web & party model of 7 (& the accompanying hiccups - it generated lot of work :)), the robustness of 7.5, all the extras in 7.8 (still think it should have been the next BIG version of Siebel) and the user friendliness and wow-so-many-features that symbolises 8.0. And yes, all hail Fusion - I will be ready for it, whenever it comes!

Siebel: Sensitizing Case Insensitive Queries

There was a time in the not too distant past - whenever users ask for certain fields to be case insensitive, developers had an answer - "look it's not like we can't or won't do it - it is just that the performance takes a beating". Now things look a lot easier.

The Problem

Siebel applications are case sensitive by default. Although we would certainly like to see them as another Google search - enterprise search was never really a Siebel forte (hold, I did not come to Siebel 8.0 improvements and Oracle Secure Search!). Now, searching for accounts or contacts would require the users to have a general idea or adhere to a framework of naming convention. An "ABC Company" here and "Abc Company" there, albeit a typo, result in frustration for the users. If you can have your whole application case insensitive you just turn on a switch and you lead a peaceful life. But unfortunately, not many of us are blessed with small databases or user-base and the kind of queries that requires users to take coffee-breaks are not encouraged.

Tackling case-insensitive queries assumed monstrous proportions in some implementations. Users have to get their work done. So there were a few work-arounds:

• Force case sensitive queries for desired fields by prefixing the queries with "~". Might have user-training problems, users are not happy with the extra typing (you have to really search for the damn character). Again, this might lead to the coffee-break problem, although in a much smaller scale
• Force a single case (like all caps) for certain fields like account or contact names. Again, not a beautiful solution, requires lot of user discipline

Then, there were developers - they have to maintain a certain level of user-satisfaction in the interest of their jobs and so were more work-arounds:

• Tell users to use ~ in their queries. Create indexes (like functional indexes) to manage performance loads
• Make selected fields case insensitive and manage performance through indexes
• Force case on fields and enforce user discipline
  
• And another interesting solution, which is now mainstream - enabling case-insensitivity through a redirection approach (you have to go through the entire article)

How Siebel Helps?

Enter CIAI (Case Insensitive and Accent Insensitive) wizard in Siebel 8.0. In there, we have a more streamlined way of dealing with enabling case-insensitive queries for specific fields.

What you do, as a developer, is pretty straight-forward:

• Select columns of interest
• Invoke CIAI wizard
• Select all indexes that need tuning
• Let wizard do it's thing

What you do, as a user, is more simple:

• You use the enabled fields to query - no case, no nonsense
  

What CIAI wizard does is not so simple:

• Change default insensitivity property to "DB Case & Accent" for the specified columns
  
• Optionally, create child columns that are same as parent (or previoulsy specified) columns except for the force-case part. In the background, all values are stored in one case
• Optionally, delete index including parent columns and recreate indexes for the child columns
  

Now, the object manager reroutes the queries on specified columns to the case-insensitive columns that in-turn use the case-insensitive indexes to return results that are case-insensitive. I bet you don't want to hear the term case-insensitive again (there you go!).

We can run CIAI wizard multiple times and even turn off the changes made in prior executions. Note that there are a bunch of prerequisites. More important ones - only certain table types like Data (Public/Private/Intersection), Extension etc. are supported and only char, varchar and CLOB data types can be configured for CIAI queries.

Interested to learn more? - Head to "Configuring Siebel Business Applications" in Bookshelf.

Siebel Architecture Roundup

Though we treat Siebel Architecture knowledge as the very basis on which we build more knowledge, it is surprising to find many people tongue-tied when answering specific questions about it. Here is my way of doing a roundup on the Siebel architecture – which actually implies that it is simplistic, useless other than to understand what goes on at a high level and ignores all complexities. This overview is a top-down look at what happens where. The highlight of this post may be this badly prepared diagram.

Core Components

First, a look at the various components involved. To start with, consider the most prominent client of them all – a PC web browser accessing the Siebel application server situated remotely.

 

Web server

Siebel application, in its present form, is nothing but an application server with add-on components to provide access, report & interact with other applications. Any application server needs a web server, which is the one that frontlines user fury. Siebel application is accessed by typing an URL in the browser. The URL (for e.g.: "http://crm.myorg.com/callcenter_enu"), consists of two parts - the IP/domain name for web server itself and the Siebel Web Server Extension (SWSE) instruction. SWSE is a component installed on the web server, which is responsible for identifying Siebel requests and forwarding it to the application server. In our case, SWSE will see the user request for the call centre application and forwards it to Siebel. The Object Manager will return HTML content, which is promptly routed to the browser through web server.

 

Important components here are:

• eapps.cfg – Configuration file that informs SWSE where to find the Siebel server and parameters like anonymous user details (required to display the login page), session time out parameters and the like
• Virtual directories  – Located in SWSE logical profile directory, these folders store files required by the various Siebel applications
• lbconfig.txt – Siebel native load balancer uses this file to recognize the various Siebel servers available and the components available on them

 

 

Aside:

• Web servers can be load balanced using hardware or software load balancers available in the market. The load balancing architecture also can be different from installation to installation. For a Siebel application developer, this is transparent
• Siebel itself can use native load balancing (version 7.7 onwards) or third party load balancing. While the former uses the lbconfig.txt directly, we can use the lbconfig information to write rules in case of load balancing using third party tools
• Take a look at the web server logs, it lists lot of URLs that let us understand how requests fly back & forth. All user requests are captured here
• Since SWSE is the gatekeeper for all user requests, it is the right place to go if we want to see the application performance in the last mile. In fact, SWSE provides a summary web page that lists the worst performing responses

 

 

Siebel Gateway (aka Name Server)

Any request forwarded by the SWSE to Siebel will pass through Siebel Gateway, which routes requests to various Siebel servers in the enterprise. A single gateway can serve multiple enterprises. Gateway keeps a tab on various Siebel servers in the enterprise and components available on the servers. This information is available in a volatile store depending on the status of various components. Requests for service will be routed to different servers based on which components are required to serve that request and where those components are able to take requests at that instant.

 

Important components here are:

• siebns.dat – All configuration information of Siebel servers is stored here. Siebel servers use this file at the time of start-up to find which components they have. Periodically the non-persistent information in the volatile store is dumped to this file

 

 

Aside:

• Gateway, though crucial, is not resource hungry
• When Gateway goes down, users are not kicked-out but no new logins are allowed. The existing users will not be able to start any new processes that have dependency on an external component
• siebns.dat file is notorious for data corruption, periodic backups as well as taking backups before enterprise changes will ensure a more peaceful IT team
• Though it looks like a bunch of text, manually editing siebns.dat is not supported. If there are no backups to fall back on, "Go Tech Support!"
• High availability is supported through resource clustering

 

 

Siebel Enterprise Server

A logical grouping of Siebel servers, Enterprise Server is not a physical entity. An enterprise server will function using a single instance of database. It is most useful to push common parameters across to various components on different Siebel servers. Remember that Gateway sends the requests to servers depending on component availability?  - well, then we don’t have anything more to deal with here.

 

Siebel Server

This is our guy in the group. Siebel server (more specifically one or the other Object Manager) receives user requests, pulls in data from database/from other sources, applies business logic, builds UI, merges data & UI and sends back information to requestor – whew!

Siebel server processes can be executed in interactive, background or batch mode and can be single or multithreaded. Siebel Object Manager is a component that resides in Siebel server that does most of the work. Different verticals & horizontals provided by Siebel CRM use different Object Managers, for example Call Centre OM, Sales, eService OM, etc, with each language having its own OM. That is the reason we have a "sales_enu" and a "sales_egb". Apart from this, we have OMs for external facing functions like Enterprise Application Integration (EAI). Object Managers in turn use other components in the server do execute various tasks. "Data Manager" worries about database interactions, "Assignment Manager" takes care of task allocation and so on. Components also work independent of user interactions - "Workflow Process Manager" takes care of validations & automations, "Transaction Router" & "Transaction Processor" manage remote clients and "Enterprise Integration Manager" (EIM) enables loading of external data in Siebel application.

 

Other Important components here are:

• Server Request Broker (SR Broker) and Server Request Processor (SR Proc) facilitate calls between different entities in the Siebel server. SR Broker handles synchronous requests, while SR Proc handles (server initiated) asynchronous requests. Both components are capable of utilising components within the server or those on other servers. This is termed as "resilient processing"
• Server Connection Broker is the intra-server load balancer, and manages spawning of tasks and threads of each component

 

 

Aside:

• Calls between different entities in the Siebel server is facilitated by Server Request Broker and Server Request Processor through Gateway. All communications within Siebel space use SISNAPI or Siebel Internet Session Network API
• Reports are not actually taken care in Siebel, rather those requests are passed on to "Actuate" reporting application. Actuate is tightly integrated to recognize Siebel data model, interact with database and produce reports
• Interactions with Oracle Business Intelligence happen through an interface, a well-defined one at that

 

Clients

The common web client defined above can also be of two types:

• High Interactivity Client – Installs and uses ActiveX controls on the client machine. Obviously, it requires Internet Explorer with suitable patches for IE and the operating system itself. Safe to consider it when the web clients reside on desktops under some degree of control
• Standard Interactivity Client – Zero footprint, works on more browsers but UI is nothing to write about 

 

Web clients can bypass server in a dedicated client mode. This mode uses Siebel Repository File (SRF) on the client machine and connects directly to the Siebel database.

Web clients also can function in a disconnected mode – for that we extract data for the user from the Siebel server and provide a copy of SRF on the client machine. The data in local database then needs to be periodically synchronised with the Server.

 

Other than web clients, there is Siebel Handheld for phones coming under the PDA bracket. Siebel is installed on the phone device and provides field force with a way to manage Siebel data. Handheld devices can be used in a disconnected mode and later synchronised with the Siebel server – directly using http/https requests or using a PC as intermediary. Technically, any phone with a browser can be used to connect with Siebel applications, but one look at the way the application looks on the tiny screen should put such considerations to rest.

 

Deal with Outside World

Lot of integration gurus have a lot to say about how enterprises need to build their processes. To simplify overtly, I tend to think of all integrations as passing through the service bus. All interactions with the external systems, maybe for provisioning, billing, supply chain management etc. will involve one or the other requests flying into or out of Siebel applications through the Service Bus - out into the big bad world. Haven’t heard of Service Bus? Relax, here it just refers to any standard middleware application like Oracle Fusion, IBM Websphere and the like

 

What Next?

• Refer detailed descriptions of various Siebel components in "Siebel System Administration Guide" of Siebel Bookshelf
• Install Siebel CRM
• Download Siebel installable files from http://edelivery.oracle.com
• Make install and carry out installation. Refer Siebel Installation Guide for UNIX or Windows
• Find demo license codes at http://licensecodes.oracle.com
• Go here for a better architecture image
  

Siebel Client-side Import - Used it yet?

Possible spoiler: Content below may be of academic interest rather than any commercial exploitation!

Most Siebel users will be familiar with "Import" and "Export" options displayed in the applet level menu in list applets. Although export is quite commonly used, import does not find many consumers. Client-side import refers to the functionality using which users, through the UI, can import data into Siebel application from a CSV file, ACT! Application export or any other defined file format.

Although we always "recommend" initiating and storing the CRM data in Siebel, that may be difficult to achieve due to logistic reasons like availability of application, disconnected mode of usage or data coming in from different sources. This gap is commonly addressed as an interface of some kind – submitting files for imports through an enterprise batch process, import using custom COM programs, interacting directly with the third-party enterprise applications etc. There are instances where allowing users to import the data quickly and start working on Siebel application may provide a better experience rather than forcing them through an enterprise EAI process running in a disconnected mode. Instantly uploading data will also enable users to connect closely with the application & assume ownership of the data. ( Hail Jargons! Anymore to add, anyone?)

Siebel out-of-the-box supports import of Contacts (according to an ambiguous statement in bookshelf that says “Siebel applications support contact business components only for client-side imports”). I am not sure how the other 25+ import objects are used, but this feature is certainly will not be on anyone’s priority list. After all, today organizations want immediate access to data from every employee and entering data in one or the other enterprise application is the norm. I did not bother to search in metalink and come out with use-cases, so do notify me if this is a repeat and I will tag this post accordingly.

 

Developers can easily configure components to enable Client-side import. An illustration below is an overview of enabling such an import for “List of Values”.

 

Enabling Client-side Import

 

Pre-build

• Verify whether the applet to which the import object will be associated has “Insert” permissions for the user (May be irrelevant here – new LOVs can always be inserted right?)
• Expose “Import Object” in the “Object Explorer” of Siebel Tools

Build - Tools

1. Create import object in Tools - Create a new “Import Object” based on same BC as the one that you see in UI. You will not see “Import” enabled in the UI if this is not the case

2. Create “Import Field” for all attributes that need to be imported
3. Create relevant Import Key Field and Import Aux Field. Import Key Field acts like the “User Key”, those are the fields used to identify uniqueness of the record. Import Aux Field will provide option to re-query if there is a duplicate found
4. Define “Import Source” to map the type of file that will be imported. This provides options to the user for selecting the type of map at the time of import
5. For each import source, create field maps. Note that one Siebel field can be mapped to a combination of columns in the import destination 

Use

1. Navigate to Administration – Data > List of Values. Click on Import from the applet level menu or File (from the application level menu) > Import
2. Choose file, input format, mapping source and conflict resolution type. All fields hopefully are self-explanatory. Auto mapping allows you to do mapping on the fly, while we have defined mapping rules for predefined mapping. Since we already have created mapping in Tools, we select that without a second thought and hit on ‘Next’

3. See the magic of mapping and hit ‘Next’ (again). This will trigger the import process. Import runs within the object manager itself (or by siebel.exe, as applicable)

4. Review import, check log file and sign off. I had introduced a duplicate to test the functionality, which promptly got rejected

Advantages

• Easy accessibility for the users, immediate response
• Does not really qualify as an interface :)
• Functionality can be configured quickly

 

Limitations

• Client-side import is supported for parent business components only, no complex hierarchies, no importing of parent & children in one stretch
• Has to be based on the same BC as the applet in UI – no ‘light’ BC concept here
• Needs ‘debugging’ skills from the users! The error report is not exactly user friendly, except for the summary

 

Final Word

• Do not forget to “Clear Cache”

 

Components & Version

Components realized on Siebel 8.0. There is nothing worthwhile to share here.

References

Siebel Object Types Reference, Page 199. Bookshelf for Oracle’s Siebel Business Applications Version 8.0 - B40099-02