Business Objects in workflows help you maintain the context and use Siebel Operation Steps inside workflows. You will not be able to use Siebel Query, Insert, Update step if you don’t provide Business Object in Siebel Workflows.

When you execute a workflow through runtime event or a user property then the active Business Object context is passed to the workflow which allows workflow to work on any child business component records without actually need to query on the BC.

Below given link will provide an example of such behavior

http://siebelunleashed.com/closing-service-request-–-scriptless-siebel/

P.S: Data Validation Manager (DVM) works similarly using Active BO context

I am back with an interesting interview question that I have been asking in past few interviews that I have taken and surprisingly nobody has been able to answer it correctly.

It is quite a simple question and answer is even simpler but people are just not aware of it.

Question:

Create a workflow that will query Opportunity with status as “Won” and then update the status of these opportunity records to “Closed”.

*Need to accomplish this inside the workflow without using any kind of script.

Usual Answer:

Usually candidates are able to answer till the query part which is using the Siebel Operation “Query” Step but they are stumped at the part of updating “Multiple Records” inside workflow as there is no looping mechanism available inside workflow (till Siebel 7.x). So, usually they say that we need to invoke a business service which will loop through records and update.

Actual Answer:

Actual answer is that you just need to use “Siebel Operation” step again with “Update” operation and Siebel will update all the records that are returned by “Query” step.

This behavior is possible due to Business Component that we give in “Siebel Operation” step and Siebel is able to maintain the BC context created by Query method and update method uses this context to udate all the records returned by Query method

I found a really good post explaining this with help of an example workflow.

Question:

What is difference between invoking a workflow through:

• Run Process on the Server “(Administration – Server Management > Jobs)”
• Run process using business service “Workflow Process Manager (Server Request)”
•  Run process in application object manager using business service “Workflow Process Manager”

Answer:

If we run a workflow process through Administration – Server Management > Jobs or using “Workflow Process Manager (Server Request)” it will be executed in Asynchronous mode

If we run Workflow process through BS “Workflow Process Manager” it will run in Synchronous mode.

Difference between Asynchronous and Synchronous mode:

• Asynchronous mode means that user does not have to wait for process to complete. He will get the control back after submitting the request and Server will execute it later.In Synchronous mode user will get the application control back only, when the execution of the process is complete.

• In case an error occurs while running the asynchronous process user will not get any error message and workflow will go in Exited state.In case of error in Synchronous mode, error message is displayed to the user (unless it is explicitly suppressed through error handling)

• As Asynchronous processes are executed in server context any function related to user session will not work. For example following functions will return null if used in a workflow process running in Asynchronous mode.TheApplication().ActiveBusObject();
TheApplication().GetProfileAttr();
TheApplication().ActiveViewName();
• Above given functions will work fine if that process is executed Synchronously without any change.

Purpose:

Stop steps are used to raise an error to User and terminate workflow process.
End Step is used to mark the end of workflow.

Mandatory:

It is necessary to have one End step in workflow
It is not necessary to have Stop step in workflow

Arguments:

End step cannot have input arguments
Stop set cannot have output arguments

Workflow Status:

Stop step sets the status of workflow as “In Error”
End step sets the status of workflow as “Completed”

We have to use connector of Type “Error Exception” to handle exceptions in workflow. Exception Connectors are shown in red color in Workflow Process Designer Palate (You can change the color though).

So, be sure to check the “Type Field” of the connecter.  It should be “Error Excpetion”