Sharepoin learning notes-architecture series-Four Execution models of SharePoint 2

In the previous article, we saw two execution models: the field solution and the sandbox solution. The midfield solution includes two modes: full trust and bin/CAS, here, let's continue to look at the last execution model, that is, the hybrid model (or the hybrid model ).

3. hybrid mode (hybrid approaches))

The so-called hybrid mode means that although the solution runs in the sandbox mode, it can access the full trust mode through various mechanisms.CodeIn other words, the sandbox mode is combined with the full trust mode. Of course, we can regard this mode as a combination of two loosely coupled methods, because the sandbox mode is deployed in the solution gallery solution library of the site collection ), the solution with full trust is deployed to the server farm, and their development can be isolated, not at the same time, in addition, components in full trust mode can be used by one or more sandbox mode components. Generally, a solution with full trust needs to be centrally developed and controlled by the IT center team and provided to the sandbox solution.

Sandbox mode supports three types of fully trusted components:

• Full Trust proxies. Compile a custom class inherited from the spproxyoperation abstract class to implement the Code function in full trust mode.ProgramDeploy the set to GAC (Global Assembly Cache). In this way, the fully trusted proxy function is exposed to the sandbox and called using the sandbox code.
  
• External content types (external content types). You can use external content types to obtain external data from lob applications (line-of-business applications) and other external data sources connected through BCS. The external content type must be deployed in full trust mode. In any case, you can create an external list (external lists) in the sandbox environment to obtain data that cannot be extracted through the sandbox.
  
• Custom workflow activity (actim workflow activities ). you can create custom workflows that are encoded and deploy them to GAC (Global Assembly Cache) in full trust mode ), then you can call the workflow activity in the sandbox.
  

Next, let's take a look at the implementation details of the above three types.

1. Full Trust proxies ).

Hybrid execution using a full-trust proxy

 

When a fully trusted proxy is used in the sandbox, the code access security (CAS) policy allows the sandbox code to access the Assembly fully trusted proxy, you can register a proxy assembly with farm by programming in feature explorer, or you can register a proxy assembly using the window powershell tool.

Your sandbox code must use the spproxyoperationsargs class to construct parameters that need to be passed to a fully trusted proxy. When you call sputility. when the executeregisteredproxyoperation method is used, the sandbox Worker Process Activates the fully trusted proxy and passes the relevant parameters in it. Then, the Code fully trusted proxy runs in the fully trusted mode, after the processing task is completed, the proxy is fully trusted to return relevant parameters (if any) to the sandbox solution, and the sandbox solution continues to complete other tasks.

Note that the context (spcontext) of Sharepoint is not applicable to the proxy operation class, that is, if you want to use context-related information in the proxy operation class, you need to pass the parameters required to create the context object into the proxy class. For example, if you need to access a site in the proxy, you need to pass the site ID parameter into the proxy class, then the proxy class will use this cited site ID in its execution code to build a site. Then you can use the site. rootweb. currentuser to get the spuser object and its information.

Indicates the main working logic and important components of this processing method.

 

• Spproxyoperation. This class provides an abstract class for a fully trusted proxy. This class contains a method called execute, in which you can define the full information proxy operation you need to complete. Its fully trusted proxy class needs to be deployed to GAC (Global Assembly Cache) and registered to the ingress poin field using the method we mentioned above.
  
• Spproxyoperationargs. this class provides an abstract base class for you to create parameters passed to the fully trusted proxy class. You must create a serializable class that inherits from spproxyoperationargs, add attributes in this class to set and obtain parameters.
  
• Sputility. executeregisteredproxyoperation. This static method enables you to activate a fully trusted proxy in the sandbox code. This method requires a collection name, a type name, and a spproxyoperationargs object. This method returns an argument of type object to its caller.
  

Note that any type defined in the parameter class (proxy arguments class) passed to the proxy class must be marked as serializable, the type returned by the proxy operation also needs to be marked as serializable, so that information is transmitted between processes.

Whether the operation (operation) in the proxy or the parameter class of the proxy class must be deployed to the GAC. You cannot pass the type defined in the sandbox code to the proxy, because the proxy does not access the sandbox assembly you load.

2. External content type (external content types)

The external content type is a collection of reusable metadata, including connection information and data definitions, and actions to be applied to specific external data categories. Creating an external content type is typically the first step in using Microsoft Business connectivity services (BCS) to add data from an external data source to SharePoint 2010.

If you want to use the external data type in the sandbox solution, you can only implement it in a hybrid manner.

The external content type (external content types) must be defined in the feature of the field level (farm-scoped). It cannot be deployed as part of the sandbox solution.

To simplify the creation of external content types, business connectivity services provides two development tools: the external content type designer in Microsoft SharePoint designer 2010 and the Business connectivity services model designer in Microsoft Visual Studio 2010.

If your external data source has windows Communication Foundation (WCF), Web Service, or. net Framework Assembly integration service, or a simple Microsoft SQL Server database, you can use the external content type designer in SharePoint designer to discover your external system and create an external content type, you do not need to write code or XML. However, if your external system is complex or not supported by Sharepoint designer, you can use the XML editor in Visual Studio (providing intelliisense) to create an XML model, alternatively, you can use the Visual Studio external content type designer to create a file. net connection Assembly (the Assembly passes through.. NET Framework Code provides Custom backend integration logic ).

