SAP announces a new release of the SAP .NET Connector

In 2003 SAP released the SAP .NET Connector (NCo) to enable communication between the .NET platform and SAP systems. The first NCo versions (1.0x, 2.0) were aimed at .NET 1.x (with support for Visual Studio .NET and later on VS 2003), and it remained at that level. This resulted in the overall conclusion that the NCo was considered 'dead', or at least strongly outdated (Future Support of NCo). This idea was re-enfored in May 2009 by 1) the advice of Juergen Daiberl to use webservices or WCF Lob Adapter in favor of NCo, and 2) a statement of SAP's Rima Rudnik-Sirich phrasing that 'ES Explorer is a successor of NCo'.

However, the truth (or weakness) of SAP Enterprise Services is that currently only a limited set is available, supporting a restricted subset of the SAP business processes functionality. There are alternatives to custom develop SAP/MS intergration whenever it is not standard provided: WCF on SAP webservices, WCF BizTalk Adapter on SAP BAPIs and RFC. And forthcoming is Duet Enterprise, with a positioning for interoperability and collaboration between SharePoint 2010 and Office 2010 clients towards SAP processes and data.

And now SAP apparently decided to give new life to the NCo proposition. They have announced .NET Connector 3.0, to be released in December 2010. At first, this appears strange when you combine this announcement with the upcoming release of Duet Enterprise. However, Duet Enterprise is thus strictly scoped for interoperability between SharePoint plus Office 2010 and SAP environments. A renewed NCo will provide an additional alternative to communicate from other .NET application formats (e.g. WPF, WF, Services) to the SAP systems.

Test, QA and Production SharePoint infra should be comparable

In multiple SharePoint projects I have been confronted with delivered functionality succesfully validated in the test environment, does not operate the same in the QA environment. Since the application software is identical in the environments, the cause of the malfunctions must originate from differences at infrastructure level. Especially when it occurs in a later project stadium, this can be a very unpleasant surprise. Of course it's not realistic to expect nor demand that the Test, QA and Production environments are 100% comparable. However, the differences should be limited to hardware resources level; number of front-end servers, sizing of database, cpu, ... The infra architecture and configuration should be [logically] the same; load-balancing, firewall settings, proxy, Central Admin settings (e.g. Search, SSO, Policy for Web Application).

Extra complication to achieve such an ideal Test/QA/Production setup, is that typically the Test environment is much more volatile. This is the first environment to try-out your stuff, be it application functionality, infrastructure settings, or both. And in case of failure, not always the deployed trial stuff is rolled back. This is an extra argument to use virtualized Test environments per SharePoint project. When a new project start, an own Test environment is provisioned, with the current production state as its baseline. The project deploys all the project deliverables to this own Test environment. There is no overlap or conflicts with the work from other projects. And after project end (successful completion, or earlier stopped), the project Test environment can be deactivated and retired.

Installing CU 2010.0 corrupts local SharePoint environment

As at many, at my current customer deployment we're running our local SharePoint development environments in a virtualized image (currently Virtual PC; before it was VMWare Workstation). Recently we developers were informed by the SDE team on the availability of Cumulative Update 2010.0. Main reason to install that CU within your own local development environment is to come in sync again with the SharePoint installation state at the hosting platforms (development, QA and production).

Last week I installed the update. To discover next that my local SharePoint environment was broken! None of the local SharePoint sites would start up, including Central Admin. Running the Configuration Wizard also halted with an error. The eventlog contained the following error: The schema version (3.1.8.0) of the database WSS_Content_Project on <Machinename> is not consistent with the expected database schema version (3.1.11.0) on <Machinename>. Connections to this database from this server have been blocked to avoid data loss. Upgrade the web front end or the content database to ensure that these versions match.

Via this message I found the cause + solution in the following post: The schema version (3.0.149.0) of the database sps_content_db on MOSS. And indeed, after manually modifying for each SharePoint content database the version to 3.1.11.0 (in my case), all local SharePoint sites came back to live again.

Duet® Enterprise on stage at seminar 'SAP and Microsoft BI'

Recently I attended the Microsoft seminar 'SAP and Microsoft BI'. The focus of this seminar, and the audience, was evidently on Business Intelligence in a heterogenous SAP + MS IT landscape. But within this scope, also the forthcoming DUET Enterprise receives it's role. Juergen Grebe of the SAP / MS Alliance team had a good session on the interoperability architecture and the provided capabilities of DUET Enterprise.