A really quick and simple tip…
When you’re running a Database Extract job for a developer, set the Extract all repository tables parameter to True to preload the database with the entire contents of the repository. This saves the developer doing a full ‘Get’ of all projects after initialising the database.
Hardly groundbreaking stuff, but one of those things that I can remember not knowing, and I can’t remember how I first found out. Maybe somebody else will find out here…
May 16th, 2007
When I first needed to add some funky client-side functionality in Siebel 7.5 I was hit with a problem: how to get hold of the browser scripts for testing?
SupportWeb Alert 365 covers using the genbscript utility to build the scripts from the repository using the following format:
genbscript <config_file> <destination_dir> <language_code>
This is all well and good and works fine - I’d recommend the method outlined for migrating browser scripts up to a server.
What the alert fails to mention, though, is that the officially ‘deprecated’ method of letting Tools generate the scripts for you still works. When you compile an object in Tools, any associated browser scripts are generated in the default directory tools_root\public\language_code\srf_timestamp\. This srf_timestamp directory is the same one produced by genbscript - except it only includes scripts for objects you’ve compiled.
For local debugging and unit testing this avoids an extra step. The destination directory for browser scripts can be changed by going to View > Options > Scripting and changing the ‘Browser script compilation folder’. You’ll want to set this to your Mobile Client’s public directory (e.g. Siebel\7.8\client\PUBLIC\enu) .
Then if you also have the usual parameters on the Debug tab pointing at your mobile client, and the location of the Siebel Repository File on the Compile dialog correctly set, then unit testing of browser scripts is a simple Ctrl+F7 > Enter > F5 away…
February 28th, 2007