Component/Job not visible in Server Administration applet

Today we got the new Siebel 8.1 Env to work on, being set-up by our Admin team. Everything is new because the fresh implementation has just kicked-off and the new team of developers required to get their Database Extract.

So, as per the normal process, I went to "Administration - Server Management -> Jobs" view to start a job for "Generate New Database". I clicked on "New" and tried opening the "Pick Applet" which is available on "Component/Job" field on the Jobs applet and got suprise to see that no "Component" was available in the pick applet.

hmmm.... first thing came into my mind was : "Any component is running on this Siebel Server?". Well to check it, I went to "Administration - Server Configuration -> Enterprises -> Component Groups", queried for "Siebel Remote" and found that all the components was enable on the Siebel Server. So no issues from components side.

After some of the discussion I came to know about the issue and let me know how I resolved it. I went to "Component Definitions" view and clicked on "Synchronize" button. It sometime for the hour-glass to go-off and then I again tried created a job for "Generate New Database" and all the components are now displaying in the pick applet.

Advice for "Admin People", please click on synchronize button after setting up the new Siebel Env :)

Debugging Email Issue : Mail Profile Parameter

One of my friend called me up this morning and said somehow emails stop working in Production Env. And when I asked about the issue in detail, he told me that any of the email via Workflow Policy is not going, he tried lot many times but none of the user has received any of the email but if use F9 functionality, email was firing properly.

hmmmmm !!! Okayy... not a problem, lets start the debugging and lets see where exactly the issue exist.

1. Since F9 functionality is working that means Siebel Server is successfully creating an SMTP request using the Communication Profile (that we generally used in Production Env).

2. Do some operation, so that Workflow Policy gets trigger.

3. Checked whether policy gets trigger or not, using the below SQL statement :

select * from s_escl_req

where rule_id = "Policy Row Id"

record was existing in the table and checked the BT_ROW_ID column has the rowid of the record for which policy triggered.

4. Lets wait for 1 min, (generally 1 min is the sleeping time of all monitor agents) and lets see whether it is getting processed by monitor agent or not.

5. Yes, after around 1 min, the record gets deleted from S_ESCL_REQ and a new record gets created in S_APSRVR_REQ table for sending an email to the user with status "Queued".

6. Uptill now everything seems working fine and now Email Manager should pick this request from S_APSRVR_REQ table and should send an email. Lets wait for 1 min more.

7. Ooops... record is still existing in S_APSRVR_REQ table with the status "Queued". That means Email Manager has some issue and it is not picking the request from this table. Okayy.. now lets see what Mr. Email Manager is doing right now [may be on vacation :) ]

8. Navigate to "Administration -> Server Management -> Enterprises". Query for "Email Manager" and found that it was there and the status was online. It seems working, drilldown on it and navigated to "Tasks" view and no error log was being generated for it. But since it is running then it should process the record in S_APSRVR_REQ table. And one more point is we are successfully sending emails via F9 functionality.

9. Okayy, now lets check which email communication profile this "Email Manager" is using.

10. Navigate to "Administration - Server Configuration -> Enterprises -> Component Definitions". Query for "Email Manager". Query for "Mail Profile" under Parameters list.

11. And yes, we found something strange. "Profile Name" was somehow blank. Don't know the reason but since it is not having Communication Profile mentioned to process the request, it is not doing its job perfectly.

12. Put the same communication profile name which we were using for F9 functionality. Restart the Siebel Server and found all emails which got stuck in "Queued" status in S_APSRVR_REQ table, has successfully processed and has the status "Success" now.

So finally, issue get resolved.

Debugging Siebel Workflow Process at Runtime

Sometimes it happens that you perform some operation, which needs to trigger a workflow process (synchronous / asynchronous) and you realised that it has not performed as per the expectation and want to see what exactly it has done. Workflow is a collection of some steps which gets executed sequentially, so you might need to track what it has done in each step and in which step some problem has occured.

Siebel provides a way to debug a already deployed workflow at the runtime and its very easy as you can do it in web client itself. What you need to do is :

1. Navigate to "Administration-Business Process -> Workflow Deployment -> Active Workflow Processes" view.

2. Query for the Workflow Process in the bottom applet.

3. Change the "Monitoring - Level" for the workflow process to "4 - Debug".

4. Now go and perform the same action again which will trigger this workflow.

5. If it again errored out or not performed as per the expectation and you want to track it execution step by step, navigate to : "Administration-Business Process -> Workflow Instance Monitor" view.

6. Query for the Workflow Process in upper applet. System will show all the instances executed for that workflow in the bottom applet. Sort the instances via "Start Date" descending.

7. Navigate to "Step Instances" view.

8. Now you can see, what all process properties were in each step of the workflow and make out what went wrong.

Isn't easy to have any workflow running in Debug mode at the runtime?

Hope this helps.

.

Siebel CFG Parameter : AutoStopDB

Everytime I close the Siebel Tools, I wonder that the Siebel Anywhere database engine (dbeng.exe) keep running in the Task Manager and sometimes it happens that it keeps consuming lot much of system memory, so I use to go to Task Manager and kill the process.

But again the question is, when I don't want to keep the Siebel Tools running anymore, why Database Engine keeps running?

So, here is the answer :

Siebel provides a CFG parameter (both in Client's and Tools's CFG file) under [Local] / [Sample] Section, name is "AutoStopDB" with the default value as "FALSE".

The "False" value of the parameter signifies that the Siebel Anywhere DB engine keeps running if you close the Client / Tools instance. As per the recommendation it should be "FALSE", in case you mostly connect to the same Database via Client and Tools, so that next you open the new instance of Client or Tools, system should not take time to connect to the database again.

So, depending upon the requirement, you can make it TRUE or FALSE. I change it to TRUE, coz I always use to connect to Local DB via Siebel Tools and to Server via Client.