The Business Objects architecture can be complex or somewhat simple. Here we will have a general , high level overview of some possible setups. Note that this information is intended for BusinessObjects 4.0. SAP consolidated and rearchitected many of the back-end data layers from XI v3 to this version so overall structure has changed. It’s the first major change since the SAP integration.
At a high level the BOBJ architecture can look very similar to a standard business intelligence stack. As an enterprise class system, BusinessObjects normally works best when driven against a standard data warehouse infrastructure. The following chart shows a standard layout.
Within the main BOBJ enterprise back end are several different engines and services running to provide data. Web services would be used to provide data to the web server. If WebI or Infoview is used, then a web server would be the intermediary. The BI portion drives the information delivery to the various Business Objects components. Information for BI Dashboards or Crystal Reports would be sent to those products desktop versions if not on the web. One of the biggest improvements in version 4.0 was the consolidation of metadata, or information about the reports, dashboards, and other objects. This means that the front-end products can use a common setup structure and their doesn’t need to be redundant data entered on the back end.
Of course, this is a simplified view. A more complex mix of data sources and front end products or deployments can add significantly to the scope. What is important to consider is the overall sizing of the servers and support structures. SAP offers several resources to help with the server sizing depending on RAM, number of users, and other factors. These are OK for a first pass but in some cases a more robust tool might be needed.
Copyright 2011-2017 BusinessIntelligenceBase.com