Tuesday, February 26, 2013

Accessing Siebel with COM


Siebel has a set different technologies to integrate with other systems, including online and batch interfaces.

Those different technologies have different advantages and drawbacks, and their application depend heavily on the nature of the task to be executed and the environment available.

One of those interfaces available for usage is the COM interface.

COM is an abbreviation for "Component Object Model" developed by Microsoft as a framework for developing modular software components and to support integration services (exposing functionality and data transfers).

COM is available for Siebel in Microsoft Windows environments only (since COM is a Microsoft exclusively technology) in three different "flavors":
  • Automation server
  • Data server
  • Data control
In this article I'll talk only about Data Control and Data Server: the programming interface for both is almost the same as you will be able to see later, although there are important architecture differences between them, including connection details.

Usually using Siebel COM Data Control is preferable to use since it is faster to load and execute and can multiplex connections to a Siebel Enterprise, but DataServer still have it's specific uses:
  1. Provides CRUD operations in the Siebel Client local database.
  2. Avoid object restrictions in the Siebel Repository by using a local modified SRF.
  3. Avoid security restrictions applied to the Siebel Enterprise, like firewalls and authentication.

Through COM usage, any language that supports it can connect to Siebel and have access to it's internal objects, more specifically the Business Layer when talking about Siebel COM Data Control or Data Server. Some examples include VBA, Windows Powershell and Perl.

The best document to start reading about Siebel COM is the 1402536.1 "Master Notes For COM and JDB(Java Data Bean) Interface Issues": it has references to other documents about Siebel COM. The bookshelf "Siebel Object Interfaces Reference" is another must read resource.

Getting to know the API requires checking the proper documentation available. When they are not available, you can consider yourself lucky if you have Microsoft Office installed, since you can check the API documentation from the DLL itself by using the Microsoft Visual Basic for Applications editor and checking the references loaded:


You must have the Siebel Client installed in a Microsoft Windows 32 bits OS. This includes Windows 7, although Oracle claims it does not supports Siebel 8.1 in such OS.

Even after installing the Siebel, sometimes the required DLL's are not registered correctly (see DLL Hell for details on that). Below is a quick reference for the DLL's that you need to have:

Siebel Interface Programmatic Id DLL/TLB
Siebel COM Data Server SiebelDataServer.AplicationObject sobjsrv.ltb
Siebel Data Control SiebelDataControl.SiebelDataControl.1 sstchca.dll


It is easy to setup if you are in a Microsoft Windows environment. Generally speaking, if you have a Siebel Client installed, you already got everything you need to use Siebel COM.

If you consider VBA, you can even get data into your Excel spreadsheet, which is a huge advantage if all you need is make data available to end users. Sometimes, it is probably easier than creating customized reports and making them available for them.

Siebel COM is also useful to provide quick data fixes, retrieve information which would be much more complicated if done from the Data Layer or even "upserting" small amounts of data.

In some specific scenarios, you could provide additional functionality to Siebel Mobile users by connecting to the local database or even doing data changes by using a modified local SRF which would not be possible due restrictions in the "regular" SRF (that could be a dangerous thing to do, but it is possible).


As simple as it looks like, COM does have it's caveats. Siebel and in fact even .NET, while still supporting it, are replacing it with other technologies.

For example, Powershell uses the .NET support to COM by using of an interop assembly, which is a special .NET Framework assembly that connects complex COM components to the .NET Framework. Sometimes a COM component doesn't have it's interop counterpart available, so when you try to instantiate it all you got is a connection to the interop assembly and not the COM component itself, resulting in not having the proper access to the properties and methods from the component (to solve this, use the "-strict" parameter with New-Object cmdlet).

Another drawback for using COM is that you cannot use it with systems that are not Microsoft based: you cannot use it from Linux, for example (but you can use a Microsoft Windows workstation to connect to a Siebel Enterprise based on Linux).

Other issues are related to scalability and speed: some resources even suggest that when necessary only to query Siebel to use direct queries to the database instead using the AOM for speed. Scaling COM with Siebel should involve using more AOM instances to connect, probably doing that with a load balance (refer to document 478270.1 "Use of Native Load Balancing With Java Data Beans Interface and COM Data Control Interface" for more information about that).

