|Bookshelf Home | Contents | Index | PDF|
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.
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.
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.
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.
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.
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,
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.
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.
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:
|Siebel Reports Administration Guide|