BS

Many thanks to all commenters who chimed in and elongated the list of useful standard
business services which every Siebel developer should know about.
Today we open the library with the family of Server Request business services. The following
business services will be discussed in this post.


Asynchronous Server Requests



Synchronous Server Requests



Server Requests



Synchronous Assignment Manager Requests



Workflow Process Manager (Server Request)

These business services all use the same class CSSSrmService. Their purpose is to allow
developers to submit component requests (aka Jobs) to the Server Request Broker from any
place in Siebel such as workflow processes, scripts or runtime events (to name a few popular
locations for business service invocations).
Let's investigate the first three business service in the above list. Inspection in Siebel Tools shows
that the Asynchronous, Synchronous and generic variant of Server Requests business services
have a common method named SubmitRequest. The differences between the three Server
Requests business services are laid out as follows:
The Asynchronous Server Requests > SubmitRequest method allows to specify input
arguments to create a non-repeating or repeating job in the S_SRM_REQUEST table. Everyone
who used the Jobs view in the Administration - Server Management screen knows how to do this
manually. The job will execute asynchronously which means that the SubmitRequest method will
return immediately its only output argument reqId having the ROW_ID value of the new job entry.
The asynchronous nature of the jobs submitted is driven by the Business Service User
Property named Mode which is set to a value of DirectDbfor the Asynchronous Server Requests
business service.
There we have the main difference to the Synchronous Server Requestsbusiness service
which has the Mode user property set to Sync which causes a synchronous execution of the
submitted job. Therefore the SubmitRequest method of the Synchronous Server Requests
business service will wait for the job to complete before returning with the reqId value plus
a reply string which will be empty for a successful job execution and carry an error message in
case of job failure. Because the job is run immediately, we can not use the Synchronous Server
Requests business service to create scheduled or repeating jobs.
The Server Requests business service's SubmitRequest method demandsMode as an input
argument, so the developer can choose the execution mode at runtime. The following are valid
values for the Mode input argument:


DirectDb: Asynchronous mode with data written to the S_SRM_REQUESTS table. The
job will always be visible in the Jobs view. Its parameters will not be written to the
database.



Async: Asynchronous mode without writing data to the database.



Sync: Synchronous mode



Schedule: Scheduled execution at the specified start time



Auto: SRBroker will set the mode to Scheduled when the requestor client is a mobile web
client and to Sync when the business service executes on a server component.

The other input arguments for the SubmitRequest method are nicelydescribed in Siebel
bookshelf and not reiterated here.
The CancelRequest method (not available for the Synchronous Server Requests BS) allows to
submit a request id and cancel the respective job.
Testing Server Request business services
If we have a safe test environment with a running Siebel Server, we can test drive the server
request business services similar to any other business service in the Business Service
Simulator.
The following scenario describes how to use the BS Simulator to invoke the SubmitRequest
method of the Asynchronous or Synchronous Server Requests business service. To make the
example simple, we use theGenerate Triggers (aka GenTrig) component.
1. In the BS Simulator upper applet we create a new record for the Asynchronous Server
Requests business service and its SubmitRequest method.
2. In the Input Arguments list applet, we create a new record and specify the Component input
property with a value of GenTrig. Note: We must use alias names for components and their
variables.
3. The tricky part is to pass the parameters for the component in the first child property set. So we
must create a new child in the Input Arguments list and provide the parameters - using their alias
names - needed to successfully execute the job.
For the GenTrig component, we can specify the following properties in the first child property set:


EXEC = FALSE



PrivUser = SIEBEL



PrivUserPass = tblo_password

The screenshot shows the Synchronous Server Requests BS tested in the BS Simulator.
The child property set contains the parameters for the component.
4. Ensure that the Generate Triggers component is online on the server and click Run.
If we use the Asynchronous Server Requests BS, the output arguments list will populate
immediately and the output property reqId will have the value of the job's ROW_ID.
When the Synchronous Server Requests BS is tested, we notice that the simulator will come

back only when the job on the server is finished and we have a reply output property.
Passing component parameters in workflow
When we use the server requests business services in a workflow process we must use the dot
notation to specify a child property set as the location for the component parameters.
This is described in more detail in this bookshelf example of invoking Enterprise Integration
Manager (EIM) from a workflow process.
We can use the BS Simulator to test the Server Requests BS as well as the two specialized
business services named Synchronous Assignment Manager Requests and Workflow
Process Manager (Server Request).
As their names suggest, they are limited to the Assignment Manager (AsgnSrvr) and Workflow
Process Manager (WfProcMgr) server components. This limitation is specified in the BS user
propertyComponent. Both are synchronous by nature.
The only method "Assign" for the Synchronous Assignment Manager Requests BS is designed
to invoke Assignment Manager for a single record and takes the following input arguments:


AsgnObjName: Name of the assignment object



ObjRowId: ROW_ID of a record to be assigned

The reply output argument carries the Assignment Manager's output.
The Workflow Process Manager (Server Request) BS has a single method
named RunProcess which takes the name of the workflow process to run in
the ProcessName input parameter and an optional ROW_ID to populate the Object Id (RowId)
process property.
Discussion
The family of server request business services allows developers to invoke asynchronous and
synchronous component requests - aka Jobs - against the Server Request Broker. This can be
very powerful because it also enables us to distribute load across servers but also has some
limitations.
For example it is not easy to track the success or failure of an asynchronous server request. In
addition, we invoke a second process which possibly runs on a different machine which brings up
the problem of locating the log files on different Siebel servers.
Documentation
The Workflow Guide in Siebel Bookshelf contains the majority of information how to use the
server request business services family.
Have a nice day