My Philosophy/Methodology for Working with the BI Platform SDK
I have been working with the BusinessObjects .NET SDK for about 8 years and the Java SDK for about 2. In the last couple of years, I have been upgrading code from the XI r2 and XI 3.x to BIP 4.x for clients – and refactoring their code in the process to make it easier to maintain. Over this time I have developed a very specific pattern for what I do with the SDK.
1. I create a class for logging in to the platform and handling various querying tasks. The constructor for this class, which I usually call BOECommon, has parameters for the User ID, Password, CMS Name, and authentication type (secEnterprise, secWinAD, Trusted etc.) The constructor uses this information to log in to the system and instantiate an InfoStore (.NET) or IInfoStore (Java) object. This class contains methods such as:
- GetIDFromName – gets the SI_ID of an object based on name and, optionally, kind or parent ID.
- GetNameFromID – gets the name of an object based on its SI_ID value.
- GetParentPath – walks up the parent list and returns a string that represents the path.
- ExecuteQuery – returns a set of InfoObjects that are the results of a CMS query.
- GetLogonToken – returns a token based on the current session. This can be used in calls to OpenDocument.
- GetFolderTree – returns a “tree” type structure that contains information about all of the subfolders and reports under the folder specified as a parameter to the method.
- GetObject – retrieves a single InfoObject, with a specified set of fields and a specific filter. If there is more than one object that meets the criteria, an error is thrown.
2. I also create a class for each type of interaction with the BI Platform. So, for example, BOEUserMaintenance provides functionality to add, edit, and delete users and BOESchedule provides functionality for scheduling reports. Each of these additional classes take the BOECommon object as a parameter in its constructor so that it has access to the InfoStore for running CMS queries.
3. Like the “folder”class mentioned in 1.f. above, I also have a set of “Info” classes that contain information about a specific type of object. The constructors for these classes usually take an InfoObject as a parameter and then convert it into the “info” class. Some examples of these are:
- Parent ID
- Subfolders (TreeNodes or List<FolderInfo>
in .NET, ArrayList<FolderInfo> in Java).
- Object Counts by type of object (Crystal, Webi,
- Schedule Count
- Last Run
- DB Connection Info (for non-universe based
- User Name
- User Full Name
- List of groups of which the user is a member
- Last login date
- Aliases, including source of the alias
(Enterprise, WinAD, LDAP, etc.)
Abstracting all of the code that interacts with
BusinessObjects out into classes provides a couple of advantages:
1. I don’t have to write the same code multiple times in different modules – all that my applications need to do is reference the classes I’ve created and then use their methods to interact with BusinessObjects.
2. If BusinessObjects is being upgraded and there are changes to the SDK – like the major changes in the upgrade from 3.1 to 4.x – I only have to update one set of code and then recompile all of my applications instead of having to update lots of similar code in each application.
If you’re interested in seeing some of what I’ve done with this, I have sample C# code available on my website – www.dellstinnett.com/sample_code.html. In particular look at the more recent samples for BO 3.1 and BI 4.0 – some of my early code for XIr2 is also on the site, but it doesn’t always follow the pattern I’ve described because this has evolved over the years that I have been working with the product.