Scripting

                Hello everyone. Today I will try to explain about scripting in Siebel. Scripting is widely used method of requirement implementation in Siebel, but in the same time it is not best practice or best choice.

                So all in all writing a script means writing a bulk of code to do some functionality. There are two scripting languages that Siebel developers use – eScript and VBScript. Most widely used is eScript, but in internet you will find many people that use VB. I will talk about eScript because it is what I use in my job.

                To write a script with eScript we can use similar syntax as JAVA, C++, and C #. Of course to do scripting you need knowledge of programming. We can use scripts on objects like Applets, Business Components, and Business Service. There are two types of scripting – Server Script and Browser Script. This means two ways of result:

1)      Server Script – it works on server side and do your code flow like normal program that you write in code. For example you coded the code on Applet for your custom button that inserts default data in new record depending on user’s responsibility. When user click button server checks his responsibility and enters default data depending on responsibility.

2)      Browser Script – they work on browser side. This type of scripts usually is real pain and developers try to not use them, but sometimes there are no other choices than use browser script. With browser script you can get confirmation windows like “Do you want to proceed? Yes! No!” Browser scripts is only way to do this, but they are really hard to write and test because you can’t debug them. Also every time you compile it, it generates browser scripts and you need to follow what scripts you generated earlier and what only now.

Ok let’s do some scripting now. I will not talk about syntax because I assume that who reads this know how to program. If you want write a script you need to find object in Siebel Tools and right click it with mouse and find “Edit Browser Scripts” or “Edit Server Scripts” depending on what script type you want to write. After that opens scripting windows! In left side you will see tree with some methods! Those are Siebel standard methods for this objet. Like for Applet:

1)      PreInvokeMethod;

2)      InvokeMethod;

3)      ShowControl;

4)      ShowListColumn;

5)      PreCanInvokeMethod;

6)      Load

As you already see, those are events on witch you can put code. That means if something happens with Applet then the appropriate code will be called. For example you create a custom button, put it on Applet and give it an Invoke Method property – EventMethodLaunch. Then in InvokeMethod event (some times in PreInvokeMethod or PreCanInvokeMethod, depends on what you are coding) you write:

if (MethodName == “EventMethodLaunch”)

{

                Do something;

}

Automate Siebel Dedicated Clients and Tools - Episode 4

                So today let’s finish this Siebel Dedicated Clients and Tools Automate thing. Where we left? Aaa…

                Five more shortcuts and we done:

4)      DEV1ServerTools – will log in to DEV1 server Siebel Tools and with user credentials, so modify shortcuts Target:

a)      "way to \siebdev.exe" /c "way to \ tools_dev1_server.cfg" /u user /p user /d ServerDEV1

5)      DEV2ServerClient_user – will log in to DEV2 Siebel Dedicated Client with local srf. and server database and with user credentials, so modify shortcuts Target:

            a)       "way to \siebel.exe" /c way to \ siebel_dev2_user.cfg /u user /p user /d ServerDataSourceDEV2

6)      DEV2ServerClient_sadmin – will log in to DEV2 Siebel Dedicated Client with local srf. and server database and with sadmin credentials, so modify shortcuts Target:

            a)      "way to \siebel.exe" /c way to \ siebel_dev2_sadmin.cfg /u sadmin /p sadmin /d ServerDataSourceDEV2

7)      DEV2LocalTools – will log in to DEV2 local Siebel Tools and with user credentials,  but as you already know this will not work, because you don’t have DEV2 local base, but anyway modify shortcuts Target:

            a)      "way to \siebdev.exe" /c "way to \ tools_dev2_local.cfg" /u user /p user /d LocalDEV2

8)      DEV2ServerTools – will log in to DEV2 server Siebel Tools and with user credentials, so modify shortcuts Target:

a)      "way to \siebdev.exe" /c "way to \ tools_dev2_server.cfg" /u user /p user /d ServerDEV2

So we did it. Now you have on your desktop 8 icons on witch you make just double click (or one if your PC settings are set so) and you automatically enter application.

This all is of course in big scope because all this depends on your system architecture, how many environments you have, how many user credentials you use and so on.

If I will have some spare time (doubt) I will add some screenshots so it will be understandable. The text is in such a bulk because for writing posts I use Word and then just copy and paste the text. This blog editor doesn’t support Word’s line spacing and some other things, but to write post in blog is bigger pain.

