SharePoint in Pictures https://docs.microsoft.com/archive/blogs/sharepointpictures/feed.xml A blog dedicated to visualizing SharePoint as a development platform. Pictures will include object model, architecture, and administrative diagrams. Tue, 16 Apr 2019 05:29:59 GMT en-US hourly 1 Excel Services REST Interface https://docs.microsoft.com/archive/blogs/sharepointpictures/excel-services-rest-interface Wed, 27 Apr 2011 10:05:33 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/04/27/excel-services-rest-interface/ The figure below is a syntax diagram detailing how to construct URIs for the Excel Services REST API. For more information on using the Excel Service REST interface, take a look at the SharePoint 2010 SDK topics located here. And developer Shahar Prish details even more tips and tricks on working with the service on his blog. To explore those posts, start here.

Excel Services REST Interface

]]> SharePoint 2010 REST Service Syntax Diagram https://docs.microsoft.com/archive/blogs/sharepointpictures/sharepoint-2010-rest-service-syntax-diagram Wed, 30 Mar 2011 09:24:48 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/03/30/sharepoint-2010-rest-service-syntax-diagram/ The figure below is a syntax diagram of the structure of SharePoint Foundation REST service URIs. You can read more about the SharePoint Foundation REST service here.

Syntax diagrams are a useful way of illustrating linear data structures. Things like:

  • REST URI composition
  • API signatures
  • JSON, OData, or other XML-based data notation

You can find out more about syntax diagrams at this Wikipedia entry, see some examples using JSON here, and see some more examples in the OData specifications.

SharePoint Foundation 2010 REST URI Structure

]]> Sandboxed Solutions Object Model Hierarchy https://docs.microsoft.com/archive/blogs/sharepointpictures/sandboxed-solutions-object-model-hierarchy Wed, 09 Feb 2011 07:00:00 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/02/09/sandboxed-solutions-object-model-hierarchy/ Today’s diagram is probably best considered a work in progress.

We created the following diagram as a prototype, to see if we could use large-scale static graphics as aids for developers to visualize the SharePoint object model hierarchy and the relationships between classes within it. As an experiment, we took the subset of classes available in sandbox solutions, and, starting from a handful of the most important classes, laid out the Microsoft.SharePoint namespace hierarchy.

The results were mixed: we quickly realized that, as recursively nested as the SharePoint object model is, arbitrarily picking starting points (even important classes such as SPWeb and SPList) and presenting a single hierarchical view of the object model from there probably isn’t going to be that useful long-term for developers. Locating a specific class was difficult. Also, in order to conserve space, we omitted the names of the members used to access a class from another class; in doing so, we inadvertently stripped off an important layer of information about the relationship between the classes.

However, the diagram does provide a useful general reference for how the major classes of the SharePoint namespace are structured, so we’re presenting it here as a free download. The diagram is 34” by 44”, and available as a Visio drawing or pdf file. You can download the larger versions in a zip here on the blog. In the comments, tell us what information you’d want to help you visualize a complex object model like SharePoint, be it in a static diagram like this, or an interactive application that enabled you to select what to display.

Sandboxed Solutions Object Model Hierarchy

]]> Server Ribbon Architecture in SharePoint 2010 https://docs.microsoft.com/archive/blogs/sharepointpictures/server-ribbon-architecture-in-sharepoint-2010 Wed, 02 Feb 2011 07:00:00 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/02/02/server-ribbon-architecture-in-sharepoint-2010/ Ribbon customizations, deployed as custom actions, in SharePoint 2010 can be categorized in two ways: filtered and unfiltered. A filtered custom action is one that uses the RegistrationId and RegistrationType attributes, for example to target a specific list. An unfiltered custom action is one that does not use these attributes. Ribbon custom actions are handled in different ways depending on the type. Both filtered and unfiltered custom actions are passed into the SPElementProvider internal class. SPElementProvider retrieves the Server ribbon XML from the custom action and sends it to the internal classes SPToolbar and SPUIProcessor depending on the type of custom action.

A custom action has two pieces:

  1. A user interface piece (i.e., a button)
  2. A command handler that will interact and control the button on the page

For filtered custom actions, the UI and handlers are generated in the following way:  SPToolbar class takes the handler data, which is stored in <CommandUIHandlers> in the XML, and the user interface extension data, which is stored in <CommandUIExtension> in the XML, and passes both to the SPRibbon class.  The SPToolbar also takes any V3 custom action that applies and creates handler data, generates callback IDs, and passes the resulting handler data into the SPRibbon class.  The SPToolbar generates user interface extension data (in the form of buttons) from the V3 custom actions that apply in the Custom Commands tab. Commands are generated for these buttons with the corresponding callback IDs that were generated for the command handlers.  SPRibbon then renders script onto the page that takes the handler data (supplied by SPToolbar from the various custom actions) and wires it up to the internal CommandUIPageComponent on the client side.  The SPRibbon class also renders the user interface piece of the filtered custom actions so that they can be consumed by the RibbonBuilder on the client side when it builds the ribbon.

