Skip to Content

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:

  1. GetIDFromName – gets the SI_ID of an object based on name and, optionally, kind or parent ID.
  2. GetNameFromID – gets the name of an object based on its SI_ID value.
  3. GetParentPath – walks up the parent list and returns a string that represents the path.
  4. ExecuteQuery – returns a set of InfoObjects that are the results of a CMS query.
  5. GetLogonToken – returns a token based on the current session.  This can be used in calls to OpenDocument.
  6. 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.
  7. 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:

    1. FolderInfo
      • Name
      • ID
      • Parent ID
      • Subfolders (TreeNodes or List<FolderInfo>
        in .NET, ArrayList<FolderInfo> in Java).
      • Object Counts by type of object (Crystal, Webi,
        Dashboard, etc.)
    2. ReportInfo
      • Name
      • ID
      • ParentID
      • Kind
      • Schedule Count
      • Last Run
      • Universe
      • DB Connection Info (for non-universe based
        Crystal reports)
      • Parameters/Prompts
    3. UserInfo
      • User Name
      • User Full Name
      • ID
      • 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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Britton Gray

    Thanks for the great info, Dell.  As I’m trying to work to extract universe objects out of a 3.1 (!) system, this is very useful!

    Tell everyone I said “Hi” 🙂

     

     

    (0) 
    1. Dell Stinnett-Christy Post author

      Thanks Britton!

      You’ll use the Designer SDK for that, which is a bit of a pain because it is COM based.  This means you’ll probably want to code in .NET instead of Java.  You’ll also need to make sure to explicitly call .Dispose() on the objects or make them part of a “using…” statement when you can.  You’ll do this because .NET doesn’t memory manage COM objects very well, so you’ll need to handle that.  Also, make sure  that at the end of your program you close any universe(s) you have open and then call .Quit() for the application and Marshal.FinalReleaseComObject(application) in order to unload the Designer application from memory.

      Let me know if you’d like me to send you some sample code.

      -Dell

      (0) 

Leave a Reply