Next time I will talk about scripting and what it has to do with Siebel. This is big and interesting topic, because scripting actually isn’t supported by Oracle and they say never to use the scripting, but sometimes there is no other way to implement requirement than just scripting, but scripting has its bad side too.

Hope you still enjoy reading as I am writing.

Automate Siebel Dedicated Clients and Tools - Episode 3

                So today I will tell about DEV2 cfg. files.

1)      siebel_dev2_user - will use DEV2ServerClient_user shortcut to log in to DEV2 Siebel Dedicated Client with local srf. and server database and with user credentials, so modify file [Siebel] section:

            a)      ApplicationTitle = Local siebel_dev2.srf and DEV2 Server DB and user

            b)      ApplicationSplashText = Local siebel_dev2.srf and DEV1 Server DB and user

            c)       RepositoryFile = way to \ siebel_dev2.srf

2)      siebel_dev2_sadmin - will use DEV2ServerClient_sadmin shortcut to log in to DEV2 Siebel Dedicated Client with local srf. and server database and with sadmin credentials, so modify file [Siebel] section:

            a)      ApplicationTitle = Local siebel_dev2.srf and DEV2 Server DB and sadmin

            b)      ApplicationSplashText = Local siebel_dev2.srf and DEV2 Server DB and sadmin

            c)       RepositoryFile = way to \ siebel_dev2.srf

3)      tools_dev2_local - will use DEV2LocalTools shortcut to log in to DEV2 local Siebel Tools and with user credentials. This will not be possible, because you have local database only for DEV1, but anyway modify file [Siebel] section:

            a)      ApplicationTitle = Local DEV2

            b)      ApplicationSplashText = Local DEV2

            c)       RepositoryFile = way to \ tools_dev2.srf

4)      tools_dev2_server - will use DEV2ServerTools shortcut to log in to DEV2 server Siebel Tools and with user credentials, so modify file [Siebel] section:

            a)      ApplicationTitle = Server DEV2

            b)      ApplicationSplashText = Server DEV2

            c)       RepositoryFile = way to \ tools_dev2.srf

This is everything for cfg. files. So lets now take the last files – shortcuts.

So lets start with DEV1 shortcuts:

1)      DEV1ServerClient_user – will log in to DEV1 Siebel Dedicated Client with local srf. and server database and with user credentials, so modify shortcuts Target:

a)      "way to \siebel.exe" /c way to \ siebel_dev1_user.cfg /u user /p user /d ServerDataSourceDEV1

2)      DEV1ServerClient_sadmin – will log in to DEV1 Siebel Dedicated Client with local srf. and server database and with sadmin credentials, so modify shortcuts Target:

a)      "way to \siebel.exe" /c way to \ siebel_dev1_sadmin.cfg /u user /p sadmin /d ServerDataSourceDEV1

3)      DEV1LocalTools – will log in to DEV1 local Siebel Tools and with user credentials, so modify shortcuts Target:

            a)      "way to \siebdev.exe" /c "way to \ tools_dev1_local.cfg" /u user /p user /d LocalDEV1

Tomorrow I will continue with the last part of this Dedicated Client automate.

Automate Siebel Dedicated Clients and Tools - Episode 2

So, yesterday we talked about files we need to automate Siebel Dedicated Clients and Siebel Tools, if you have more than one development environment and you use both.

Today I will tell you what to do with those files. So we will start from bottom of yesterday’s list.

So first you need to 4 srf. files:

1)      siebel_dev1 - this will be the repository file for DEV1 environment your Siebel Dedicated Client will use and you will compile your changes to this file. I think it is self explanatory, so no need to go in to file itself;

2)      siebel_dev2 - this will be the repository file for DEV2 environment your Siebel Dedicated Client will use. Because you will have locally only DEV1 database, you will not be enabled to use Siebel Tools for DEV2 so you can't compile your DEV2 changes, but still you can use this srf. and connect to DEV2 server database;

3)      tools_dev1 - this will be the repository file for DEV1 environment your Siebel Tools will use;

4)      tools_dev2 - this will be the repository file for DEV2 environment your Siebel Tools will use, but because you don't have database for DEV2 you can't use DEV2 Siebel Tools.

So next is 8 cfg. files for every shortcut, I assume that you know how cfg. are working and that data sources are already entered in cfg. files for both environments:

