A Peek Inside: The client architecture

Well, I have a fun one today. We get asked all of the time about how the PowerPivot add-in works. Particularly how it relates to the SSAS components that BI Pros are used to, e.g. making connections to SSAS. As I am getting ready to write an architecture overview blog posting for the PowerPivot team blog, I decided to take the client architecture out for a spin and attempt a more detailed drilldown here . . .

Here is a block diagram of the PowerPivot client component architecture:

As this is a geek discussion, I will spend a bit more time on how some of these components are implemented. As most of these components (with the exception of the ‘transports’ in the msolap OLEDB provider) are likely already known to you geek’ie SSAS pros, I will just make a few observations:

• Notice how the addin interfaces with the VertiPaq engine – it uses AMO and ADOMD.NET. This is one of the most powerful aspects of PowerPivot. While we expose a tabular interface to end users, the underlying model is multidimensional. It is based on the UDM and well-known and established SSAS interfaces. We use AMO and ADOMD.NET (and their resulting languages, MDX and XMLA) as the components to implement the multidimensional objects.
• As the addin is written exclusively in C#, we use the managed libraries to interface with the VertiPaq engine. Excel itself is still native code, so when Excel pivot tables want to ‘speak’ to PowerPivot, they use the msolap OLEDB provider.
• Inside the msolap OLEDB provider are four transports. A transport is a module that provides the physical channel used for sending messages back and forth to the server. In the case of the client addin, there are three possible transports:
  1. TCP/IP – this is used for normal client-server connections. In this case, the SERVER=<name> is used in the connection string.
  2. HTTP – this is used for http access, e.g. using the data pump in SSAS, or making a connection to the PowerPivot for SharePoint PWS component (PowerPivot Web Service) – more on the PWS in the full architecture blog posting coming next week. For the data pump, the connection string is SERVER=http://server/virtual_directory/msmdpump.dll. For the PWS, the connection string is: SERVER=http://sharepoint_server/webapp/site/subsite/doclib/file.xlsx
  3. INPROC – this is the transport that is being used here to make a connection to the in-memory VertiPaq engine. The key that indicates that this is an in-proc connection is the SERVER=$EMBEDDED$ or DATA SOURCE=$EMBEDDED$ value.
  4. There is a fourth transport, called the CHANNEL transport, but it is used on the SharePoint farm to route requests directly to the PowerPivot System Service (PSS) – so I will put off a detailed discussion of it until we talk about the midtier architecture (likely next week).
• AMO and ADOMD.NET have a similar transport mechanism inside the http client, but it is much more straightforward as it is written in managed code and has a less complexity as the msolap provider does.
• Notice that the entire component stack is in-proc within the Excel process – Excel, the msolap provider, AMO, ADOMD.NET, and even the VertiPaq engine are all together. Can you spell 64-bit?
• Not to point out the obvious, but a downside to this approach is that we have no process little separation between the components, i.e. a VertiPaq crash is also an Excel crash and the reverse. We are all one happy or unhappy family (together).
• As a dev team – and a supportability champion – the beauty of this architecture is that we were able to get a ton of reuse from the existing SSAS infrastructure (for example, the client libraries, and the in-proc code path is similar to SSAS local cubes).
• The transport mechanism makes it transparent to the pivot table how the actual messages flow – everything is driven by the format of the SERVER= (or DATA SOURCE=) parameter on the connection string. So, in a way, the user does control the message flow – because he or she is the source for where the SERVER= parameter points to.

So, I hope you enjoyed the slight detour in to the client ‘realm’, I hope to get back to the midtier and the server soon but then it was fun. So maybe I will stay here for a while. You never know . . .