Microsoft Services has no concrete advice or guidelines on when to apply SharePoint versus SAP Enterprise Portal within a customer situation

At the last Microsoft Application Platform congress, Harry Tolsma gave a presentation on 'Optimizing your SAP-based business processes with the Microsoft Application Platform' (audio, slides). At the end of his talk, a question popped up from the audience on whether Microsoft has a decision matrix when to utilize MOSS, and when to hold on to SAP Enterprise Portal. At that moment, Harry could not give a conclusive answer on whether such a matrix is available at Microsoft Services. A time later I asked him whether he had more news on this.

The answer is that Microsoft Services does not have a concrete generic decision matrix and guidelines. The rationale is that each customer situation is specific, and requires a custom analysis and tuned advice. I intend to agree with this idea. With an important addition: for larger enterprises their specific customized advice and guidelines ought to be applicable across the entire enterprise, and should therefore be integrated within the enterprise referential architecture.
Reuse and application of the architectural guidelines and decisions is possible within the enterprise for unlocking and integrating of various SAP business functionalities and processes. My advice is to mandate this.

The blog of Kristian Kalsing contains 2 interesting posts related to the subject: ‘SharePoint versus NetWeaver Portal‘ and ‘EP/MOSS portal technology strategies’.

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability architecture guidelines roadmap

Apply partial classes to structure a multi-screen webpart

In a recent project I needed to implement a webpart consisting of multiple subscreens. The case is an employee self service application for the expensehandling business process. Usecases herein are to (re)view the status of your earlier entered expenses, and to enter new or modify existing expenses. In the UI design this resulted in 3 separate screens:

1. Overview of entered expenses

2. Details of one expenses

3. Input and edit form for a new expense

For an optimal user experience it is desired to present these different screens while remaining at the same location (thus webpage) in the enterprise portal. This can easily be achieved by incorporating the different screens within a single webpart, and apply a mode-flag to runtime determine which particular screen to render and respond to. A disadvantage of this approach is however that the webpart source file is considerable larger, and also contains different subfunctionalities with minimal cohesion. The solution for this is to structure and divide the webpart code in multiple partial classes. One partial class is the 'master', which delegates dependent on the mode-flag runtime behaviour to one of the 'child' partial classes. Each 'child' partial class contains and provides all the functionality for a single subscreen. End result is that the code is more understandable, and thus better to maintain.

Shared thought - achieving successfully SAP / Microsoft interoperability requires combined knowledge of both in a single team

Kristian Kalsing has published an interview on his blog in which Mike Fitzmaurice of Nintex gives a.o. his opinion on the current maturity of SAP / Microsoft interoperability in actual implementations. Bottom line, the technology stacks of both platforms have progressed enough, main obstacle in the current stadium is at the combined knowledge of both in the enterprise. Problem there is that in the typical organisation structure, the IT management of SAP respectively Microsoft environments is done by separate IT teams, sometimes even within separate departments. I placed a comment that I totally agree with Mike on his statement, and that I think that an essential factor for succesfully approaching SAP / Microsoft interoperability in an enterprise is to combine the knowledge + experience of both in a single team. However, it's like Kristian states in his reaction, "When a solution is required, it's usually handed to either the SAP camp or the Microsoft camp. Rarely are solutions architected to span across the two technology stacks".

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability roadmap organization department politics

Interesting report on how Microsoft phases out products

Today I had an architectural discussion with a colleague on the possible approaches to build applications on top of the Office platform. He mentioned the Information Bridge Framework. I had some reservations since that technology never really seems to catch much attention nor concrete applications, and therefore being doubtful on the future status of it. I did a quick search on the net for recent IBF news to check it's status and liveleness. The result was a confirmation in my doubts: Microsoft already in 2007 declared the outphasing of IBF in favor of VSTO...; within this report (Directions on Microsoft) there is background information on what grounds Microsoft decides to outphase products and technologies.

Dynamic updatable configuration in SharePoint list for Dependency Injection

Dependency Injection and Inversion of Control are 2 well-known and related design patterns to achieve flexibility and loose-coupling in your system architecture. Compile-time you decouple the consumer from the real provider(s) at interface level. At runtime the interface consumer is connected to a particular real implementation for the requested interface. The consumer is thus only dependent on the interface (= agreed behaviour), and transparent towards the concrete implementation. Dependent on situational factors, another implementation can be runtime provided to the consumer.

The responsibility for runtime instantiating and returning the correct particular implementation is typically delegated to a factory object. Multiple frameworks are available to provide a Dependency Injection (or IoC) container. Well-known are Spring.Net, Castle Windsor.

