SharePoint in Pictures

A blog dedicated to visualizing SharePoint as a development platform. Pictures will include object model, architecture, and administrative diagrams.

Posts
  • SharePoint in Pictures

    Excel Services REST Interface

    • 1 Comments

    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 in Pictures

    SharePoint 2010 REST Service Syntax Diagram

    • 0 Comments

    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

  • SharePoint in Pictures

    Sandboxed Solutions Object Model Hierarchy

    • 1 Comments

    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

  • SharePoint in Pictures

    Server Ribbon Architecture in SharePoint 2010

    • 1 Comments

    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

  • SharePoint in Pictures

    Excel Services Architecture In SharePoint Server 2010

    • 0 Comments

    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 http://msdn.microsoft.com/en-us/library/ms517343.aspx

    Excel Services Architecture In SharePoint Server 2010

  • SharePoint in Pictures

    Understanding Business Connectivity Services

    • 0 Comments

    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

  • SharePoint in Pictures

    What Is Included in Business Connectivity Services?

    • 0 Comments

    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 in Pictures

    SharePoint Business Connectivity Services Dataflow Model

    • 1 Comments

    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

  • SharePoint in Pictures

    Client Object Model Request Batching in SharePoint 2010

    • 0 Comments

    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

  • SharePoint in Pictures

    Business Connectivity Services High-Level Architecture in SharePoint

    • 0 Comments

    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

  • SharePoint in Pictures

    Web Part Development Options in SharePoint 2010

    • 1 Comments

    This diagram demonstrates the project templates and project item templates that you can use when developing Web Parts in Visual Studio. While these templates have the same end result (a cool Web Part running SharePoint), the development experience can vary between working with code or using a designer to build the UI. For more information, see the following MSDN topics.

    Web Part Development Options in SharePoint 2010

  • SharePoint in Pictures

    Solution Packages and the SharePoint Tools Continuum

    • 0 Comments

    One major advantage of the SharePoint 2010 development platform is that it provides the ability to save sites as solution packages. A solution package is a deployable, reusable package stored in a .cab file with a .wsp extension. You can create a solution package in the browser, SharePoint Designer 2010, and Microsoft Visual Studio 2010. In the browser and SharePoint Designer 2010 user interfaces, solution packages are also called templates. This flexibility allows you to create and design site structures in a browser and/or in SharePoint Designer and then import these customizations into Visual Studio 2010 for further development.

    When the customizations are complete, you can deploy your solution package to SharePoint and use it there. After modifying the existing site structure with a browser, you can start the cycle all over again by saving the updated site as a solution package.

    This tools continuum also enables you to use other tools. For example, you can design a workflow process in Microsoft Visio 2010 and then import it to SharePoint Designer 2010 and from there to Visual Studio 2010. For instructions on how to do this, see Create, import, and export SharePoint workflows in Visio.

    For more information on creating solution packages in SharePoint Designer 2010, see Save a SharePoint Site as a Template. For more information on creating solution packages in Visual Studio 2010, see Creating SharePoint Solution Packages.

    SharePoint 2010 Tools Continuum

  • SharePoint in Pictures

    Client Object Models Operation in SharePoint Online Solutions

    • 0 Comments

    The following diagram shows the call and response flow for the client object models in SharePoint Online.

    SharePoint Online includes three client object models. The ECMAScript, .NET Framework managed, and Silverlight client object models each include objects that correspond to major objects at the site-collection level or lower in the SharePoint hierarchy. The object models provide a consistent and easy-to-use, object-oriented system for interoperating with SharePoint data from a remote client or server.

    Because code written against the client object models runs remotely on the client, it is not subject to the same restrictions as sandboxed solutions, and can, for example, access external data sources.

    The client object models are provided through proxy .js files and managed .dll files, which can be referenced in custom applications just as other object models. All operations are inherently asynchronous, and commands are serialized into XML and sent to the server in a single HTTP request. For every command, a corresponding server object model call is made, and the server returns a response to the client in compacted JavaScript Object Notation (JSON) format, which the proxy parses and associates with appropriate objects.

    For more information on developing solutions for SharePoint Online, see SharePoint Online: An Overview for Developers, from which this diagram is excerpted.

  • SharePoint in Pictures

    SharePoint Online Sandboxed Solution Development Process

    • 1 Comments

    The following diagram shows the basic steps in the process of creating, deploying, and activating a sandboxed solution on SharePoint Online:

    1. Develop and test the solution.

    To create or customize SharePoint Online solutions, you must develop the solution on a local computer where SharePoint Server 2010 or SharePoint Foundation 2010 is installed. This includes debugging the solution; you will not be able to debug the solution directly on SharePoint Online.

    After you set up your development environment, you can use Visual Studio 2010 to create your sandboxed solutions. In addition, Visual Studio 2010 can open and edit solution package (.wsp) files that are created in SharePoint Designer 2010, enabling designers and developers to tightly collaborate on solutions through a common framework.

    2. Deploy and activate the solution.

    After you create and debug your sandboxed solutions on your local computer, you must hand that solution off to your SharePoint Online administrator, if you do not have SharePoint Online administration permissions. The SharePoint Online administrator uploads the solution package (.wsp) file to the Solution Gallery for activation.

    To make the solution available to users, you must activate it.

    3. Monitor the activitated solution.

    Activated solutions are monitored in terms of the resources they consume. Solution performance can be monitored by using multiple types of measures including CPU execution time, memory consumption, and database query time.

    For more information on developing solutions for SharePoint Online, see SharePoint Online: An Overview for Developers, from which this diagram is excerpted.

    SharePoint Online Sandboxed Solution Development Process

  • SharePoint in Pictures

    SharePoint Online Development Options

    • 1 Comments

    The following diagram details the development options available in SharePoint Online (Beta): use the server object model available to sandboxes solutions, or employ the client object model and client-side code to access additional data that is available through the SharePoint web services, or data from external sources.

    In SharePoint Online, subscribers own and administer site collections, instead of entire farm installations; therefore, the development approach to SharePoint Online is necessarily scoped to the site collection. Because of this, sandboxed solutions and the client object models form the foundation of developing for SharePoint Online.

    A specialized type of the SharePoint solutions framework, sandboxed solutions provide a framework for developers to create, and for SharePoint Online administrators to upload and activate, custom code solutions to SharePoint Online. Sandboxed solutions run in an environment that has access to a core subset of the server object model. The sandboxed solutions framework gives developers access to the major objects at and below the site collection level.

    The client object model provides three parallel and comparable representations of the core objects in the server-side SharePoint object model: a .NET Framework managed model, a Silverlight model, and an ECMAScript (JavaScript, JScript) model. This client object models provide remote access to SharePoint data and functionality.

    In addition, you can use the client-side code to access the web services that SharePoint Online makes available and external data sources. Because of this, client-side code is a useful option if you need to access either objects beyond those included in sandboxed solutions, but available through a SharePoint Online web service, or external data.

    For more information on developing solutions for SharePoint Online, see SharePoint Online: An Overview for Developers, from which this diagram is excerpted.

    SharePoint Online Development Options

  • SharePoint in Pictures

    User Profile Subsystem in SharePoint Server 2010

    • 0 Comments

    Today’s post comes to us from Spencer Harbar, a SharePoint MVP,  at http://www.harbar.net. He graciously offered to let us use his User Profiles graphic and accompanying text. You can find his guides on User Profiles at http://www.harbar.net/articles/sp2010ups.aspx and http://www.harbar.net/articles/sp2010ups2.aspx. Thank you, Spencer!

    This diagram shows the high level architecture and the various components that make up the User Profile subsystem in SharePoint Server 2010.

    User Profile Subsystem in SharePoint Server 2010

    The key components are briefly described below.

    User Profile Service Application (UPA)

    A logical component which encompasses:

    · An IIS Application which sits in the SharePoint Web Services IIS Web Site. The IIS Web Site is on every machine in the farm. When we start the User Profile Service machine instance later, the IIS Application will be created on that machine. It will be named with a GUID and hosts two of WCF services. This is known as a Service Application Endpoint.

    · Pages for managing the Service Application are hosted in Central Administration and are called using a GUID in the query string. The WCFs don’t actually do any work themselves but provide an interface to calling clients and calls other elements of the system.

    There can be more than one instance of the User Profile Service Application, but there is a one to one mapping between a Service Application and the User Profile Synchronization Service Service Machine Instance.

    User Profile Service Application Proxy (UPA Proxy)

    A Service Connection (aka Proxy). This lives within the SharePoint Foundation Web Application Service and allows Service Consumers (e.g. Web Applications) to call the Service Application.

    User Profile Service Instance (UP)

    A SharePoint Service Instance. This is not a Windows Service, but .NET assemblies that are primarily responsible for surfacing User Profile data to consuming Web Applications. There are no configuration options. This should run on the machine in the farm you wish to use to host the User Profiles “Role”. When it’s running that machine is known as the Service Machine Instance.

    User Profile Synchronization Service Instance (UPS)

    A SharePoint Service Instance. This is a wrapper responsible for the provisioning of the Forefront Identity Manager (FIM) components. You select a User Profile Service Application to associate with, and need to specify the credentials of the Farm Account (under which the FIM Services will run). This should run on the machine in the farm you wish to use to host the User Profiles “Role”. When it’s running that machine is known as the Service Machine Instance. There can only be one UPS Service Instance per User Profile Service Application.

    Forefront Identity Manager (FIM)

    A bundled version of FIM that includes two Windows Services, associated configuration and data, along with a rich client Synchronization Manager tool. FIM is responsible for synchronizing user profile properties with attributes or data from external directory services such as Active Directory. It is not supported to use the FIM client but this can be useful for viewing progress and identifying errors. The two FIM services are automatically configured by the User Profile Synchronization Service Instance and the User Profile Service Application.

    Related Service Applications

    We can configure the UPA to use Term Sets provided by the Managed Metadata Service Application (MMS). In order to take advantage of the Social Search capabilities in SharePoint Server 2010 we also need the Enterprise Search Service Application.

    Profile Database

    The Profile database contains the profile properties and other related data such as Audiences. It also stores Activity Feed data for users.

    Social Database

    The Social database contains social data such as Tags, Keywords, Comments, Bookmarks and Ratings.

    Sync Database

    The Sync database is a staging area for data synchronized with external directory services or business data connections. In FIM terminology this is known as the “metaverse”.
  • SharePoint in Pictures

    Services Running in a Multi-Server SharePoint Farm

    • 1 Comments

    This graphic shows the services, CFSIs (configured farm-scoped instantiations), and service instances on a hypothetical 10-server farm. Note the following things about this example:

    • The translucent rectangles represent services. These services are modeled in the SharePoint Foundation object model with SP*Service classes.

    • The darker translucent rectangles represent CFSIs ("service applications") that are modeled in the SharePoint Foundation object model with SP*ServiceApplication classes.

    • The smaller, solid rectangles represent instances of services that are modeled in the SharePoint Foundation object model with SP*ServiceInstance classes.

    • The Diagnostics Service has instances running on all servers (except the dedicated database server), but the object model has no SPDiagnosticServiceInstance class (because there is no need for one in SharePoint Foundation), so there are no sold rectangles for these instances.

    • The Administration, Timer, Workflow Timer, User Code, Diagnostics, and Usage services run on all servers (as they must), except the dedicated database server.

    • Only the five front-end Web servers run the Web Application Service.

    • There is a dedicated search server.

    • There are two dedicated Business Data Connectivity (BDC) servers.

    • The BDC service has two CFSIs (service applications). One has an instance on each of the dedicated BDC servers, but the other is running on just one of them. The front-end Web servers must have separate service application proxies targeting these two different CFSIs.

    • A fourth, multipurpose application server runs Central Administration, the e-mail services, the subscription service, the security token service, and the application discovery and load balancer service. Since the Central Administration Web service hosts a Central Administration Web application, this server would also have service application proxies running on it if it needed to consume any of the services that implement the Service Application Framework. This is an exception to the usual principle that consumer proxies in the framework run on front-end Web servers.

    • When the SharePoint Foundation databases are on a dedicated server, as in this case, SharePoint Foundation need not be installed on that server. The Database Service is just a wrapper for the SQL Server service running on the database server. Hence, SharePoint Foundation code is not running on the dedicated database server. The service and its instance appears in the figure because it is represented in the object model with the SPDatabaseService and SPDatabaseServiceInstance classes.

    For more information see Background: Service Entities in Microsoft SharePoint Foundation

    Services Running in a Multi-Server SharePoint Farm

  • SharePoint in Pictures

    PerformancePoint Services Extension Points

    • 2 Comments

    This diagram shows where supported extensions fit into the PerformancePoint Services architecture. The front-end web server hosts custom editors, web services, and other web applications, and the back-end application server hosts custom renderers, providers, and scorecard transforms. For more information, see Development Scenarios with PerformancePoint Services, PerformancePoint Services Architecture, Getting Started with PerformancePoint Services, and Fundamentals of PerformancePoint Services.

    PerformancePoint Services Extension Points in Microsoft SharePoint Server 2010

  • SharePoint in Pictures

    PerformancePoint Services Architecture in SharePoint Server 2010

    • 0 Comments

    This diagram shows the high-level architecture of PerformancePoint Services in Microsoft SharePoint Server 2010 Enterprise. Its multi-tiered architecture includes components on the client tier, the front-end Web server, and the back-end application server. For more information, see PerformancePoint Services Architecture, Getting Started with PerformancePoint Services, and Fundamentals of PerformancePoint Services.

    PerformancePoint Architecture in Microsoft SharePoint Server 2010

  • SharePoint in Pictures

    Dual Worker Process Model for Sandboxed Solutions

    • 2 Comments

    Note the following about this graphic:

    • The User Code Service (SPUCHostService.exe) creates the sandbox worker processes and assigns each HTTP request to a sandboxed solution to one of these processes.
    • A sandbox worker process (SPUCWorkerProcess.exe) is the process in which custom code that is a part of a sandboxed solution executes. 
    • A full trust proxy process (SPUCWorkerProcessProxy.exe) hosts the portion of the SharePoint object model that sandboxed solutions can access and enables second stage calls to the rest of the object model.

    For more information, see Sandboxed Solutions Architecture, Sandboxed Solutions​, Sandboxed Solutions Execution Model, and Chapter 4: Sandboxed Solutions.

    Dual Worker Process Model for SharePoint 2010 Sandboxed Solutions

  • SharePoint in Pictures

    SharePoint Foundation 2010 Events Pipeline

    • 1 Comments

    The illustration depicts the flow of actions associated with synchronous and asynchronous before and after event handlers in SharePoint Foundation 2010. Handlers for synchronous events (all Before events are synchronous) are called in their sequential order in the main thread–-that is, in the thread in which the user action occurred. Their sequence order is determined by the value of the sequence number property (SPEventReceiverDefinition.SequenceNumber) for each event. This applies to both Before and After synchronous events.

    On the other hand, event handlers for asynchronous events (After events can be asynchronous or synchronous using the SPEventReceiverDefinition.Synchronization property) behave differently. First, they execute in a different thread from the one in which the triggering action occurred. Furthermore, successive asynchronous event handlers execute in successive threads.

    Second, although asynchronous handlers are initiated in sequential order (again, based on the SequenceNumber property), there is no guarantee that they will execute or be completed in that same order. Note, too, that handlers for an asynchronous After event can start at any time after its triggering action occurs.

    For more information about events, see the following resources in the SharePoint 2010 SDK:

    SharePoint Foundation 2010 Events Pipeline

  • SharePoint in Pictures

    SharePoint 2010 Development Platform Stack

    • 5 Comments

    This diagram shows the platforms on which SharePoint Server and SharePoint Foundation are built.

    • The boxes with a blue fill represent independent platforms and each depends on the platforms below it.
    • The empty boxes inside the larger boxes are selected important subparts or features of the platform.
    • The thin downward arrows indicate selected dependency relations. Not every sub-platform or dependency relation is shown.
    • The thicker, green, sideways arrows indicate that one entity accesses the entity to which the arrow points. Again, only some selected access relationships are shown.

    For more information, see Conceptual Overview of SharePoint Foundation and its child nodes.​

    SharePoint 2010 Development Platform Stack

  • SharePoint in Pictures

    Welcome to SharePoint in Pictures

    • 1 Comments

    Welcome to the SharePoint in Pictures blog! On this blog, you will find diagrams that visualize SharePoint as a development platform. These diagrams will include various object models, application stacks, network topologies, user interface extensions, and highly customized SharePoint sites. Each diagram will have a small description along with links to more in-depth information on Microsoft Developer Center (MSDN). A new diagram will be posted on a weekly basis.

    Your feedback is very important! Feedback helps with the creation of future diagrams and helps improve the SharePoint Software Development Kit (SDK) and the SharePoint content on MSDN. One of the goals with SharePoint in Pictures is to make the SharePoint developer content more visual rather than text-based as it is now. A few questions to think about while viewing these diagrams:

    • Were the diagrams helpful?
    • How can they be improved?
    • Are there areas that were missed in these diagrams? 

    If you have an idea for a diagram, please provide the ideas using the feedback form.

    I hope you enjoy SharePoint in Pictures, and I look forward to sharing ideas and getting your feedback. Enjoy!

Page 1 of 1 (23 items)