Automate Siebel Dedicated Clients and Tools - Episode 1

This will be about developers that have so many developing environments for they project.

So all in all the developing process of Siebel application is made in 3 different (can be more or less, but 3 is the default) environments:

1) Developing environment - where developers develop application;

2) Test environment - where testers test application;

3) Production environment - where user uses application.

In this post I will talk about developing environment.

Normal Siebel application can have more than one developing environment. It depends on size of application, on number of modules, number of developers and so on. Normal developing process is as described:

1) Every developer has his own developing machine on witch he have local database, local Tools. When he is developing application he logs in with his credentials in Tools, does check-out on object, modify it or create a new one, test it and then check-in. So the test process he is performing is interesting. He uses dedicated client with locally compiled .srf and the server database. So he can test his own created functionality with server data;

2) After creating process is done, the full compile of server .srf is done and it is migrated to test environment there it will be tested and if everything is OK it will be migrated to production.

This all is in big scope and every individual project can have his own differences.

I will try to explain how developer can manage the local .srf and dedicated clients if the project have more than one developing environment.

So if you have more than one developing environment and you use both of them you want to automate your login process in dedicated client and Tools. So that you every time know where you are and what are you doing.

All of this means of creating a lot of .cfg files. I will give example about two environments.

1) So first of all create the folder on your development machine (create there where you can find it - I usually do this just on desktop. This will be your configuration and repository folder. It will carry your .cfg files and .srf.;

2) So next step is to define how many environments we have (in our case it will be two), how they are called (in our case lets say DEV1 and DEV2), how they are accessed (to know what to write in data source section in cfg. files), which environment is the primary for you (for witch you will have local database, in our case lets choose DEV1), and with what user you will log in to the client and tools (lets make it two - user "user" password "user" and user "sadmin" password "sadmin");

3) So it will make for you 8 shortcuts on desktop (of course for the DEV2 local Tools will not work, because you don't have local base for it).

 a)DEV1ServerClient_user;

 b)DEV1ServerClient_sadmin;

 c)DEV1LocalTools;

 d)DEV1ServerTools;

 e)DEV2ServerClient_user;

 f)DEV2ServerClient_sadmin;
 g)DEV2LocalTools;
 h)DEV2ServerTools;

4) So also it will be 8 cfg. files, for each shortcut. Of course, you can use as many cfg. as you want because with even one .cfg you can do this. But to change splash text on Tools and dedicated client you must have for every shortcut its own .cfg

 a)siebel_dev1_user;
 b)siebel_dev1_sadmin;
 c)tools_dev1_local;
 d)tools_dev1_server;
 a)siebel_dev2_user;
 b)siebel_dev2_sadmin;
 c)tools_dev2_local;
 d)tools_dev2_server;

5) And least but not last - you will have 4 srf.

 a)siebel_dev1;
 b)siebel_dev2;
 c)tools_dev1;
 d)tools_dev2;

In next episode I will try to explain how this files is created and what they do.