In a recent Proof-of-Concept I needed the flexibility to easily switch between different implementations of a service behaviour. Started with a stub when initially focussing on construction of the consumer (UI), followed by a variant with the business data stored in a SharePoint list in the local site, and finished with the ultimate version with the data stored in an external Lines of Business system, unlocked to the client via WCF. I prefer to name this plumping responsibility 'interface brokerage'. The signature of such a broker is simple:

I could have applied one of the available Dependency Injection frameworks. However, in this PoC evaluation I had some specific requirements which none of them seems to support all:

1. I want to be able to runtime change the configuration, and have this automatically picked up by the interface broker;


2. I want to share the same configuration entity accross multiple broker consumers (or rather, have only 1 single configuration entity to maintain);


3. Support different client contexts - SharePoint WebPart, WinForm, and also Silverlight control via the same interface broker implementation;


4. Be able to specify constructor parameters for the instantation of a service implementation (e.g. the name of WCF endpoint);


5. Be able to let the client access mode influence which implementation class is returned (for instance, to apply IsolatedStorage for the Silverlight control)
   

I decided to implement this specific brokerage functionality myself. And almost inevitable choose to apply a SharePoint list as configuration store. Benefits of this above a file based configuration are:

• It's possible to view and modify the configuration remotely within the browser; no need to have access to the server environment (is required to modify the web.config)


• Modification can be runtime determined and picked up by the broker (a web.config modification is also noticed, but results in a recycle of the application pool)


• Via the SharePoint List webservice the configuration can be accessed from any consumer context: SharePoint WebPart, WinForm, Silverlight [running at the client desktop], and even from non-Microsoft technologies like Flash, Java.

The following illustrations highlight the concepts of the resulting broker implementation:

  

Setup of the BrokerConfiguration storage

Example of a filled-in BrokerConfiguration

Code extract of reading in and parsing of the BrokerConfiguration

The essence of runtime determination + instantiating of requested interface provider (details and exception handling left out)

I hope that above gives you inspiration on the possibilities of utilizing the SharePoint functionalities within your system setup. Love to hear for what other system aspects one has applied the SharePoint functionalities...

Some of my Best Practices in SharePoint development

I've been a 'traditional' developer long before getting into SharePoint. Started on Unix platforms with C, C++ and Objective-C, next Java on both Solaris and Windows, and since 2000 mainly Microsoft (web)development. A common red line during my professional history is to apply Application Lifecycle Management principles. Ok, back then it was not phrased like that...; but still, we applied versioning control, nightly builds, peer reviews, static analysis.
The tooling support for ALM has substantially improved the last years; within Microsoft development most significant available via Team System / Team Foundation Server. Its different aspects - version control, static analysis, build support, work items, reporting, ... - can give a project and its stakeholders a better control and insight on how the project is [non]progressing.

My utmost best practice is to apply these same ALM principles and practices also within SharePoint development projects. This is not always commonplace, due to the different nature of SharePoint development compared to 'traditional' apps. SharePoint is namely amongst others a template platform, with a lot of functional and technical building blocks out-of-the-box available. You typically apply these for your own dedicated SharePoint portal or application via customatization. These are not directly source code artefacts which you edit and version control in a development environment, but can directly be performed in the SharePoint environment itself; and the customizations stored in the SharePoint content database.

That is all fine, excepts it presents you with a challenge when you need to deploy your SharePoint custom application to other environments.
I'm therefore a strong upholder to threat everything the project does for realizing a custom SharePoint application, as a first class source artefact. Store all your intermediate building items within your team productivity environment, and be able to repeatedly produce and provision your SharePoint application on whatever physical server or farm.

This results in my following list of some best practices:

1. Apply development and ALM principles - structure the application within architecture layers with the different responsibilities, provision the Visual Studio solution structure accordingly, implement and schedule an automatic build, identify, plan and divide the total work within workitems,
2. Strive for a first fully automatic deployable version as soon as possible. This is key to get your customers and users involved from the early stages on: give them something to see, feel, try-out, critize; but ultimately to reach a common agreement on what to build
3. Utilize the SharePoint platform's own inherent functionalities within the deployment process - Solution Framework, Features, SPWebConfigModification, ...
4. Honor the inherent out-of-the-box available SharePoint functionalities, above implementing your own custom variation. This richness is one of the strengths of SharePoint as an application development platform.
5. From start on [re]consider memory management and performance - for instance, include the usage of SPDisposeCheck within your development and QA processes
6. Distinguish between the two types of users of a Content Management site: content editors and the end users (readers)
7. Co-operate with your IT operations staff
8. Favor FieldControls above using the Content Editor WebPart

I can easily extend this list with more of my own experienced best practices, but then I'll be getting more into technical details and peculiarities. I'll leave that for another blog.

Whoami ?

I'm a strong believer of reuse whenever applicable... Therefore I present myself here via my company profile: