SharePoint Customization

Accelerating the development cycle

At aXelerate Solutions, we believe not only in building great software for our customers, but also in delivering solutions with the highest quality possible and that can evolve to answer future customer needs. Instead of writing new applications from scratch every time, we have dedicated several man-years in developing a framework for solution development: the aXelerate Libraries which literally accelerate the development cycle of Web 2.0 applications in general and SharePoint based applications in particularly.

More than a collection of components and tools, it is a multi-tier framework that includes a Continuous Integration (C.I.) cycle as well as automatic testing. The central element of the aXelerate libraries is the Business Object (BO). The Business Object is an entity which has its own internal business logic. A BO can be the status of the connectivity of a user as illustrated in the examples below. The BO can be manipulated as single entity or through a collection of BOs. The state of a BO can be saved in any data storage. By default, it is stored into a SQL database, but it any other permanent data store can be used. The BOs are accessed through the Business Logical Layer (BLL). Each BO can be accessed through Web Services as well and can be unit tested automatically.

The visible aspect of the BOs is exposed through the User Interface Layer (UIL). The UIL includes several Web controls component is designed to support Ajax and SharePoint. One important feature of the UIL is that it is possible to build forms and web parts using an XML definition.

The bottom layer of the aXelerate libraries is composed of the Data Adapters to the data store. The data adapters allow to virtualize any data store to the Business Objects. Separating the data storage from the business logic layer makes the entire stack very flexible. In the example below, we are demonstrating a simple SharePoint web part which maintains the connectivity status of a user in an enterprise. In that example, the UI part is built using an XML definition and is connected to a BO which in turns is connected to a data adapter. It is possible to change the data storage of the BO on the flight and even the BO, resulting in a complete change of behavior of the web part without changing any code.

Click on any picture to view full size.


the aXelerate libraries development cycle	Details of the aXelerate libraries
The key steps of our development cycle are: The Build leverages the Visual Studio Team Foundation System build technology. Each time a change is detected in the source code, a new build starts. The Test leverages the aXelerate testing framework to automatically unit test each business objects and to test on virgin environment. The Deploy leverages Microsoft Virtual Server and Virtual Machines technologies: we systematically deploy and test on multiple VM environments while creating stronger installer. The Deliver step minimizes the risk of delayed product deliver while creating products with higher quality standards.

User Interface Layer

The User Interface Layer of the aXelerate Libraries is designed to provide Codeless Customization. A user interface page can be done in XML instead of writing HTML or ASP.NET code. One of the key advantages is that the same XML designed form can be used in an ASP.NET page or in a SharePoint Web Part. Because the U.I. layer is coupled with the aXelerate Business Logic Layer, all the security is handled in one location in the business logic layer, not in the presentation layer.

Of course, an XML UI layout scratches only the surface of what we can do. We support AJAX, grid embedded in another grid, tree and we can integrate other toolsets available from 3rd party developers. Because we developed the source code for the presentation layer, we can fine tune the end-result in a far more precise and rapid fashion than having to rely on the original toolset provider.

The example below demonstrates how a simple Web Part form is displayed in SharePoint and how it is linked to its XML definition.


SharePoint web part build using an XML template	Connection to the XML template is managed by the web part chrome	XML definition of the web part

Business Logic

The Business Logic layer of the aXelerate Libraries is designed to map heterogeneous technologies to standard business semantics. It includes Business Object, Business Collection and Business Activity. The BLL interfaces with the internal details of the SharePoint APIs and present a unified “business surface” to the UI layer and it makes the manipulation of the SharePoint objects much easier.

The BLL provides also supports for Windows Workflow Foundation. This means that every object, collection and activity can be inserted into a workflow. This means that it is possible to build more complex workflows than the ones offered in SharePoint because SharePoint objects and non-SharePoint objects can be inserted into the same workflow. Additionally, every object, collection and activity can be invoked through Web Services.

The aXelerate BLL also includes a customizable security model. It can derive from the SharePoint security model or be completed independent from SharePoint, i.e. implementing it using AzMan, or integrate security from multiple source.

Because testing is critical in a real deployment environment, the BLL includes out-of-the-box automated testing which allows creating stress tests. This allows constant testing during the development of a project and increases dramatically the quality of the end-result application.


This SQL table contains the definition used by the Web Part above	This sample code illustrates the different regions used to define the business object which manages the Web Part above	Details of the field maps and how they are mapped against the data layer


How each property of the B.O. is accessed	Example of the business object collection (of the same B.O.)

Data Layer Abstraction

Example of a SharePoint web part build using an XML template

The Data Adapters integrate multiple technologies: they are able to read from different data sources, access Web Services, direct read APIs, and other heterogeneous technologies while providing the same interface to the Business Objects. A BO does not need to know how or where the data is stored, it can access it directly through the data adapter layer.

Let’s take an example of a BO which manipulates documents. The entire UI and BO can be written and tested with accessing documents inside a SQL database. Without any code at all, the same BO could manipulate documents stored in a SharePoint document list.

From out of the box, the Data Layer integrates SQL and any other OLE databases. Only when accessing specific data store it is necessary to add a new adapter data layer.

Conclusion