1) Where do I run the SDK in my application stack?
There are 3 main architectures for SDK enhancement:
a) InfoView Modification (i.e. hacking) – This involves changing and/or adding to the code that runs the InfoView application. While this seems like the shortest path it provides several challenges:
i. The InfoView has several hooks for customization but not for things like changing menus, adding buttons, custom messages, etc.
ii. Modifications will be eliminated as each BusinessObjects service pack, patch or upgrade is applied. This requires significant re-work, re-testing, and re-deployment procedures to be developed that could be used better elsewhere
iii. This nullifies your support contract with SAP for the use of the InfoView at least.
b) SDK Integration into a custom application – This involves adding the SDK libraries into the .NET or Java application that requires the enhanced functionality. The pro to this method is this provides a fully integrated application with connectivity Enterprise BI platform where you have full User Interface control and vendor support. The con to this choice include:
i. The main application has been burdened with many additional libraries that must be integrated and deployed as part of its build process.
ii. The main application has to be rebuilt and redeployed as each BusinessObjects service pack, patch or upgrade is applied even if there were no changes in functionality.
c) Web Application Sharing (separate SDK application called from main application) – This architecture includes the same benefits of the first two options addresses the negatives of the prior two options while also allows a Service Oriented or Web Oriented Architecture where the functionality is available for reuse across multiple applications. The other benefits to this architecture include:
i. The web server running the SDK application can be optimized for its use as a BI platform.
ii. New BI functionality can be added as new BusinessObjects features and SDK’s become available with needing a build process and the related regression testing of the main application.
2) Where do I run the SDK in my network stack?
There are actually two answers in this area : For functions like authenticating the user, gathering a report and presenting a viewer there are both the Service Level SDK’s, as well as, a Web Services SDK. While the latter does not have all the same deep functionality as the service level SDK’s, it works extremely where in network architectures where direct access to the BusinessObjects server is not available. The Enterprise and related Crystal / Webi SDK’s use libraries that require direct IP access to the services running on the BusinessObjects Server(thin port 6400). The Web Services SDK can access the services through the web service application that can made available over the normal http access layer (think port 80)
In terms of where should the application reside part of this best practice depends on your decision on the application stack above. If you are running an integrated SDK installation, then you need to install the SDK code on the same web application server as the main application. If you are going to create an shared application or just use the InfoView then it can run on the BusinessObjects server itself in the default web application server (think tomcat) or on a separate web application server (or cluster) specifically setup for web applications that can be called without logging into a single particular application.
Another input to answering this question is the understanding of where the users that will use the application are located on the network and what access security is required to access the application.
a) A publicly available URL (think reports.mycompany.com) will normally have at least one server in the DMZ(search demilitarized zone) where traffic can be monitored and direct access to the data is not required nor allowed.
b) An internal application, or one requiring VPN access (search virtual private network) can have the web servers, Business Objects application servers, and database servers all on the internal network.
3) Which SDK to Use for modifying Crystal Reports?
There are two levels of “customization” when it comes to working Crystal Reports within the SAP BusinessObjects Enterprise system.
a) When you need to add filters to your reports – This can be done using the Enterprise and Reporting SDK’s using the same features that allow you to add filters through the CMC in the report properties. This uses the normal Crystal Processing Server (i.e. previously known as the page server)
b) When you need to modify your reports on the fly – This type of modification is deeper and touches the actual report object, although usually in the memory of the BusinessObjects Server. Examples of this type of modification uses the Report Application Server or RAS SDK to perform modifications such as add / remove fields, change database connections and handle the output of the report as a record set/stream/XML (in other words anything other than a viewer or export).
Handling things like exporting the report content as a pipe (|) delimited file can now be done using the reporting SDK’s where earlier you would have to handle this through the slightly less scalable RAS SDK.
4) Which SDK to use for modifying Web Intelligence reports?
Until recently the only viable SDK was the ReBean SDK for working with Web Intelligence report modification. However….Recent updates to the Webi Extension Points has added a significant ability to customize the interfaces in both the web versions of Webi as well as the Rich client.
a) When you need to add functionality to the Interactive viewer as the primary interface:– This can primarily be done using the Webi Extension Points along with some ReBEAN methods for managing output and storage
b) When you need to add functionality using an alternative interface (i.e. simplified viewer) : the REBean SDK will give you all the power you need in 3.X. note that in 4.0 the ReBean SDK is more limited as there is a new Webi architecture underneath that will require subsequent versions before the full support through SDK’s is provided by SAP.
5) Which SDK to use for managing the Security and Reports
There are three main options for maintaining the security of the report objects
a) Self Maintained – Where the main application stores the Users and reports along with the rights associated with those reports. This of ends in developing a reporting menu that has to be maintained so that it matches or is linked with the content in the BusinessObjects server.
i. Pro: Integrated control of reports along with other application features
ii. Con: Application security and reporting security are usually different and hard to match together. This usually ends up bloating the application security module needed to support reporting
b) No-Security – The main application calls the reporting interface and users have access to all reports. Not a good long terms plan as business needs change often and things like providing use for users outside the company are not well supported
c) Integrated : by using the strength of the BusinessObjects security as an authorization handler in coordination with the application authentication the best practice can be achieved.