Archive for March, 2007

Changing the Local Database Password

Users forget their passwords – that’s just the way it is. Without picking on anybody, certain users (cough sales guys cough) are particularly prone to this. And more often than not, they’re remote users who’ve not synchronised their local database for a week and desperately need their updates.

As with the server database, there’s no way to retrieve the current local database password. Password hashing algorithms are repeatable, but not reversible – sensibly enough. It is possible to change the password to something new though.

Connect to the local database, then run these SQL commands:

grant connect to USERNAME identified by PASSWORD
grant connect to SIEBEL identified by PASSWORD

Where USERNAME is the login for this database and PASSWORD is the new password (both in upper case). If for some reason you don’t know who the local database belongs to, the login can be retrieved with this command:

select name from SYSUSERAUTH
where name not in ('SYS','DBA','PUBLIC','SIEBEL','DBO','dbo','SSE_ROLE')

More often than not, you’ll also want to reset the server database password to match, so that you can sync up those outstanding changes. On Oracle, this is your usual:

alter user USERNAME identified by PASSWORD

There’s more info in SupportWeb TechNote 25, including scripts for different versions of SQL Anywhere to automate the process.


March 29, 2007 at 7:13 pm 1 comment

Siebel Interview question

I’ve interviewed a bunch of Siebel techies and have evolved a few favourite questions, all based around the same theme: attempting to uncover technical breadth while avoiding obscure ‘gotcha’ questions. Things like this:

Q: How would you update a second field every time a first field is changed?

This is a great question: simple enough that a junior dev straight out of a tools course should come up with a few options and have some idea how they weigh up, but broad enough that a senior techie can lead you into detailed discussions about performance vs maintainability, good practices, upgrade issues, etc etc.

If the candidate’s running out of steam, leading questions can coax them toward more inventive answers. For instance:

  • What if the second field is in a different business component?
  • What if there are multiple fields to be updated?
  • What if the second update needs confirmation?
  • What if the update still has to happen for batch (EAI/EIM) updates?

To the answer: I reckon the following is not a bad list to cover-off, but there’s still a few missing…

User Properties
+ minimal config
+ real time
+ robust (mostly!)
– limited
– require srf update

Runtime Events to Workflow Process
+ most things possible with native, compiled Siebel Operations
+ declarative, flexible, upgradable without srf update
+ long-running workflows for multiple consecutive events
+ real-time, optional asynchronous
– no loops (almost) without custom business services
– overhead of instantiating the workflow first time (then cached), which can have a big impact on mobile users

Server scripts
+ simple to write
+ low overhead
– not declarative, requires srf release
– higher level than vanilla C++ services (so slower, in theory)
– limited possibility to interact with the user

Browser scripts
+ opportunity for full manipulation of DOM, real-time interactivity
– maintenance headache (generating script, keeping versions current)
– interpreted at run-time (so slower, in theory)
– limited speed, memory space etc

Workflow Policy to Workflow Process
+ fully robust database-level trigger
+ fully asynchronous
– not real time, interactive
– not declarative, requires DBA maintenance

March 26, 2007 at 11:57 pm 5 comments

Locally unlocking a locked Project

With multiple developers building one application it’s inevitable that multiple developers will need to change the same project at the same time. There’s pros and cons and object-locking and change-control and build-control etc etc, but sometimes deadlines are too tight and you just have to fork.

In Siebel Tools, once one developer’s got a project locked the UI won’t let a second developer anywhere near it. To get around this you need to get into SQL Anywhere. Login to the second developer’s local database, then the following script will unlock the project locally:

UPDATE s_project
SET locked_flg = ‘N’
WHERE name = <Project Name>

The second developer can now log into Siebel Tools, manually lock the project as normal and do what she has to do. Of course, once build is done the two developers will need to go through a merge exercise to get their changes into the one repository, but that effort can be preferable to losing days of development time.

March 22, 2007 at 7:47 pm 2 comments

Tools Object Explorer options

Every Siebel 6 developer new to Siebel 7 goes through this one. Install Tools, open it up, browse around, note the handy use of drilldowns everywhere, then… “Where have all the Integration Objects/Reports/Workflow Policy Objects/User Properties/etc etc gone??! ”

The answer is that they’re hidden. For ‘simplicity’, Tools 7 defaults to only showing a small subset of the repository objects. To see the rest, go to the View -> Options… dialog and click the Object Explorer tab:

Object Explorer Options

From here, you can tick away exposing all the obscure Pick Map UpdOnlyIfNulls and Workflow Policy Component Cols you want to hack around with.

March 19, 2007 at 8:03 am 1 comment

Connecting to a Local Database

SQL is my kind of fast, powerful, geekiness. I’m forever forgetting the ins-and-outs of connecting to a local database with SQL Anywhere though, so it needs noting.

There’s a pretty comprehensive SupportWeb article that covers everything you need to know. In summary:

  • for Siebel 6 use isql55.exe from the \bin directory, then username DBA and password SQL.
  • for 7.0 and 7.5 use dbisqlc.exe and the same DBA/SQL.
  • for 7.7 and 7.8 it’s still dbisqlc.exe but the login changes to DBA/<Enterprise Name> (in upper case).
  • not sure about 8 yet…

Update: those executables are all in the client\bin directory, regardless of version.

Another login option in all versions is the username SIEBEL with the local password for the database you’re connecting to (in upper case). This can be handy if somebody’s changed the database admin password, for instance…

The Watcom-SQL variant is somewhat different from Oracle or SQL Server SQL, so it’s worth keeping the SQL Anywhere User’s Guide to hand while hacking around.

March 15, 2007 at 7:24 pm 2 comments

Siebel DBA Resource

I was going to do a post about Siebel resources around the web, but AndyC (aka Norman Brightside) beat me to it.

Andy’s writing some excellent articles for database admins working with Siebel, which will be most handy. I’ve worked with any number of excellent DBAs who know Oracle/SQL Server inside out but nothing about Siebel; now I know where to send them…

March 14, 2007 at 1:34 pm

Popping up the Persistent Customer Dashboard

A while ago I was implementing the Persistent Customer Dashboard in Siebel 7.8. Generally, the dashboard is linked into CTI and auto-populates customer details when successfully matching an incoming phone number, after which all the customer info remains visible to the user no matter where else they navigate in the application. Some variation of the functionality is standard in most call centres.This particular client wanted to use the functionality in a more manual scenario though, with the users querying for the customer before manually populating the dashboard. That’s pretty easy to do, invoking the ‘Update Dashboard’ method on the Persistent Customer Dashboard business service.

The first complication was that the client didn’t want the dashboard visible by default – I needed to have it open up and populate on demand. That turned out to be also not too tricky: there’s an ‘OpenDashboard’ method on the same Persistent Customer Dashboard business service that does exactly what is says on the tin. [Note: ‘OpenDashboard’ (no space) and ‘Update Dashboard’ (with space). Intuitive, non?]

The tricky thing was that we needed to open the dashboard, update the dashboard details and update the source applet – all from a single button click. Problem: the dashboard and the source applet are in different frames, and only one frame can be updated from one UI event. So if I updated the Dashboard, the update to the source applet didn’t happen. And if I updated the source applet…

The solution was to create a second button on the applet to trigger dashboard update in a server script. Add in a browser script to handle the method for the first button, opening up the dashboard from there – and allowing the source applet updates to happen – before using FindActiveXControl to programmatically ‘click’ the second button – giving us a second UI event and the opportunity to populate the dashboard.

Code below…

Server script ‘Update Dashboard’

// Populate the persistent customer dashboard
var bsDashboard;
var psInputs;
var psOutputs;
var AccountId;

bsDashboard = TheApplication().GetService("Persistent Customer Dashboard");

psInputs = TheApplication().NewPropertySet();
psOutputs = TheApplication().NewPropertySet();

AccountId = this.BusComp().GetFieldValue("Account Id");

if( AccountId != "" )
psInputs.SetProperty("Source Name","Base View");
psInputs.SetProperty("Buscomp Name", "Account");
psInputs.SetProperty("RowId", AccountId);
bsDashboard.InvokeMethod("Update Dashboard", psInputs, psOutputs);

Browser script ‘Select Customer’

// Open up the Persistent Customer Dashboard
var svc = theApplication().GetService('Persistent Customer Dashboard');
var inputs = theApplication().NewPropertySet();
var outputs =theApplication().NewPropertySet();
outputs = svc.InvokeMethod('OpenDashboard', inputs);

// Click the custom 'To Dashboard' button
var obj = this.FindActiveXControl("UpdateDashboard");
// obj.all[0].all[0] locates the Anchor tag.

March 2, 2007 at 7:32 pm 2 comments

Older Posts