Emphasis on Office 2010 hindering Duet Enterprise implementations?

In a blog of Venture Research I read the following rumor: "…about the partnership with Microsoft in Duet Enterprise, which my sources say is not advancing as fast as desired because many organizations are not anxious to upgrade to the latest release of Microsoft Office, which is necessary to derive the true value of Duet. This caution by organizations to update their underlying platform has good reasons in terms of cost and resource constraints, and SAP is not able to do anything about that."

If true, I find this a misconception and incorrect positioning of the Duet Enterprise potential. Surely, it also provides a Microsoft Office 2010 clients connection. But the true strength and potential of Duet Enterprise is that of a standards-based SAP / Microsoft interoperability foundation. It comes out-of-the-box with multiple integration plumping capabilities which you otherwise need(ed) to implement yourself. And being a commercial product, Duet Enterprise is backed-up by both SAP AG and Microsoft Corp as strong and future-proof IT suppliers.

That said, the implementation of Duet Enterprise puts its demands on the software server infrastructure in your company: SharePoint 2010 Enterprise Edition at the Microsoft stack, and NetWeaver 7.02 at the SAP stack. These are minimal necessities, without the availability of the both of them Duet Enterprise is not an option. But Microsoft Office 2010 at the client side is merely a bonus, not a prerequisite.

SAP Connector for Microsoft .NET 3.0 released

Yesterday SAP made the renewed version 3.0 of the SAP Connector for Microsoft .NET (NCo) officially available. This version is the long awaited successor of NCo 2.0 - which still had a design-time and runtime dependency on .NET Framework 1.x and Visual Studio 2003.

With the NCo, it is possible to directly interoperate from a .NET consumer context with SAP RFC's. It is thus a different approach as with Duet Enterprise - in which the SAP/SharePoint interoperability is achieved via standards-based webservices. The Duet Enterprise services are provided by the SCL, which transparently encapsulates and shields the specifics of the SAP backend towards the SharePoint consuming side.

In the earlier versions the NCo used the SAP librfc32.dll to achieve the SAP/.NET binary interoperability. In NCo 3.0 the RFC protocol is fully re-implemented in the NCo itself. Main advantage is that there is no longer the dependency on the librfc32.dll being available on each .NET consuming system. Also this should result in better performance as there is no more marshalling required in .NET client runtime context from the managed .NET code to the unmanaged librfc32 invocation.

In the previous NCo versions the programming model was to generate at design-time .NET-based proxies in Visual Studio 2003 per SAP RFC that you intend to call. This involved a proxy method for the ABAP Function Module, and an individual proxy class for each structure or data table used in the RFC signature. In case of a change in the SAP backend, the implication is that it is required to regenarate the proxies, and rebuild plus deploy a new assembly for the re-generated code. In NCo 3.0, the RFC call pipeline is dynamically constructed. Whenever there is a change in the enclosed SAP back-end, the NCo on-the-fly adapts the internal RFC invocation. NCo 3.0 transparently shields the .NET consumer from modifications and upgrades in the SAP backend. However, this approach also has its downside. You are in effect developing against a weakly-typed integration API, much resembling the .NET reflection pattern. There is no compile-time validation nor protection for incorrect RFC invocations.

The NCo 3.0 can be downloaded from SAP Service Marketplace, including accompanying documentation.