Easy Way to Backup Your Siebel Config While You Work

Thanks to EdZachary.com for giving the final solutions. Place the following in a .bat file scheduled to run at regular intervals that make you feel nice and safe:

set UNPADDEDHOURWITHSPACE=%TIME:~0,2%
set /a UNPADDEDHOUR=%UNPADDEDHOURWITHSPACE%
set EXTRAZERO=0%UNPADDEDHOUR%
set HOUR=%EXTRAZERO:~-2%

set curdate=%DATE:~10,4%-%DATE:~4,2%-%DATE:~7,2%
set curtime=%HOUR%-%TIME:~3,2%

set projfolder=C:\Siebel\Backups\%curdate%\%curtime%\Projects
set projdatename=C:\Siebel\Backups\%curdate%\%curtime%\Projects
mkdir %projdatename%

copy C:\Siebel\7.8\Tools\TEMP\Projects\*.* %projfolder%


set objfolder=C:\Siebel\Backups\%curdate%\%curtime%\Objects
set objdatename=C:\Siebel\Backups\%curdate%\%curtime%\Objects
mkdir %objdatename%

copy C:\Siebel\7.8\Tools\TEMP\Objects\*.* %objfolder%

Validate and Raise Messages from Run Time Events and Application (Client) Business Services

Hi Siebel lackies. This is a great little trick I discovered recently. In my fight for zero-footprint customizations of Siebel, this is one weapon that is foundational part of my arsenal going forward.

Using a combination of Run Time Events and Application Business Services (in other words not developed in tools and compiled in the SRF), you too can validate a field and message the user. Done properly, you can validate every field in your business component - no joke.

Let's get to it. Here's the scenario: I don't want users closing a Service Requests with a Resolution of "Other" without an entry in the "Comment" field. It's a common request. First create your business service. You should create a method and then handle that method in the pre_invoke. If you don't know how to do that, you are in bad shape. Here's the function we'll be using that is relevant to this method:

function SRClosedError ()
{
TheApplication().ActiveBusObject().GetBusComp("Service Request").UndoRecord();
TheApplication().RaiseErrorText("The Service Request cannot be closed with a Resolution Code of other without a Comment.");
}

Notice what I am doing here: I am just rolling back the junk from the user and popping a message box. In 7.7.2 and up, RaiseErrorText gives you a message box.

Now go to Site Map -> Administration - Run Time Events -> Action Sets. We need to create the Action Set for our Event. Create a new Action Set record and name it Customer_Prefix Service Request BusComp Validations. Note that "Customer_Prefix" is the same prefix you've been using in your repository. Since this is a master entity record it receives the prefix.

Now create a child Action. Let's call it Comments Required when Resolution = Other. Do not set a value for Conditional Expression. Set the Action Type to Business Service and then set the Business Service Name and Method fields. Also set sequence.

Next create the Event. Click on the Events View. Create a new record. Object Type = BusComp, Object = Service Request. Then pick that Action Set you created. Now drill to the Action Set. Since you've drilled into the Action Set from the Event, the Conditional Expression java applet will get the business component needed to be in context. Add your conditon for the Action (not the Event and certainly not the Action Set). The Conditional Expression on the Action called "Comments Required when Resolution = Other" should be [Resolution Code]=LookupValue("SR_RESOLUTION","Other") AND [Description] IS NOT NULL.

That's it. Reload Run Time Event using the command on the applet menu. Enjoy.

Resuming Errored Instances of Bad Workflow Process Design

When you have an error in your workflow Siebel should toss the instance into Workflow Instance Admin. Once you diagnose, fix, and test, you will need to recover all the errored processes. However, you cannot do this via the GUI admin in Site Map -> Administration - Business Processes -> Workflow Instance Admin. Once the revised WF Process is deployed, the saved and errored instances will still be hung on the old and errored Definition. You have to update the Definition Id so that WFProcMgr will use the newly defined WF Process rather than the old.

This problem happened to me when a client wanted to send emails to two different recipient groups. Obviously the smart thing to do was to create an addtional correspondence template and add the name of the template to the Package List parameter of my CreateRequest step on my workflow. Unfortunately I delimited the template names with a comma (',') rather than a semi-colon (';'). With a comma, WFProcMgr sees only one template name instead of two and throws HUGE fits ( a.k.a. errors). Finding my mistake, I needed to recover. I deployed the repaired and updated WF Process definition and then had to update the errored instance as below:

UPDATE S_WFA_INSTANCE set DEFINITION_ID = '1-16C9P' WHERE DEFINITION_ID = '1-163A6'

Once I ran the SQL, I then went throw each instance and resumed Current Step in the Related Instances Applet.

If you ever have to recover and in the process update a WF Process Definition, this advice will be of tremendous help.