After the external content type is successfully created and deployed, you can create an external data list (external list) based on the external content type in the sandbox solution ), the external data list is used to obtain the external data.

Hybrid execution with external content types

We can use the splist object model of the external data list (external list) to obtain external data using code in the sandbox. We cannot directly use APIs during BCS runtime in the sandbox code to obtain external data.

Hybrid execution using an external list

 

When obtaining external data in the sandbox, we must face security issues.

As described above, the sandbox solution obtains external data through the external data list (external list). The external data list calls APIs at BCS runtime to obtain external data, tasks related to external data should be executed in the user code proxy service. For security reasons, when the context enters the sandbox Worker Process, Sharepoint removes the user creden。 bound to the context. Therefore, the Windows identity associated with this user will no longer act on the sandbox Worker Process and sandbox proxy process, because the user's windows identity will no longer work, the managed account of SharePoint becomes the basis for the sandbox to access external data or external services through BCS, all sandbox users run the user code proxy service based on the managed account of SharePoint ).

When BDC (business data connectivity (BDC) Service) receives a request for external data while running, it determines the Secure Storage Service (SSS )) whether or not the security creden are managed. We know that the Secure Storage Service (SSS )) the creden set can be securely stored for external systems and associated with individual or group identities.

If SSS is involved, the user ID associated with this request will be provided to SSS. Sss is responsible for associating this user ID with a credential in the external system credential set, then, the SSS will return the mapped external system credential to the BDC runtime, And the BDC will use this ing credential to access the external data. Because BDC does not receive credentials of individual users from a single user, you cannot restrict whether a specific user can access external data from the sandbox.

The following figure shows the processing process.

The following describes the steps:

1. The user code in the sandbox accesses external data by using the splist object model. When the sandbox submits a request to the user code proxy service, the user's identity token will be removed from the context.
   
2. An access request to the splist object model will be delegated to the user code proxy service, which passes the data request to the BDC during running, BDC Runtime is also running in the user code proxy service process ).
   
3. Next, BDC will call the Secure Storage Service (SSS) when it is running) the bound identity is the managed account bound to SharePoint that runs the user code proxy service. The external system creden。 requested by BDC are also mapped to an identifier in the user code proxy service, and SSS returns the creden。 to BDC.
   
4. The BDC runtime obtains the external content type from the BDC metadata cache (if the metadata is not in the cache, the BDC runtime will retrieve it directly from the BDC service ). Relying on the external content type metadata (external content type metadata), BDC can know how to interact with the external data system.
   
5. When BDC is running, use the identifier that SSS returns to it (the identifier that SSS returns to BDC from the third step above) to access the external data system and obtain the data required by the request.
   

 

3. Custom workflow activities (custom workflow Activities)

Hybrid execution using a declarative Workflow

By using this method, the fully-trusted code contained in the Custom workflow activity can be activated by the sandbox Worker Process and run asynchronously, in this way, the sandbox and full trust are mixed.

The Sandbox environment allows you to deploy workflows. A workflow can contain several workflow activities. SharePoint provides many out-of-the-box workflow activities, we can also develop custom workflow activities and deploy them to GAC (Global Assembly Cache) in full trust mode for sandbox use.

To create a fully trusted workflow activity, we need to set the Web. config file and add authorizedtype to it. In this way, the custom workflow activity you developed is in the same state as the out-of-the-box workflow activity in Sharepoint. The following code illustrates how to set authorizedtype.
:

< Configuration >

<System. workflow. componentmodel. workflowcompiler> 

<AuthorizedtypeAssembly= "... "Namespace= "... "Typename= "*"Authorized= "True" /> 

</System. workflow. componentmodel. workflowcompiler> 

</System. Web> 

When you add an authorization type, the Assembly attribute is the strong name of your Assembly, And the namespace attribute is the fully qualified namespace used by the activity class.

You can create and deploy workflow activities in the sandbox. These workflow activities are subject to the same constraints as those in the sandbox. If you want to break through these constraints, you can only develop and deploy workflow activities that are fully trusted. Note that the workflow engine itself is always running in full trust mode. When you deploy a workflow activity in a sandbox, the workflow engine adds specific constraints to the sandbox constraints based on the full trust mode.

The figure below shows how the workflow is executed. The declarative workflow is loaded from the sandbox solution, the custom fully-trusted workflow activity is loaded from the GAC cache ,.

Hybrid execution with a custom workflow Activity

Although declarative workflowis a specific definition for the case, it runs in processes such as owstimer.exe, w3wp.exe, or user code proxy process. That is, it is executed by processes running in fully trusted mode. Declarative workflow cannot be moved between SharePoint Foundation and Sharepoint Server. If necessary, you can only create one equivalent declarative workflow in two environments. Of course, there are more workflow activities provided in Sharepoint Server, and the management of declarative workflow is slightly different from that of SharePoint foundation, but they are the same in terms of packaging and deployment. As a good habit, it is recommended that the SharePoint version used for workflow development be consistent with that of the production machine, so as to minimize unnecessary troubles in the future.