Siebel workflows are quite for powerful validation and automation tools. I’ll even go to the extent of recommending workflows as one-in-all solution, as a vehicle for your more complex scripting needs, and for integration of course.

Siebel offers quite a number of methods to invoke workflows -

• From runtime events
• On button click using user properties/ script
• Using BC/Field user property, triggered by field updates
• From scripts

Although design decision to invoke workflows depends on a specific situation, one-time events provide the most versatile way of invoking workflows ( or performing other supported actions for that matter).

How to trigger workflows by runtime events? #

You can use any event supported by runtime event, and trigger a workflow process based on that event.

Three examples-

Trigger on button click #

The simplest way to trigger a runtime event for a custom action is to use the InvokeMethod.

You configure button on the applet as usual, and will provide the event name of your liking. It has to be prefixed with “EventMethod”.

For example consider “FINS BIB Limit Child List Applet”.  A button called “Get Details” fetches the limit For the particular contact from the backend system.

You then create a runtime event in the application by navigating to “Administration – “Runtime Events”.

Create an action set that may have one or more actions, and tagged against this event.

The action set will have commands to invoke workflows. It will simply use the “workflow process manager” to execute workflow - nothing fancy there.

The biggest advantage of this method is that you do not need to “handle” the EventMethod* events. Siebel simply ignores those events, and leave it to you to configure runtime events that can handle the custom event.

Trigger on custom events #

You could also trigger runtime events for custom defined events. For example you want to save the record, perform a few validations and then go about triggering the workflow. You could then use custom event with any name, and use InvokeMethod to handle the method through runtime event as appropriate.

The InvokeMethod event can be defined at the applet, or at the BC level.

Trigger on field update. #

You can simply define a runtime events on “PreSetFieldValue” or “SetFieldValue” events.

Now, whenever the field gets updated the associated runtime event is triggered, runtime event executes the workflow is defined in the action set.

Advantages of using runtime events #

• You don’t need to perform additional configuration or write additional scripts to invoke workflows
• ID of the active record is automatically passed across to the workflow as the “Object ID”. This will set the current context for the workflow
• Runtime event is more flexible. Activating or inactivating a specific event is as simple as checking the flag, and reloading runtime events. There is no change to the code
• You can tag more than one action to one runtime event. Just sequence actions in the action set and you are all set!
• You can make the process a synchronous in runtime. Just call a service to execute workflow synchronously instead of Workflow Process Manager.

When not to use runtime events? #

There are certain cases and situations where runtime events may not be the ideal solution.

• Workflows are not tagged to a business object. In certain cases you do not want to have a business object because the extra queries are not adding any value
• You need to pass additional parameters to the workflow other than the Object ID
• When there were only a couple of fields to be updated or very simple actions to be carried out. You’re better off using user properties rather than triggering off runtime events