Since COM uses DLL's, there is still a present issue regarding 32 and 64 bits support: when writing this article Siebel still does not support usage of COM in 64 bits systems, as show in document 1393381.1 "Can COM Interface Be Used in a 64 Bit Environment in 64 Bit Mode?". As it seems, it is just a matter of time that you won't be able to use COM anymore when we stop to use computers with 32 bits support. Maybe Oracle will update those DLL's, but I would not bet on that.

There are more issues related to COM. You can check more examples at Wikipedia webpage about COM.


There are several examples available in the internet to use Siebel COM with VBA and even Perl. I'll restrict to show an example with Windows Powershell since I could not find any when writing this article.

set-strictmode -version 2.0
$siebelApp = New-Object -ComObject "SiebelDataControl.SiebelDataControl.1" -Strict

$gateway = "siebdev"
$server = "siebdev"
$langCode = "ENU"
$enterprise = "SIEBEL"
$aom = "eFoobarObjMgr_enu"
$connAddress = "host=""siebel://$gateway/$enterprise/$aom"" Lang=""$langCode"""
$user = "foo"
$password = "bar"

try {

    if ($siebelApp -is 'System.__ComObject') {

        Write-Host "connecting to" $connAddress
        [void] $siebelApp.Login($connAddress, $user, $password)
        if ( $siebelApp.GetLastErrCode() -ne 0 ) {
            write-host "Not possível to connect to" $connAddress
            throw $siebelApp.GetLastErrText()
        } else {
            write-host "Connected to server $server"
            try {
                $bo = $siebelApp.GetBusObject("Contact")
                $bcContact = $bo.GetBusComp("Contact")
                [void] $bcContact.ClearToQuery
                [void] $bcContact.SetViewMode(3)
                [void] $bcContact.ActivateField("First Name")
                [void] $bcContact.ActivateField("Last Name")
                [void] $bcContact.ExecuteQuery(257)
                if ($bcContact.FirstRecord()) {
                    do {
                        $string = "First Name =" + $bcContact.GetFieldValue("First Name") + ", Last Name = " +  $bcContact.GetFieldValue("Last Name")
                        Write-Host $string                  
                    } while ($bcContact.NextRecord())

                } else {
                    Write-Warning "It was not possible to find any contact"

            } catch {

                Write-Host $error[0].exception -ForegroundColor red

            } finally {

                remove-variable -name bcContact
                remove-variable -name bo

                [void] $siebelApp.Logoff()



    } else {

        throw "It was not possible to connect to Siebel"


} catch {

    Write-Host $error[0].exception -ForegroundColor red

} finally {

    write-host "Releasing resources" -foregroundcolor green

    remove-variable -name bcContac
    remove-variable -name bo
    remove-variable -name siebelApp

Let's comment some details about this code.

First thing is the "-strict" option when creating the COM object: this is necessary to raise an exception if, for any reason, the COM object cannot be instantiated.

It is also a good idea to check to if the object created is really a COM object, since this will avoid calling methods from an invalid object: -is 'System.__ComObject' does that.

Another good idea is to turn on automatic exception from the Siebel Data Control: EnableExceptions method will do just that.

You will notice that some methods invocation have a "[void]" prefixed to them: this is useful because those methods returns something but usually you won't want those thing to go to standard output (as Powershell does by default). Also, automatic exceptions are turned on, so don't worry too much about checking methods returns.

Unfortunately, Siebel COM will not give you constants for free. That's why you will need to use the numeric value of them as done in ExecuteQuery() method or create those constant yourself.

Everything else should be straightforward if you have already programmed with eScript. I tried to make some effort by using try/catch/finally to check for exceptions, trying to logoff automatically and release the objects created with remove-variable cmdlet, but during my test by turning on trace with Trace method did not showed any different by using such schemes (to release objects), at least in this example.

Get your feet wet

If you know how to program with anything that supports COM, then you have a good chance to do yourself a favor and stop using EIM for simple things like updating 50 accounts or even doing it by hand. Automation with Siebel COM is a real option, just don't try to take it too much seriously as putting thousand of requests/data over it.