Business Connectivity Services
Business Connectivity Services (BCS) formerly known as Business Data Catalog (BDC) in a SharePoint 2010 enables easier integration with Line Of Business systems. This allows developers to perform CRUD operations on data they need for a particular business process in one place regardless whether data is housed in SharePoint or otherwise.
The idea behind this functionality is to expose Line of Business data from your back end services (such as People Soft, SAP, custom databases etc.) to business analysts so they can use them within SharePoint. Each piece of information (for example a table in a database that has your Customers information) can be exposed as an External Content Type (ECT) by an IT professional or a developer using SharePoint Designer 2010. Then a business analyst can use SharePoint through the web browser to make an External List which uses this ECT. The result will be that they have a list now showing information straight from the Customers table. When anyone manipulates the information in that External List, it will actually be written back to that table in the database.
Benefits of ECTs:
1. Reusability
2. Enabling working offline Mode
3. Secure Access
4. Encapsulate complexities of external systems.
5. Allows user to perform CRUD operations easily.
6. Integrated with SharePoint provides built in Office and SharePoint behavior.
After you create an external content type, you can use any of the presentation features of Microsoft Business Connectivity Services (BCS) to provide a rich experience to the user, without writing any code.
Presentation Features on the SharePoint 2010 Server
1. External Lists in SharePoint 2010 exposes BCS entities to the end user through familiar SharePoint List UI.
2. External Data Columns: The Business Data list column type is now renamed External Data column, and it enables users to add data from external content types to standard SharePoint lists.
3. External Data Web Parts: BCS continues to offer Web Parts: External Data List, External Data Item, External Data Item Builder, External Data Related List, and External Data Connectivity Filter.
4. External Content Type Picker: An External Content Type Picker provides picking and resolving functionality to the user. You can embed a picker in a form or page for scenarios where a user should be able to pick an external content type from the list of available external content types.
5. Profile Pages: Profile Pages are SharePoint pages on the server that display the details about an external item. Just like any other SharePoint Web Part page, you can customize this page to show details of an external item.
Tuesday, January 12, 2010
SharePoint 2010 Sandbox Solutions
Sandbox is a safe virtual container, in which untrusted programs can run safely. In this environment, program runs in strict limitations on what system resources the program can access. Sandboxes are used when executable code comes from unknown or untrusted sources and allow the user to run untrusted code safely.
A sandboxed solution can be monitored by two levels of administrators, the site collection administrator monitor the site collection and farm administrator monitors on per site collection basis through central admin site. A sandboxed solution can be deployed easily by site administrator of a site collection.
Architecture:
The sandbox in SharePoint is implemented as a separate process where your sandbox solution code will run. In fact, there are three processes.
User Code Service
SPUCHostService.exe, also known as the User Code Service. This service runs on each server on the farm that we are going to allow to work in the sandbox. Thus the infrastructure ogres can choose to run this service on all, or only a certain subset of the servers in the farm. This is an important consideration, because this constitutes an important part around the administration of sandbox solution infrastructure, namely the load balancing aspects. There are two approaches to load balancing sandbox solutions on your SharePoint Farm.
Sandbox Worker Process
The sandbox worker process SPUCWorkerprocess.exe is where your actual code runs! This is in contrast to having the code run inside of w3wp.exe. This is why you don't have to restart the application pool every time your redeploy an sandbox solution.
Sandbox Worker Process Proxy
The Sandbox worker process proxy SPUCWorkerProcessProxy.exe, which is built on the new services infrastructure in SharePoint.
Sandbox assemblies run under a separate service called as SPUserCodeV4. The sandboxed solutions are also restricted by an out of the box CAS policy. The CAS policy for sandbox solutions grants you the following policy permissions:
1. SharePointPermission.ObjectModel
2. SecurityPermission.Execution
3. AspNetHostingPermission.Level = Minimal
With default CAS, there is a limited access to SharePoint Object Model, No file I/O, no call to web service. There are two other important points to note in this out of the box CAS Policy
1. While your code is restricted to the CAS policy permissions defined above, it allows the SharePoint framework code full trust.
2. If your custom code needs to break out of this sandbox's boundaries, you can always write a full-trust proxy.
This means we can’t elevate privileges in such an environment and we land up with complex solutions, sandbox solutions are bad in such scenarios. However, before implementing any sandbox solutions, we must consider constraints under which it has to be executed.
With Sandbox solutions, web parts derived from Microsoft.SharePoint.WebPartPages.WebPart is not supported, only support web parts derived from System.Web.UI.WebControls.WebPart namespace.
Disadvantages of Sandbox solutions:
1. No support to Microsoft.SharePoint.WebPartPages namespace.
2. It’s more secure, can’t elevate privileges and leads to more complex codes.
3. Making web service calls over the internet, or accessing code that is not marked to allow partially trusted callers are not supported. You also can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution, and security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed.
4. No support to SPUtility.SendEmail namespace for sending mails.
A sandboxed solution can be monitored by two levels of administrators, the site collection administrator monitor the site collection and farm administrator monitors on per site collection basis through central admin site. A sandboxed solution can be deployed easily by site administrator of a site collection.
Architecture:
The sandbox in SharePoint is implemented as a separate process where your sandbox solution code will run. In fact, there are three processes.
User Code Service
SPUCHostService.exe, also known as the User Code Service. This service runs on each server on the farm that we are going to allow to work in the sandbox. Thus the infrastructure ogres can choose to run this service on all, or only a certain subset of the servers in the farm. This is an important consideration, because this constitutes an important part around the administration of sandbox solution infrastructure, namely the load balancing aspects. There are two approaches to load balancing sandbox solutions on your SharePoint Farm.
Sandbox Worker Process
The sandbox worker process SPUCWorkerprocess.exe is where your actual code runs! This is in contrast to having the code run inside of w3wp.exe. This is why you don't have to restart the application pool every time your redeploy an sandbox solution.
Sandbox Worker Process Proxy
The Sandbox worker process proxy SPUCWorkerProcessProxy.exe, which is built on the new services infrastructure in SharePoint.
Sandbox assemblies run under a separate service called as SPUserCodeV4. The sandboxed solutions are also restricted by an out of the box CAS policy. The CAS policy for sandbox solutions grants you the following policy permissions:
1. SharePointPermission.ObjectModel
2. SecurityPermission.Execution
3. AspNetHostingPermission.Level = Minimal
With default CAS, there is a limited access to SharePoint Object Model, No file I/O, no call to web service. There are two other important points to note in this out of the box CAS Policy
1. While your code is restricted to the CAS policy permissions defined above, it allows the SharePoint framework code full trust.
2. If your custom code needs to break out of this sandbox's boundaries, you can always write a full-trust proxy.
This means we can’t elevate privileges in such an environment and we land up with complex solutions, sandbox solutions are bad in such scenarios. However, before implementing any sandbox solutions, we must consider constraints under which it has to be executed.
With Sandbox solutions, web parts derived from Microsoft.SharePoint.WebPartPages.WebPart is not supported, only support web parts derived from System.Web.UI.WebControls.WebPart namespace.
Disadvantages of Sandbox solutions:
1. No support to Microsoft.SharePoint.WebPartPages namespace.
2. It’s more secure, can’t elevate privileges and leads to more complex codes.
3. Making web service calls over the internet, or accessing code that is not marked to allow partially trusted callers are not supported. You also can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution, and security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed.
4. No support to SPUtility.SendEmail namespace for sending mails.
Subscribe to:
Posts (Atom)