Siebel Runtime Event and Workflow Process

In Siebel world, Runtime Event (RTE) and Workflow Process seems to be very good friends. Both understand each other pretty well. Whenever there is a need to implement any functionality on based of some trigger, these two friends comes hand in hand. I usually make use of both of them most of the time to make a good solution.

Few things to keep in mind when we use them for any requirement:

1. If a workflow process needs to be invoked synchronously like, via button click on the UI or some action done by user, RTE can be used. The best part is if the Workflow is also based on the active business object, system will automatically set the "Object Id" process property with the Row Id of the primary business component on UI. Moreover, the complete context of the UI handed over to the workflow.
   
   Note: RTE will not get invoked if the business object, on which workflow is based on, is different from the UI context BO. 
   
   
2. In the scenario where point#1 can't be used due to any reason i.e. workflow is not based on any BO, then the only way to pass the Row Id or any other field values of the current record to the workflow is via setting the profile attributes. In the RTE action set, you can set the profile attibutes as the first step and in the next step call the desired workflow. Then inside the workflow, you can read the profile attribute values.
   .
3. One of the tracking feature that OOB provides is, if you have "Monitoring Level" set to "4 - Debug" for a workflow process, and if that workflow process being called from RTE then system automatically add a new property named "Triggering Event" with the Row_Id of RTE. So it becomes easy to track the triggering event.

How to migrate Runtime Events (RTE) from one env to another env?

Runtime Events (RTE) and Data Validation Manager (DVM) are the two highly used features whenever there is a requirement for imposing business rules in the process. Every another project has their own business rules to implement and Siebel developers use RTE and DVM as their first choice (mostly). Problem comes in when you are done with the development and now its time to move the RTE and DVM (Rule Sets) to different Env (QA, UAT etc). So if you have plenty of RTE implmented, it would be cumbersome job to create those RTE again in different env at various stages of the project life cycle.

To ease the job, Siebel has provided the way for taking the export it into a XML file and again import it back into another env. Runtime Events -> Menu -> XML Import/XML Export.

But, the irony is, it doesn't work as you expect. The basic assumption would be, you query your RTE, take the XML export and import the XML file into other env. System should get the new RTE created for you. But the reality is, this way you will end up exporting "ALL" RTE from the source env to destination env (which you never wants).

So, how to get the Runtime migrated?

1. Navigate to ‘Administration Deployment Manager -> Deployment Projects’. Click ‘New’ and create a project for exporting the RTE. Remember to check ‘Export to File’ flag to ‘Y’.
2. In the below applet create a new record and pick ‘Data Type Name’ as ‘Personalization – Events’. Save the record.
3. Expand the ‘Data Type Name’ (by clicking on the + icon)      
4. Drill down on the ‘Personalization – Events’ and you are navigated to ‘Administration Runtime Events -> Events’
5. Query for the event you want to export and by using "Query Assistant", save this as PDQ.
6. Again go back to your deployment project at ‘Administration Deployment Manager -> Deployment Projects’ and in the pick applet for the field ‘Deployment Filter’ against ‘Personalization – Events’ select the name of the PDQ you saved in the above step.
7. Now Drill down on the ‘Personalization – Action’ and you are navigated to ‘Administration Runtime Events -> Action Sets'
8. Query for the Action Set associated with your event you want to export and by using "Query Assistant", save this as PDQ.
9. Again go back to your deployment project at ‘Administration Deployment Manager -> Deployment Projects’ and in the pick applet for the field ‘Deployment Filter’ against ‘Personalization – Actions’ select the name of the PDQ you saved in the above step.
10. Check your configuration by clicking ‘Validate Filter’ button. If everything is fine click the ‘Enable’ button on the top applet. Status of your deployment project changes to ‘Enabled’ from ‘Draft’.
11. Now go to ‘Administration Deployment Manager -> Deployment Sessions’. Create a new record and select the project you created in step 1.  Save the record
12. Press the ‘Deploy’ button on the top applet and give the path on the server (if connected to thin client) or local machine (if connected to thick client) where you want the export file to be generated.
13. Status changes to ‘Export Completed’ and the field ‘Log’ gives you the name of the xml file generated as a result of your export.
14. Copy the xml files generated to you local machine (if connected to thin client)
15. Go to the ‘Administration Data Manager -> Deployment Sessions’ on the server where you want to import your RTE. Click ‘Menu’ and select ‘Deploy From Local File’ and give the path where you have saved the xml files created and press ‘Import'.
16. Your RTE will be created in the target system.

Special thanks to Manuj Garg for sharing this information.

How to update Child BC records on update of Parent BC record?

Siebel provides various ways of achieving the same solution, but you need to do the analysis beforehand to pick the right one. Recently I got one basic requirement that:

As soon as the Opportunity Sales Stage gets "Approved", all the Activities (Child of Opportunity) status should automatically set to "Approved".
Any Siebel Geek can offer multiple ways to achieve this solution:
1. Write a small script on "WriteRecord" event of the Opportunity business component.

2. People against scripting will not like Point#1 above and they might suggest to create a Workflow process with an Update operation on Action business component. And call this Workflow process in WriteRecord event of Opportunity or by Runtime event or by Workflow Policy.

3. Trigger a Workflow Policy when Opportunity Sales Stage = "Approved" which will call a WF Policy action with a program of type DB Operation.

I found another way of achieving the same solution (scriptless) and want to share with you. Using Data Validation Manager (DVM), you can achieve this as well. If you know how to update a field (SetFieldValue) using DVM, you might know what I am talking about.

Solution Details: 1. Navigate to Administration - Data Validation -> Rule Sets view.
2. Create a new record with the following data:

Name : Set Activity Approved
Business Component : Opportunity
Business Object : Opportunity

3. Drilldown on Rule Set Name.
4. Create new record under Rules view.

Sequence# : 1
Name : Set Status to Approve
Expression : [Status]="Approved"
Business Component : Action
Apply To : All Records
Return Code : Select any return code from the pick applet

5. Navigate to "Action" sub-view under the "Rules" view.
6. Create new record in Action applet:

Sequence# : 1
Type : Business Component
Business Component : Action

7. Create new record in "Field Values" applet

Field : Status
Value : Approved

8. Navigate to Administration - Data Validation -> Rule Sets view again and Activate the Rule set you just created.
9. Status changes to "Active".
10. Navigate to Administration - Runtime Events -> Action Sets view.
11. Create a new record:

Name : Activity Approved
Active : True

12. Create new action record:

Name : Call DVM
Action Type : BusService
Sequence : 1
Active : True
Business Service Name : Data Validation Manager
Business Service Method : Validate
Business Service Contect : "Rule Set Name", "Set Activity Approved", "Enable Log", "Y"

13. Navigate to Administration - Runtime Events -> Events view.
14. Create new record:

Sequence : -1
Object Type : BusComp
Object Name : Opportunity
Event : WriteRecord
Conditional Expression : [Sales Stage]="Approved"
Action Set Name : Activity Approved

15. Reload the runtime events.
You are done.

Now this is the time to test the solution:
1. Navigate to Opportunity -> Activities View.
2. Change the Sales Stage to "Approved".
3. See the change in activities status.