Siebel Reports Administration Guide > Understanding Your Reports Development Environment > Migration Instructions for the Siebel Reports Server >

Migrating PreSiebel 6 Custom Reports to the Siebel Reports Server

CAUTION:  The information in this section only applies to migrating custom reports from Siebel 99. For more information about migrating custom reports for version 6 and later, see Migrating Custom Reports.

Custom reports that were written for Siebel eBusiness Applications versions earlier than Siebel 6.0 will not run successfully on the Reports Server. The Actuate Basic code for methods and custom reports must be modified to achieve compatibility with the Reports Server environment. This section explains the changes that must be made to the code.

Reporting in the preSiebel 6.0 environment used OLE automation directly between a Siebel application and Actuate software, which was located on the same client machine. This kind of communication is not available for the Reports Server and Siebel Web clients.

Instead, library methods are provided that allow access to objects in a platform-independent fashion. Object variables in your custom design and library files must be replaced with integer variables that refer to the corresponding objects, and object methods must be replaced with stand-alone methods.

When a data supply library file is generated from Siebel Tools version 6.0 and later, the generated file contains updated data access logic that uses the new library methods. If you have custom reports, you must regenerate their data supply library files from Siebel Tools 6.0 and later, or they will not work in server reporting or thin client modes.

About sssiebel.bas Library Functions

Communication between Siebel and Actuate software is enabled in Siebel 6.0 and later by library functions in an Actuate Basic file, sssiebel.bas. The sssiebel.bas file has been loaded into the sssiebel.rol library in Siebel 6.0 and later, and does not need to be explicitly included in each design file. The sssiebel.bas functions provide the report with a system-independent interface to communicate with the Siebel Application Server. While sssiebel.bas functions were used in a limited set of roles in preSiebel 6.0 reporting, the role of this library file has expanded to include object interface functions.

The object interface functions in sssiebel.bas are designed to be the sole interface to the Siebel Application Server from all reports, whether standard or custom. In standard reports, the appropriate changes have already been made, and these upgraded files are installed when you upgrade the Siebel application. Your custom reports will, in most cases, run successfully on the Reports Server following regeneration of the data supply library file from Siebel Tools and recompilation of the report design in Actuate e.Report Designer Professional.

If a custom report works successfully in client reporting mode and does not work in server reporting mode, you will need to locate and replace any Microsoft Windows-specific and object interface function calls with calls to sssiebel.bas object interface functions.

Changing Object Variables to Integer Variables

The sssiebel.bas functions abstract the Siebel Application Server in terms of four basic objects: model, business object, business component, and property set. These objects can be accessed only using the sssiebel.bas functions. The report uses references of type Integer to these objects.

NOTE:  Model refers to the handle to the top-level object exposed by the interface. In the case of OLE/COM, this is SiebelApplicationServer. The PropertySet object is described in the Siebel Object Interfaces Reference.

All variables of type Object should be changed to type Integer. Functions in sssiebel.bas take these integer references as arguments, using the references to access objects and perform operations on them.

The integer value is a handle to an automation or C++object. Variables such as ssAppServer, ssBO, theBC, and AppServer change from object variables to integer variables. For example,

Set theBC = ssManaged_Person_Forecast

.

.

ssManaged_Person_Forecast.InvokeMethod(...)

changes to

theBC = ssManaged_Person_Forecast

.

.

ssBusCompInvokeMethod (ssManaged_Person_Forecast, ...)

Since all these variables have been converted to type Integer, they can no longer be used as objects with their own methods. Instead, special methods in sssiebel.bas are used to manipulate the objects, such as ssBusCompInvokeMethod in the preceding example. These substitute methods are described in About Method Name Prefixing.

NOTE:  Since the variables are integers, comparison expressions can no longer use "is Nothing" and need to be changed to "= 0".

About Method Name Prefixing

Methods on business components, fields, business objects, and application servers can no longer be affixed to object variables and separated by a period. These object variables are now integer reference variables, as previously described. New stand-alone methods provided in sssiebel.bas perform the same functions previously performed by object methods. These have the same names as in the Siebel Object Interfaces, but are prefixed with ssBusComp, ssBusObj, or ssModel.

Using ssBusComp as the Prefix for Business Component Variables

Whenever an API method makes use of business component variables or names, a substitute method with a prefix of ssBusComp is used. For example, FirstRecord becomes ssBusCompFirstRecord, SuppressNotification becomes ssBusCompSuppressNotification, and so on. For example,