1)      siebel_dev1_user - will use DEV1ServerClient_user shortcut to log in to DEV1 Siebel Dedicated Client with local srf. and server database and with user credentials, so modify file [Siebel] section:

a)      ApplicationTitle = Local siebel_dev1.srf and DEV1 Server DB and user

b)      ApplicationSplashText = Local siebel_dev1.srf and DEV1 Server DB and user

c)      RepositoryFile = way to \ siebel_dev1.srf

2)      siebel_dev1_sadmin - will use DEV1ServerClient_sadmin shortcut to log in to DEV1 Siebel Dedicated Client with local srf. and server database and with sadmin credentials, so modify file [Siebel] section:

a)      ApplicationTitle = Local siebel_dev1.srf and DEV1 Server DB and sadmin

b)      ApplicationSplashText = Local siebel_dev1.srf and DEV1 Server DB and sadmin

c)      RepositoryFile = way to \ siebel_dev1.srf

3)      tools_dev1_local - will use DEV1LocalTools shortcut to log in to DEV1 local Siebel Tools and with user credentials, so modify file [Siebel] section:

a)      ApplicationTitle = Local DEV1

b)      ApplicationSplashText = Local DEV1

c)      RepositoryFile = way to \ tools_dev1.srf

4)      tools_dev1_server - will use DEV1ServerTools shortcut to log in to DEV1 server Siebel Tools and with user credentials, so modify file [Siebel] section:

a)      ApplicationTitle = Server DEV1

b)      ApplicationSplashText = Server DEV1

c)      RepositoryFile = way to \ tools_dev1.srf

Tomorrow I will tell about DEV2 cfg. files.

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.

Creating Joins

Joins in Siebel is the thing that makes the relationships between tables possible. The difference between Join and the some other relationship method (like in Access making a simple relationships between tables) is that the relationships is based on Business Components in Siebel Business Layer not on the Tables them self.

1) So first of all you need two Business Components between who we will make relationship;
2) In Child Business Component create Field that you will see on Applet with data from Parent Business Component;
3) Then in Child Business Component create Field that will store ROW_ID from Parent Business Component. This Field must be based on column of Child Business Component based Table;
4) Then in Child Business Component create Join that is based on Table on which is based Parent Business Component;
5) Then for newly created Join add Join Specification with column from Parent Business Component Table that store ROW_ID (usually it is ROW_ID) and Source Field is Field we created in point 3. (Field that stores the Parent Business Component Table ROW_ID;
6)Then modify Field we created in point 2. by adding Join property of Join we created in point 4. and adding a column from Join (from Parent Business Component Table) that you want to see on applet (for example NAME)

Example - You have applet with Contacts and you want to see on it Account the Contact belongs. Account is Parent Business Component and Contact is Child Business Component. So you create two new Fields on Contacts Business Component, one Join also on Contacts Business Component. In the end if you will put on applet Field we created in step 1. you will see a Account Name, but in the Data Base will be ROW_ID of the record in Accounts Table.

About my last post about Check In/Check Out, there is some problems with this. I will update it as soon as I test everything.

Check in locally locked object.

Some times before we "Check Out" some objects or even a whole project we want to play around it locally, so we just click right mouse button on object and select "Lock" to start modifying it (and if something goes wrong you can just do "Get" on object to get definition from server). It is good choice if on one, really hard to solve, requirement (some difficult change request) are working two or more people in team (two heads better than one). Then every body can "Lock" project locally and work with it. But what to do when some one find the solution and want to "Check In" it? Yes he can't because the objects he changed must be "Checked Out" from server and locked on the server. So if we "Check Out" object it will overwrite any changes we made and we need to do it all again, but what if it was really hard solution and depends on lot of configuring? So there is a solution! Of course it is not good to do it too much! The member who solved the problem log in to the "Siebel Tools" on server (first better close local "Tools" (I don't know if it is needed, but better to close)), then lock the object, objects or projects, that are changed locally, on server "Tools" so that they are locked by that member who have locally solved solution. Close the server "Tools" (this is mandatory) and then member who solved solution can do "Check In" to check in modified objects. As I sad, it is not advised to do it too much, because it is not advised to log in to server "Tools" to much, or if you do so then think about every step you do on server.

Hope it helps teams.