For unfiltered custom actions, the UI and handlers are generated in the following way:  The client side RibbonBuilder retrieves data from the commandui.ashx HTTP handler on the server.  This data is a merge of the out of the box cmdui.xml file and any unfiltered custom actions that apply on the current SPWeb.  The RibbonBuilder client object then merges this data with the filtered custom action extensions that the SPRibbon server control rendered and then builds the client Ribbon control from this merged data.  The client object CommandUIPageComponent then retrieves unfiltered handler data from commandui.ashx and merges it with the filtered handler data that was rendered by the SPRibbon server control on the page.  Commandui.ashx gets its data by querying the SPUIProcessor which produces its data by merging out of the box cmdui.xml data with the unfiltered custom action handler and user interface extension data.

The end result is that the page has a client Ribbon control that is built from a merge of cmdui.xml, unfiltered and filtered user interface extension data, and a CommandUIPageComponent that has handlers that are a merge of the unfiltered command handlers from commandui.ashx and the filtered command handlers that were rendered onto the page by the server side SPRibbon class.

Server Ribbon Architecture in SharePoint 2010

]]> Excel Services Architecture In SharePoint Server 2010 https://docs.microsoft.com/archive/blogs/sharepointpictures/excel-services-architecture-in-sharepoint-server-2010 Wed, 26 Jan 2011 07:00:00 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/01/26/excel-services-architecture-in-sharepoint-server-2010/ Excel Services is part of Microsoft SharePoint Server 2010. Excel Services is built on ASP.NET and SharePoint Foundation technologies. Following are the core components in Excel Services:

  • · Excel Web Access
  • · Excel Web Services
  • · User-defined functions (UDFs)
  • · ECMAScript (JavaScript, JScript)
  • · Representational State Transfer (REST) service
  • · Excel Calculation Services

The Excel Web Access, Excel Web Services, UDFs, ECMAScript, the REST service, and Excel Calculation Services components can be divided into two major groups: the components on a front-end server (also known as the "Web front end") and the component on a back-end application server.

An important aspect of Excel Services is that solution developers can use its power programmatically from their applications. These applications can be line-of-business (LOB) products or custom enterprise solutions that an organization develops internally.

Following are examples of these applications:

  • · Multitiered applications, with the presentation layer implemented as a Web application (for example, an ASP.NET application) that calls Excel Web Services.
  • · Applications within Microsoft SharePoint Server 2010, or integrated with LOB products.

There are five types of development that you can do by using Excel Services:

  • · Develop solutions by using Excel Web Services
  • · Extend the Microsoft Excel function library in Excel Services by using user-defined functions (UDFs)
  • · Customize the Excel Web Access Web Part
  • · Develop solutions by using ECMAScript (JavaScript, JScript)
  • · Use the REST API to perform operations against Excel workbooks

For more info, see https://msdn.microsoft.com/en-us/library/ms517343.aspx

Excel Services Architecture In SharePoint Server 2010

]]> Understanding Business Connectivity Services https://docs.microsoft.com/archive/blogs/sharepointpictures/understanding-business-connectivity-services Wed, 19 Jan 2011 07:00:00 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/01/19/understanding-business-connectivity-services/ Microsoft Business Connectivity Services (BCS) enables users to read and write data from external systems—through Web services, databases, and Microsoft .NET Framework assemblies—from within Microsoft SharePoint 2010 and Microsoft Office 2010 applications. Both SharePoint 2010 and Office 2010 applications have product features that can use external data directly, both online and offline. Developers can gain access to a rich set of features and rapidly build solutions by using familiar tools such as Microsoft Visual Studio 2010 and Microsoft SharePoint Designer 2010.

To understand the important concepts and architecture of Business Connectivity Services, see the following topics:

The diagram below is a high-level architecture diagram of Microsoft Business Connectivity Services (BCS).

Business Connectivity Services High Level Architecture

]]> What Is Included in Business Connectivity Services? https://docs.microsoft.com/archive/blogs/sharepointpictures/what-is-included-in-business-connectivity-services Wed, 12 Jan 2011 07:00:00 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/01/12/what-is-included-in-business-connectivity-services/ Microsoft Business Connectivity Services (BCS) is included in Microsoft SharePoint Foundation 2010, Microsoft SharePoint Server 2010, and Microsoft Office 2010 applications. However, the feature set and the capabilities differ in each application.