theBC.FirstRecord (errCode)

changes to

ssBusCompFirstRecord (theBC)

Methods with an argument list lose the errCode argument at the end of the list and acquire the business component integer argument at the beginning. For example,

theBC.GetFieldValue ("City", errCode)

changes to

ssBusCompGetFieldValue (theBC, "City")

A reference to a specific business component, such as a business component variable, is moved into the argument list as the first argument, as follows:

ssOpportunity.SuppressNotification (errCode)

changes to

ssBusCompSuppressNotification (ssOpportunity)

Field methods adopt the ssBusComp prefix as well. A first argument is added for the field name, and the errCode argument is dropped. For example,

ssAccount.SetSearchExpr (searchSpec, errCode)

changes to

ssBusCompSetSearchExpr (ssAccount, searchSpec)

and

ssAccount.SetViewMode (ssReport::ssViewMode, errCode)

changes to

ssBusCompSetViewMode (ssAccount, CInt (ssReport::ssViewMode))

This latter example illustrates the setting of the view mode (visibility). The view mode can be explicitly set to user view, manager view, and so on. For more information, refer to SetViewMode in the Siebel Object Interfaces Reference. The ssBusCompSetViewMode function expects the ssViewMode value in integer format, but the parameter in ssReport is a string and needs to be converted.

Using ssModel as the Prefix for AppServer-Related Methods

AppServer-related methods are prefixed by ssModel. The errCode argument is removed, and the application server name or variable becomes the new first argument. For example,

ssAppServer.ActiveBusObject (errCode)

changes to

ssModelActiveBusObject (ssAppServer)

and

ssAppServer.GetBusObject (ssReport::ssBusObjectName, errCode)

changes to

ssModelGetBusObject (ssAppServer, ssReport::ssBusObjectName)

Using ssBusObj as the Prefix for Business Objects

The names of methods related to business objects are prefixed by ssBusObj. The errCode argument is removed, and the business object name or variable becomes the new first argument. For example,

busObjName = ssBO.Name (errCode)

changes to

busObjName = ssBusObjGetName (ssBO)

and

ssBO.GetBusComp ("Account", errCode)

changes to

ssBusObjGetBusComp (ssBO, "Account")

Replacing InvokeMethod for Use with Business Component

InvokeMethod is replaced by ssBusCompInvokeMethod when it is used by a business component. It is replaced by ssModelInvokeMethod when it is used by appServer or ssAppServer. Also, in both cases, the errCode parameter is no longer used.

For an invoked method on a business component,

theBC.InvokeMethod ("Account Status", errCode)

changes to

ssBusCompInvokeMethod (theBC, "Account Status")

For an invoked method on the application server,

AppServer.InvokeMethod (parameters)

changes to

ssModelInvokeMethod (parameters)

About Message Boxes

Reports often use message boxes for reporting errors. However, message boxes are relevant only on the Windows platform on a client machine, and do not work when reports are being generated in batch mode on a Reports Server. sssiebel.bas provides operating-system-independent functions for error reporting, with behavior appropriate to the environment in which the report is executed.

The MsgBox function in method code in ROL and ROD files is replaced with ssDisplayMessage or ssProcessLastError, depending on whether an AppServer variable is used. For a message box that presents an information string, ssDisplayMessage is used, as follows:

MsgBox (string)

changes to

ssDisplayMessage (string)

A message box that makes use of the AppServer or ssAppServer variable uses the ssProcessLastError function.

MsgBox ssAppServer.GetLastErrText ()

changes to

ssProcessLastError (ssAppServer, "", "")

The syntax for the ssProcessLastError function is as follows:

ssProcessLastError (object_integer, pre_message_string, post_message_string)

Changing CreateObject to ssConnect

CreateObject changes to ssConnect. ssiSiebelServer is a global integer variable that keeps track of the connection. For example,

If (ssAppServer is Nothing) Then

Set ssAppServer = CreateObject (ssReport::ssOLEServer)

If (ssAppServer is Nothing) Then

Start = False

Exit Function

End If

End If

changes to

ssReport::ssiSiebelServer = ssConnect(ssReport::ssOLEServer)

If (ssReport::ssiSiebelServer = 0) Or (errCode <> 0) Then

ssDisplayMessage ("Login Failed!")

Exit Sub

End If