A Beginner’s Guide to BI Services
There are plenty of posts out there explaining BI Services, but it’s difficult to find a true beginner’s guide. So the below is for those that are new to the world of BusinessObjects BI Services, or just want to get a better understanding of what's going on behind the scenes.
When working with BI Services I find it immensely helpful to be able to picture the flow of data. Especially when something goes wrong (if nothing goes wrong, then something’s not right). So this is what the flow of data looks like, flowing from the bottom up.
Database
The data starts life in a database. This could be SQL, Oracle, Microsoft Analysis Services, Access, Excel, etc. Things are slightly different if you're using SAP/BW/BEx.
Connector
For most data sources, some sort of connection is used to define how to connect to the data source, for example an ODBC connection. If you’re using a universe on BEx then consider BEx the connector.
Connection
In BusinessObjects, a connection is created that the universe will use to connect to the database connection. This is nothing more than a pointer to the data source connector. If you're using a BICS connection, then this connection points to a BEx query.
Universe
A Universe is created, pointing to the BusinessObjects connection. This is the first ‘smart’ layer, in that you can define dimensions and measures in a way that suits end users, not necessarily the way that suited the database creator. This is called ‘abstraction’. If you're using a BICS connection, then you're effectively jumping this step (the BEx query does the job of abstracting).
Web Intelligence
A Webi report is created, based on one or more universes (or BICS connections). And here’s an important thing to note: once that Webi report is scheduled (i.e. has at least one ‘scheduled instance’) then it becomes a data source. The great part is that when you create a Webi report for use with a BI Service, you are actually designing a cube (a multi-dimensional data source) based on the underlying data, without having to know anything about databases. The cube will typically be much smaller than the underlying data source because it will contain only the data required for your dashboard. When the report runs and a new scheduled instance is created, this is Webi creating a new cube with up-to-date data.
BI Service
Finally we get to the BI Service. A single BI Service can contain several ‘methods’. Don’t worry about the programmer-sounding language, a method is simply a pointer to a Webi block. So if I have five Webi blocks that I want to get into my dashboard, then I would create one BI Service with five methods. The method also defines things like which filters are available for the block.
Xcelsius Connection
In Xcelsius, a “Query as a Web Service” connection is defined that points to the BI Service and method. (Yes it’s confusing that you use a QaaWS connection when you’re not using QaaWS, but that’s the way it is.) This connection pulls data in from the Webi block and puts it into the Xcelsius worksheet. If I had five Webi blocks, and had used one BI Service and five methods to point to these blocks, then I would have five connections in Xcelsius. All five would use the same BI Service but each would connect to a different method within the BI Service. These connections is where I define when the connection fires, what filters to apply and whether I use the ‘drill’ or ‘getReportBlock’ version of the method. I won’t cover the difference here, but if you don’t know which one you want, you want the getReportBlock version.
Xcelsius Model
Then of course the final presentation layer is the dashboard. Where the beautiful charts connect to the data in the worksheet.
And that’s it! I hope this has helped you have a better understanding of what’s going on behind the scenes, which should speed up development and reduce time spent troubleshooting. If I’ve missed anything out, the comments await you below…
- See more at: http://blog.davidg.com.au/2012/08/a-beginners-guide-to-bi-services.html#sthash.8eC5qEKF.dpufWhen working with BI Services I find it immensely helpful to be able to picture the flow of data. Especially when something goes wrong (if nothing goes wrong, then something’s not right). So this is what the flow of data looks like, flowing from the bottom up.
Database
The data starts life in a database. This could be SQL, Oracle, Microsoft Analysis Services, Access, Excel, etc. Things are slightly different if you're using SAP/BW/BEx.
Connector
For most data sources, some sort of connection is used to define how to connect to the data source, for example an ODBC connection. If you’re using a universe on BEx then consider BEx the connector.
Connection
In BusinessObjects, a connection is created that the universe will use to connect to the database connection. This is nothing more than a pointer to the data source connector. If you're using a BICS connection, then this connection points to a BEx query.
Universe
A Universe is created, pointing to the BusinessObjects connection. This is the first ‘smart’ layer, in that you can define dimensions and measures in a way that suits end users, not necessarily the way that suited the database creator. This is called ‘abstraction’. If you're using a BICS connection, then you're effectively jumping this step (the BEx query does the job of abstracting).
Web Intelligence
A Webi report is created, based on one or more universes (or BICS connections). And here’s an important thing to note: once that Webi report is scheduled (i.e. has at least one ‘scheduled instance’) then it becomes a data source. The great part is that when you create a Webi report for use with a BI Service, you are actually designing a cube (a multi-dimensional data source) based on the underlying data, without having to know anything about databases. The cube will typically be much smaller than the underlying data source because it will contain only the data required for your dashboard. When the report runs and a new scheduled instance is created, this is Webi creating a new cube with up-to-date data.
BI Service
Finally we get to the BI Service. A single BI Service can contain several ‘methods’. Don’t worry about the programmer-sounding language, a method is simply a pointer to a Webi block. So if I have five Webi blocks that I want to get into my dashboard, then I would create one BI Service with five methods. The method also defines things like which filters are available for the block.
Xcelsius Connection
In Xcelsius, a “Query as a Web Service” connection is defined that points to the BI Service and method. (Yes it’s confusing that you use a QaaWS connection when you’re not using QaaWS, but that’s the way it is.) This connection pulls data in from the Webi block and puts it into the Xcelsius worksheet. If I had five Webi blocks, and had used one BI Service and five methods to point to these blocks, then I would have five connections in Xcelsius. All five would use the same BI Service but each would connect to a different method within the BI Service. These connections is where I define when the connection fires, what filters to apply and whether I use the ‘drill’ or ‘getReportBlock’ version of the method. I won’t cover the difference here, but if you don’t know which one you want, you want the getReportBlock version.
Xcelsius Model
Then of course the final presentation layer is the dashboard. Where the beautiful charts connect to the data in the worksheet.
And that’s it! I hope this has helped you have a better understanding of what’s going on behind the scenes, which should speed up development and reduce time spent troubleshooting. If I’ve missed anything out, the comments await you below…
No comments:
Post a Comment