The diagram below shows the differences in the feature sets of Business Connectivity Services, SharePoint Server 2010, and Office 2010. For more information about the Business Connectivity Services features in each application, see the following topics:

What Is Included in Business Connectivity Services?

]]> SharePoint Business Connectivity Services Dataflow Model https://docs.microsoft.com/archive/blogs/sharepointpictures/sharepoint-business-connectivity-services-dataflow-model Thu, 06 Jan 2011 08:34:54 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2011/01/06/sharepoint-business-connectivity-services-dataflow-model/ Microsoft Business Connectivity Services (BCS) enables users to read and write data from external systems—through Web services, databases, and Microsoft .NET Framework assemblies—from within Microsoft SharePoint 2010 and Microsoft Office 2010 applications. Both SharePoint 2010 and Office 2010 applications have product features that can use external data directly, both online and offline. Developers can gain access to a rich set of features and rapidly build solutions by using familiar tools such as Microsoft Visual Studio 2010 and Microsoft SharePoint Designer 2010.

This diagram shows the relationship between all of the components that make up BCS or that interact with the services BCS provides.

SharePoint Business Connectivity Services Dataflow Model

]]> Client Object Model Request Batching in SharePoint 2010 https://docs.microsoft.com/archive/blogs/sharepointpictures/client-object-model-request-batching-in-sharepoint-2010 Tue, 21 Dec 2010 07:00:00 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2010/12/21/client-object-model-request-batching-in-sharepoint-2010/ The request batching process helps to improve performance and reduce network traffic in two ways. First, fewer Web service calls occur between the client and the SharePoint server, which reduces the "chattiness" of the client-server interface. For example, you can perform two list queries in a single request. Second, as a set of operations occur on the server in a single request, the data being acted on doesn't need to be moved between the client and the server for the intermediate operations—only the list of operations and the final result set are passed between the client and the server.

Request batching requires a different mindset when you create queries from client-side code. First, be aware that you do not have access to any results until you call ExecuteQueryAsync (or ExecuteQuery) and receive the call back with the results. If you need to implement conditional logic in the client-side code that can't be expressed in the command list that you send to the server, you will need to execute multiple queries. Second, you should aim to group your operations to minimize the number of service calls. This means you may need to think about how you sequence your logic in order to take full advantage of request batching.

For more information about the client object model, see patterns & practices: Using the Client Object Model, patterns & practices: Client Application Models in SharePoint 2010, and SharePoint SDK: Using the Client APIs.

Client Object Model Request Batching in SharePoint 2010

]]> Business Connectivity Services High-Level Architecture in SharePoint https://docs.microsoft.com/archive/blogs/sharepointpictures/business-connectivity-services-high-level-architecture-in-sharepoint Tue, 14 Dec 2010 09:47:26 GMT https://blogs.msdn.microsoft.com/sharepointpictures/2010/12/14/business-connectivity-services-high-level-architecture-in-sharepoint/ Business Connectivity Services (BCS) for SharePoint 2010 builds on the technology of the Business Data Catalog first introduced in SharePoint 2007.  It provides the ability to connect SharePoint to external data sources of all kinds, including but not limited to, other database systems, Customer Relationship Management (CRM) systems, ERP systems. BCS provides a developer with a means of pre-defining all the information needed by an application to connect with and manipulate this external data through External Content Types (ECT). The most important aspect of ECTs is that once the developer creates it, the ECT will be available for use by SharePoint users to connect and use the external systems without knowing any code.

The following diagram displays a high-level overview of how the components of BCS all work together.

Business Connectivity Services provides mechanisms to enable experienced users, developers, and business unit IT professionals to do the following much more easily:

  • Reveal external data from enterprise applications and Web 2.0 services in Microsoft SharePoint Foundation 2010, SharePoint Server 2010, and in rich client Office applications.
  • Provide Office Type behaviors (such as contacts, tasks, appointments) and capabilities to external data and services.
  • Provide complete interaction with the data including write-back capabilities from Office applications and SharePoint Server to the underlying external system data and business objects.
  • Enable offline use of external data and processes.
  • Bridge the unstructured world of documents and people and the appropriate structured data that is locked in external systems.

Business Connectivity Services is included in Microsoft SharePoint Foundation 2010, SharePoint Server, and Office 2010. However, the feature set and the capabilities differ in each, as shown in the following figure.

For more information on BCS, see Business Connectivity Services Overview, Understanding Business Connectivity Services, and Business Connectivity Services Fundamentals.

SharePoint Business Connectivity Services High Level Architecture

]]>