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.

His Story

So as promised a little bit of history behind Siebel. I am not so experienced in Siebel, so I will not talk about all history curves, just in big picture.

So, behind Siebel is a guy named Thomas Siebel. Guy worked in Oracle corporation from 1984 through 1990. And then when he do not like the way Oracle was working he founded his own company Siebel CRM Systems, Inc., and developed Siebel CRM. Then in 2005 Oracle (the company witch Tom dint like) buys Siebel Systems for $5.8 billion. Not a bad revenue from the enemy.

Actually that is in big scope, You could try reading Wikipedia about Siebel System and Wikipedia about Tom to learn more.

I need to say one thing about this blog - I will not demand on perfect information and I will not write all the things You can found on net, I will just narrow the way where to look. Because if You look around net, You will found that there already is full of blogs and forums about Siebel from more experienced guys. I will try to tell some tricks and tips I have managed in my daily work with Siebel.

Hope it will be interesting to read as it is interesting for me to write.

Siebel - CRM - Siebel

So! As yesterday I was talking about those three magical letters CRM, today I will talk about the Siebel and what it has to do with CRM.

So, as we remember the CRM is the method of interaction between buyer and seller. Where in there came Siebel? Remember the example about seller that sold You the PC and entered You in his system? Thats right he entered You in his CRM Software, be it Siebel or not. So Siebel actually, no not actually, it is a CRM software.

Wikipedia and Oracle sites can explain it more.

In Siebel You as seller can manage Your customer data much faster than You can do it in Your head. You can manage your sales process easily and much faster find all Your customer data, and Siebel can be configured to match Your business needs and to simulate Your sales process. Use call center to manage service requests from customer regarding Your products. In Siebel You can store all the data that You need to know about Your customer so that You can interact with him much faster and easy as You already know what client owns and You can prefer what he will need next.

So as old saying says "Time is Money". And first step to make more money is to save money You already have. So by using Siebel You can save Your time and money and Your customer will be happy and will stay loyal to Your business.

So tomorrow I will try to talk about little of Siebel history, because it is interesting story about man that made billions of dollar's in no time.

Customer relationship management (CRM)

So... What is those three magical letters CRM? It is Customer relationship management! So what will be the next question from guys that shake head's? That right - "What is Customer relationship management?".

So all in all the CRM is the method of interaction between buyer and seller.

For example if Homer is going to Kwik-E-Mart to buy a beer and ask the Apu for beer, Apu gets him a Duff Beer even if the Homer doesn't say what kind of beer does Homer wants. And Homer buys it with out saying that he wants different kind.

That's it - it is CRM. Seller exactly knows what the buyer wants even before buyer asks something.

Of course you can get the big info about it on wikipedia.

All in all it is the interaction between seller and buyer - like if you get some news in form of SMS from your mobile network provider to your mobile phone about that you are customer for them 5 years and now you are eligible to get some extra minutes on rate plan - it is CRM.
Or if your car seller sends you e-mail about yearly car inspection to repair the defects on your car.
Or if you buy a new PC with specific requirement and seller enters your data in his system, then you know when something will go wrong with PC or if you want something new seller will automatic know your needs and can provide you with best solution he can in much less time than the first time you bought your PC form this seller.

Hope this gives a little bit intro in to CRM. Tomorow I will try to explain about Siebel in CRM or CRM in Siebel.

Weekly Siebel Begins

Hello everyone!

Now is about 5 months as I am working with Siebel. When I first heard about it (it was in 19 February 2010) I was like "uhhhh.... what's that" after a two weeks I was "shit, shit, there nothing working, it is shit... who made it...". Now I am like if someone ask me with what you working I answer "Siebel!", they ask "What's that?", I answer "Well do you have a time...", they shake head's "Well Siebel is...", and then every time I tell a different story.

Well that is, you can't describe Siebel in one or two words, and as you work and learn about it you starting to notice some new and new descriptions of Siebel. Of course you can tell me that Siebel has one big description in three letters - CRM! BUT, if I will tell that to guys that shake head's when I ask about time, what they will answer? Of course - "WHAT THE HELL IS CRM".

So I hope that I have got hot those that don't know what Siebel and CRM is, and I will tell you all that I know when time comes...