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.

Participating in Duet Enterprise Ramp-Up / Rapid Deployment Program

This blog is earlier published on SAP Community Network Blogs

In May this year, TopForce applied as IT partner together with an end-user organization for participating in the Duet Enterprise Ramp-Up. Rationale for both organizations to participate in this Rapid Deployment Program is to gain in an early stadium insights and practical experience on the potential and added value of Duet Enterprise.

Our mutual application was accepted by the RDP Program in June. As one of the first activities, both organizations each sent 2 to 3 employees for Duet Enterprise training. Actually this was a requisite for RDP participation. The 5-days training addressed both the infra/operations aspects of Duet Enterprise in the SAP and Microsoft landscapes [3 days], and the development approach in the SAP and Microsoft development suites [2 days].

After this first introduction to the Duet Enterprise product, we received access to the software bits and accompanying documentation. The last mostly in draft versions, understandable as the product is still in Ramp-Up.

Reasons for participating

The mission of TopForce is to deliver the concept of High Performance Workplace for our customers. In essence this means that we aim for ease of use in the daily workspace of the employees, thereby abstracting the nifty details of the total backbone IT landscape. As our background comes from SAP consultancy, at a lot of our customers SAP is [part of] the business back-end. In our HPW vision, one of the means to achieve a pleasant employee workplace is operating the SAP back-end via a SharePoint based front-end (Unlock the value of SAP business processes within a SharePoint based HPW). We defined a conceptual integration architecture for this SAP-backend / MS-frontend interoperability. The architecture is validated via multiple interoperability technologies and products; e.g. WCF to BAPI WebServices, WCF LOB Adapter, Sitrion. Drawback in all was that we still had to develop a lot of the interoperability plumbing ourselves, most noticeable the support for Single Sign-On. Duet Enterprise now promises to be a good (best?) additional alternative for enabling SAP / MS interoperability.

Our partner shares this same goal, but also has a clear additional target. In the recent history several projects have emerged in which SAP / Microsoft integration might be subject for business and IT architectural decision making, and/or in which SAP / Microsoft integration is concrete realized in some aspects. As the role of both SAP as Microsoft server landscapes is gaining importance at this end-user organization, they have the need for consistent design guidance on when and how to achieve SAP / Microsoft interoperability. Duet Enterprise is participated in this context as an important integration technology to consider.

Project team

Our RDP project team consists of the following roles / persons:

From the end-user organization

1. Project lead
2. SAP solution architect
3. Microsoft solution architect
4. SAP business analyst
5. SAP infra/operations
6. SharePoint infra/operations
7. SharePoint developer
8. SAP NetWeaver solution architect / consultant

From TopForce as IT partner

1. SAP / SharePoint interoperability consultant (my participation in this Ramp-Up)
2. ABAP developer [only temporarily required]

From the combined SAP / Microsoft RDP support team

1. SAP NetWeaver consultant [from SAP AG]
2. SharePoint consultant [from Microsoft Services]
3. Whenever applicable, supplemented with SAP and Microsoft consultants with varying expertise’s; dependent on nature of discussions and encountered issues

Validation approach and activities

The potential of Duet Enterprise is twofold. On one side it delivers directly usable out-of-the-box functionalities, customizable in some degrees to your situation. Second to that, and this is where it strongly differentiates from the original DUET proposition, it provides a SAP / SharePoint interoperability foundation. Although the first is certainly interesting, our main combined focus for now is evaluating Duet Enterprise for the added value on interoperability plumping aspects. This validation is done by means of a real-life custom-developed application. The following activities are executed by the RDP team:

• Attend the Duet Enterprise training to get acquainted with the infra and development aspects
• Install and configure Duet Enterprise in the SAP NetWeaver 7.02 and SharePoint 2010 landscape
• Derive and define the Software Architecture Design for the selected real-life application
• Discuss the Software Architecture Design with RDP consultants, from SAP AG and Microsoft Corp.
• Model, compose and [only] where required custom-develop the interoperability + integration between SAP backend environment, and SharePoint 2010 based front-end
• Derive and define the Design Guide for SAP / Microsoft integration decision making at business and IT architecture level

Where do we stand / Results so far

In this near-end phase of the Ramp-Up program, approaching the General Availability of Duet Enterprise, it is not viable to go into product details. This will be addressed later, after the successful conclusion of our Ramp-Up participation.

Results and findings that I can share now are:

• Getting acquainted with the design and development approach for Duet Enterprise application has an initial steep learning curve. Mind you, this will be less after General Availability when the accompanying documentation will be more complete and mature.
• Installation and configuration of Duet Enterprise takes its time. This is mainly due the complexity of any typical SAP landscape anno 2010 (aka ECC, NetWeaver, Solution Manager, SLD, ESS and MSS, …), and not so much to direct back to Duet Enterprise specifically. On SharePoint 2010 side the work is much less, although also here it depends on the characteristics (complexities) of the SharePoint farm.
• This RDP project is an evidence for the added value of a mixed SAP / Microsoft development team (Build Your Interoperability Team as 1 of the Steps HowTo begin with SAP / MS interoperability)
• It pays out if the SAP and Microsoft solution architects are on a general level familiar with the ‘opposite’ platform stack. E.g. what’s the positioning of SAP PI versus Microsoft BizTalk; what is the concept and support of SAP Enterprise Services;
• It pays out to have at least one team member aboard that has knowledge and practical experience on the SAP / MS interoperability area; knowledge of both technology stacks, interoperability technologies and approaches.
• And final remark: SAP / MS interoperability is and remains interesting stuff; from business and IT architectural point of views…

Duet Enterprise is approaching the General Availability date. If you are considering its application for SAP / Microsoft interoperability, I like to share ideas and actions.

2 approaches to architecting SAP / SharePoint interoperability

This blog is earlier published on SAP Community Network Blogs

In today’s market the interest is growing to integrate the structural business processing of SAP within the familiar workplace environment of the Information Worker. These enterprise workplaces are in more and more companies provided by means of SharePoint 2007/2010. To achieve the SAP / SharePoint integration on structural and future-proof manner, requires investigation at forehand to come up with a solid interoperability architecture.

Main steps to define a solid SAP / Microsoft.NET interoperability architecture

1. Derive and define guiding principles; originating as first from the business perspective, and next from IT. Typically the latter are more of constrictive nature; e.g. required to apply a service architecture, required to conform to W3*-standards, ...
2. Analyze the current state of the IT landscapes (‘IST’) within the company: SAP and Microsoft environments and server products.
3. Define and describe the interoperability architecture
   • Conceptual level; on purpose technology and product agnostic, to make it more timeless and future-proof
   • Concrete level; with a choice for interoperability technologies and products that are nowadays available
4. Validate the interoperability architecture by means of either a Proof-of-Concept, or via a small launching interoperability project.
5. Adjust the defined interoperability architecture on the lessons learned.

Guiding architecture principles

1. Layered architecture, with separation of concerns. A typical layer architecture is:
• Presentation
• Integration
• Application
• Data
2. Service architecture
3. Loosely coupled
4. SAP business backend is and remains responsible for the correctness of business process
5. Responsibility of business data consistency within the SAP backend layer

Approaches to derive the interoperability architecture for a concrete case

When in context of a concrete application, there are basically 2 approaches you can apply to derive the layered interoperability architecture:

1. Inside-Out
2. Outside-In (nb: in Microsoft terminology, this approach is also referred to with the phrase ‘Contract-First’)

Inside-Out

As the name already suggests, the starting point here is your current SAP landscape state. Start with identifying the available functional building blocks in the SAP environment – existing BAPI Function Modules, RFC’s, SAP workflow business objects, and already available SAP webservices. And expose these to outside world, to have the related SAP data and functionality consumed by a non-SAP front-end.

Advantages

Biggest advantage of this approach is that you have a faster time2market. You can base your SAP / Microsoft.NET interoperability on already existing, and thus also tested, SAP building blocks. The only thing that needs to be done is to put a (web)service interface on them, and then you can integrate with the Microsoft based presentation layer.

Disadvantages

This can be summarized with the phrase ‘Garbage In – Garbage Out’. If you base your interoperability architecture on the current state of your SAP environment, there is a large likelihood that SAP-proprietary concepts will be visible on the integration surface level. In general, an architecture that originates via this approach will be less pure and transparent. And thus less future-proof.

Outside-In

The essence of the Outside-In approach is to first agree on and define the conceptual contract [interface] between the service provider side [SAP], and the service consumer side [SharePoint]. The idea is to start from the requested application functionalities. Derive and define at a conceptual level the services you require from the SAP backend to deliver the application and system functionalities. Describe the service interfaces in W3*-standards based notation and data structures. From here on, map onto required SAP building blocks: existing if available, new ones otherwise. At SharePoint / presentation side, you can build the consumption layer for the defined service interfaces via wsdl.

Thus start at ‘outside’ with the conceptual, externally visible service interfaces; and continue then for both provider and consumer / SAP and Microsoft sides to the inside with their respective technologies.

Advantages

Because you start in this approach with a green field, the resulting interoperability architecture typical has a cleaner interface, which inherently conforms to interoperability standards. And because you start from the required business services, it also has a better chance on being conceptual correct, and future-proof.

Disadvantages

Biggest disadvantage is that this approach requires more investment and time at front in deriving and describing the service interface layer. Also it requires to get both SAP and Microsoft departments representatives on par, to have a common understanding of the applied service concepts. And in case of existing SAP building blocks, a transformation can be required to map the standards-based service interface to the SAP-specifics Function Modules, RFC’s, workflow business objects.

SAP project "Gateway" and Duet Enterprise

Project "Gateway" was prominent on the agenda of this years SAP TechEd. In an interview with SearchSAP.com, SAP’s Chief Technology Officer Vishal Sikka got into more detail on the role and proposition of Gateway, and the relation it has with the Duet Enterprise product.

Some remarkable statements, and messages derived from this interview:

• Gateway is the bridge from the existing system, e.g. [SAP ERP] 4.6c application with all customizations, to the new world – SharePoint, Facebook, Twitter; without requiring your SAP customers to upgrade to a new version which is inherently service enabled.
• Gateway is a mechanism to enable an existing SAP system that is dark to the outside world, and to put windows on it.
• SAP Enterprise Services are usually large, and they are designed for process consumption, not for UIs.
• The Gateway, think of it as a protocol adapter, that you can attach to a legacy SAP system and have it speak to the world outside.
• Duet Enterprise is a product we have built with Microsoft that has the Gateway inside it that has the abilities to connect the world of SharePoint.

Duet Enterprise Overview presentation at SAP TechEd 2010

Virtual SAP TechEd 2010 presents the recorded 1-hour session CD109 - Duet Enterprise Overview: Consume and Extend SAP Applications Through Microsoft SharePoint and Office. The presenters were from SAP AG, Microsoft Corp and CapGemini. In this session the business goals of Duet Enterprise are outlined, at high-level the advantages it brings for companies doing or considering SAP / Microsoft interoperability, discussion of the architecture and runtime flow, and the development toolset + process. Accompanied by (life and pre-recorded) demo's.

Some of the take-aways of this presentation:

• Duet [Enterprise] Service Consumption Layer is the first version of SAP's project "Gateway", embedded in Duet. The aim of project "Gateway" is provide simplified access to SAP:
  SCL, internally referred to as 'Gateway Layer'

  
  Framework built as an NetWeaver ABAP add-on, enabling simplified access to SAP software from any device or environment using standard market protocols


• Primarily, Duet Enterprise is working as an Add-On on both sides; NetWeaver stack and SharePoint stack
• [SAP service-enabling] Business entities from SAP available as Web Services; [SAP consumption] Discover SAP information as External Content Types in BCS, and connect to SharePoint/Office.
• The ready to use Duet Enterprise capabilities, are also building blocks that you can use and even build upon in your custom solutions
• SharePoint Duet Enterprise front-end development distincts 3 Solution Types:
  1. Simple - by end-user; within the SharePoint GUI
  2. Intermediate - by Power User; via SharePoint designer
  3. Advanced - by a .NET developer; via Visual Studio


• Study on the effort it takes to develop SAP/SharePoint integration learns that without Duet Enterprise it costs 6 times
• Create solutions very fast to address business (needs) very quickly. Not create very big applications, but small ones and do it fast
• SAP services are fairly complicated, with nested and complex structures. SAP WSDL's kinda have their own definition, slightly away from the WS*-standards
• Duet Enterprise can either map SharePoint users to SAP users through the Duet Enterprise User Mapping component, or connect to a LDAP that this mapping.

See also slides of the presenation

Steps HowTo begin with SAP / MS interoperability

Important aspect of applying SAP-Microsoft interoperability within a company IT landscape, is how to start. Almost always the Microsoft and SAP departments form their own community in the company, with only limited contacts and co-operation between them, and no clear understanding of each others platforms, technologies and capabilities. See also earlier posts of Kristian Kalsing [1] and of myself [2] addressing this issue.

Raymond Smith [Microsoft Corporation] published an interesting article on this: Building an SAP/Microsoft Interoperability Team. In his article he distinguishes and details on the following aspects:

Aspects of Building an SAP/Microsoft Interoperability Team

1. Build a SAP Interoperability Lab
2. Determine a Proof of Concept Business Process
3. Build Your Interoperability Team
4. Cross Train Developers
5. SAP Interoperability Training
6. Determine Architecture
   • Security
   • SAP Architecture
   • SharePoint/.NET Architecture
7. POC Development

I recognize [most of] these steps from own experiences with SAP / MS interoperability implementations. For the details, I strongly advice to read Raymond's article.

Debugging Error upon creating MySite

In a SharePoint intranet, feature stapling is applied to the standard MySite site definition to customize and extend the newly created employee’s MySite’s. After making some requested changes to the custom MySite masterpage, I deployed the SharePoint solution to the development farm. When validating that upon first visit an employee’s MySite is still successful and correct created, I got a runtime error. The display error message gave no details on the problem cause, and in the 12hive log no related information was found. Due a lack of rights to open the EventLog on the remote development server, I could not [myself] check whether in there useful logging was available.

So, what to do? Due the nature of my changes I was pretty sure that the malfunction could not be related back to them. But pretty sure is not good enough, when the ultimate deployment target is the company production intranet. I needed to exactly pinpoint the problem cause, and proof that it was not related to my deployment.

The SharePoint standard MySite creation handling hides the details of the thrown and catched exceptions. To detect what exception was thrown, I therefore created my own DebugMySite.aspx, and filled it with the basics of the standard MySite creation handling – with the noticeable difference to expose the exception details within the browser. Via this debugging approach I learned that the internal error message reported the following:

My Site creation failure for user '<domain>\<username>' for site url 'https://SharePointServer/personal/<username>'. The exception was:
Microsoft.Office.Server.UserProfiles.PersonalSiteCreateException: There has been an error creating the personal site ---> System.ArgumentException: Value does not fall within the expected range.
at Microsoft.SharePoint.Library.SPRequestInternalClass.SscCreateSite(Guid gApplicationId, String bstrUrl, String bstrServerRelativeUrl, Int32 lZone, Guid gSiteId, Guid gDatabaseId, String bstrDatabaseServer, String bstrDatabaseName, String bstrDatabaseUsername, String bstrDatabasePassword, String bstrTitle, String bstrDescription, UInt32 nLCID, String bstrWebTemplate, String bstrOwnerLogin, String bstrOwnerUserKey, String bstrOwnerName, String bstrOwnerEmail, String bstrSecondaryContactLogin, String bstrSecondaryContactUserKey, String bstrSecondaryContactName, String bstrSecondaryContactEmail, Boolean bADAccountMode)
at Microsoft.SharePoint.Library.SPRequest.SscCreateSite(Guid gApplicationId, String bstrUrl, String bstrServerRelativeUrl, Int32 lZone, Guid gSiteId, Guid gDatabaseId, String bstrDatabaseServer, String bstrDatabaseName, String bstrDatabaseUsername, String bstrDatabasePassword, String bstrTitle, String bstrDescription, UInt32 nLCID, String bstrWebTemplate, String bstrOwnerLogin, String bstrOwnerUserKey, String bstrOwnerName, String bstrOwnerEmail, String bstrSecondaryContactLogin, String bstrSecondaryContactUserKey, String bstrSecondaryContactName, String bstrSecondaryContactEmail, Boolean bADAccountMode)
at Microsoft.SharePoint.Administration.SPSiteCollection.Add(SPContentDatabase database, String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String secondaryContactLogin, String secondaryContactName, String secondaryContactEmail, String quotaTemplate, String sscRootWebUrl, Boolean useHostHeaderAsSiteName)
at Microsoft.SharePoint.SPSite.SelfServiceCreateSite(String siteUrl, String title, String description, UInt32 nLCID, String webTemplate, String ownerLogin, String ownerName, String ownerEmail, String contactLogin, String contactName, String contactEmail, String quotaTemplate)

With these error details, I could do a focussed search on the internet. And found this related forum-entry Error creating MySite: There has been an error creating the personal site, which had the answer: "add the account configured as the Application Pool Identity for the web site to the "Farm Administrators" group through the Central Administration pages". This was the situation earlier for the intranet webapplication on our development farm, but somehow this got broken. With this knowledge I went to our IT pro, and asked them to restate the AppPool identity as a farm admin, followed by an IISReset. After that, the MySite creation problem was solved.

Duet Enterprise - Technical Overview presentation

Upon searching on 'Duet Enterprise', I came accross this posted presentation with technical overview. Next to the expected high-level on the Duet Enterprise proposition, this powerpoint also contains some more in-depth explanatory visualizations of the technical and system flow in capabilities like authorization and single sign-on, SAP role based authorization, workflow, monitoring.

Note, the presentation is [declared] prelimary; in awaiting of RTM.

More [functional] robustness issues with OOTB InfoPath Forms Services

Earlier I blogged about some robustness issues I encountered with the application of InfoPath Forms Services in an external facing SharePoint site. The basis of the framework developed in that project is re-used in context of the company's intranet. Hereby I ran into some new robustness issues. I'll describe them here, and also the outline of the applied solutions.

1. Placing XmlFormView webpart on a SharePoint page conflicts with inline server codeblocks in MasterPage
   Immediately upon adding the out-of-the-box Microsoft.Office.InfoPath.Server.Controls.XmlFormView webpart on a publishing page in the company's intranet, SharePoint throwed an exception:

   Source: System.Web
   Message: The Controls collection cannot be modified because the control contains code blocks (i.e. ).
   Stacktrace:
   at System.Web.UI.ControlCollection.Add(Control child)
   at Microsoft.Office.InfoPath.Server.SolutionLifetime.ScriptIncludes.AddCssLinkToHeader(HtmlHead head, String href)
   at Microsoft.Office.InfoPath.Server.Controls.XmlFormView.TryToAddCssLinksToHeader()
   at Microsoft.Office.InfoPath.Server.Controls.XmlFormView.OnDataBindHelper()
   at Microsoft.Office.InfoPath.Server.Controls.XmlFormView.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.WebControls.WebParts.WebPart.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint

   
   

   First analysis learned that the problem was related to the applied SharePoint MasterPage: it manifested itself with 2 of our custom MasterPages, but not on other custom nor the standard (Publishing) Masterpages. Inspection of the particular custom MasterPages disclosed the following server-side code:

   <% Response.Write("<script>var Collaboration_SiteRelativeUrl='" + SPContext.Current.Site.Url + "';</script>"); %> 

   
   

   The inclusion of this inline server codeblocks resulted in the conflict with the server-side operation of the XmlFormView webpart. The solution was to replace the inline server codeblocks-tags '<%' and '%>' approach by a HtmlHead (which is a webcontrol) databinding approach:

   
   

   <script>var Collaboration_SiteRelativeUrl="<%# SPContext.Current.Site.Url %>";</script> 

   
   

   And in the MasterPage codebehind:

   
   

   protected override void OnLoad (EventArgs e)
   {
       base.OnLoad(e);
       Page.Header.DataBind();
   } 

   
   

   
   

   
   


2. IE 6 gives a runtime Javascript error in case of RichTextBox control on the form
   While demonstrating the potential of the self-service WebForms functionality to internal stakeholders, I was asked to modify an earlier published InfoPath form with the placement of a RichTextBox control. After re-publishing the InfoPath form to the SharePoint target site, the form still correctly displayed in the content page; including the added RichTextBox control. However, when positioning the mouse in the RichTextBox control, the IE6 browser (Red: still the company's standard) reported a runtime Javascript error. Also the RichTextBox toolbox was not displayed, leaving the control pretty useless wrt a plain TextBox control.
   
   With these problem symptons, I kinda got a 'Deja-Vu' feeling. It looked very much like the problem earlier encountered with displaying InfoPath forms in IE 6. And indeed: via Javascript debugging I detected that the client-side runtime error manifested itself in the same OOTB InfoPath Inc/Core.js method as before: ErrorVisualization.ComputeAbsoluteTop(). Was then the problem caused by the usage of relative CSS-positioning applied in the custom branding, this time it proved completely InfoPath related. I could easily reproduce the same problem within a standard SharePoint WebPart page, with a standard MasterPage. The explanation of the IE 6 Javascript problem is in the HTML that InfoPath Forms Services renders for a RichTextBox control: an embedded iframe element within the DOM document. Due to the fault behaviour of the IE 6 offsetParent method implementation in combination with the non-robust/error-prone implementation of the OOTB InfoPath method, this results in the runtime Javascript error.The solution was to runtime at browser/client-side expand that OOTB InfoPath method to make it robust for the IE 6 faulty CSS offsetParent implementation.
   

   
   

   
   

   
   

   
   


3. InfoPath re-publishing adds duplicate site columns to the ContentType
   
   Upon re-publishing an InfoPath formtemplate during the demonstration, I noticed another issue. It looked as if all promoted fields in the ContentType were now duplicate present. A quick internet search learned that this is a known InfoPath feature/behaviour, just something I myself was not aware of upto now. And neither something I was particular happy with. I think it is pretty ridiculous to add a complete other set of fields to the InfoPath ContentType each time you re-publish the associated formtemplate. You have some control-options in the InfoPath publishing wizard to prevent the creation of another set of promoted fields, but this is manual-dependent and thus error-prone; let alone it is also very cumbersone and clumsy for the functional managers (the first-class users of the self-service WebForms functionality in the company portal). Therefore I sought for a manner to afterwards correct the modified ContentType, by removing all duplicate FieldLinks. Ideally did would be done fully automatic in the scope of the InfoPath publishing, and thus transparent and invisible to the WebForms functional managers. Sadly, SharePoint does not have an EventReceiver signalling the creation or update of a ContentType. The solution is therefore to deliver a custom SharePoint application page via which the WebForms functional manager can afterwards fix the InfoPath modified ContentType. He/she selects in the dropdown the ContentType that [potentially] needs a cleanup. The custom application page then inspects
   the FieldLinks in the ContentType for duplicate occurences, and removes each one found. The changes (deletions) in the SiteCollection ContentType are propagated to all childs. Also each duplicate detected FieldLink is removed from the Fields collection of each SPDocumentLibrary that is associated with the selected InfoPath ContentType (code snippet).
   

   
   

Handling save conflict within SPList EventReceiver

Background

Publishing an InfoPath form to a SharePoint site creates a new contenttype in the site. Via the InfoPath publishing wizard you have some control over the structure of the created contenttype. But in essence the control is very limited when compared with explicitly provision a contenttype yourself [see also previous post Administrate data from InfoPath form in a self-provisioned ContentType for further explanation why I prefer this above the automatic created information architecture entities]. However, it is not always possible or viable to explicit provision the InfoPath utilized IA entities. The big selling point of InfoPath is that it enables self-service (web)form-definition by functional management. A key cornerstone in this self-services proces is the InfoPath publishing functionality to allow functional managers to themselves distribute the InfoPath forms to a SharePoint site.
One of the aspects missing with the InfoPath publishing managed contenttypes is including the InfoPath promoted fields in the display form. Displaying all InfoPath form fields is in particular handy when quickly browsing the data submitted to a SharePoint forms library.

Solution approach

To fix the functional shortcoming requires to afterwards make the promoted fields displayed. This is not something you want to burden the functional managers with. The aim is therefore to execute it automatically in the context of the target SharePoint site. The ideal moment would be when the InfoPath managed contenttype is created or updated. SharePoint however does not provide an eventreceiver for these events. The next best moment is when the contenttype is associated with the forms library to which the InfoPath form data is submitted. Here you neither have a direct event notifying the contentype association. But you can receive indirect notification via SPListEventReceiver::FieldAdded. The idea is then to check each added field whether it is an InfoPath promoted field, and if so to alter its definition so that the field will appear in the standard SharePoint display form.

Issues encountered

So, easily said and done. Associate the custom ListTemplate with a SPListEventReceiver, and fill in the FieldAdded method. In my local development image it worked like a charm: after you associate via the SharePoint GUI a document library with an InfoPath contenttype, all promoted fields of that contenttype appear in the document library display form. But after deploying to the central SharePoint development farm, I ran into the first issue. Upon associating a library with a contenttype, SharePoint faulted with a weird message: The specified program requires a newer version of Windows.

Despite this misleading error message, it was immediate clear that the issue was caused by the custom FieldAdded eventhandler:

Apparently, SharePoint does not allow to update a list field in the runtime context of that field being added to a list.

Solution outline

Solution is to isolate the execution of the field-update from the field-addition runtime context. Instead of direct updating the field, schedule this work via a worker thread. One extra aspect to take into account is that the scheduled worker threads can still run into a parallel update conflict:

Save Conflict

Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes.

  at Microsoft.SharePoint.Library.SPRequest.UpdateField(
        String bstrUrl,String bstrListName, String bstrXML)
  at Microsoft.SharePoint.SPField.UpdateCore(Boolean bToggleSealed)
  at Microsoft.SharePoint.SPField.Update()
  at WebformulierFieldsHandler.Worker.b__1()
 

The likelihood of these save conflicts increases with the number of promoted fields in the contenttype, and can already manifest itself when that number is 4 to 5. It can be made functional robust by implementing a retry mechanism in the worker thread.

What about the competition - new roadmap for SAP NetWeaver Portal

As a SharePoint adept, I don't really consider the SAP Enterprise Portal as competition. Let's face it, the typical UI is horrible, and it lacks many of the capabilities the SharePoint platform brings. But moreover, the impression [within the market] is that SAP has stopped with actual new major developments in this product (Web2.0, content management, social media). SAP is putting it's intellectual resources and budget mainly on the business capabilities, and less on fancy user interaction. Fair enough, as it leaves room for integration and interoperability via foreign UIs, as SharePoint.

Contradicting the above, it's knownable that at SAPPHIRE some new additions for SAP NetWeaver Portal were announced. Most notable the concept of 'Enterprise Workspaces'. Read and see more of this in SAP NetWeaver Portal – SAPPHIRE NOW Summary.

It aims to provide SAP users with an iGoogle- or myYahoo-type experience within SAP, allowing them to build their own pages with structured and unstructured assets -- reports, RSS feeds and so on. It applies a self-service approach within defined roles and security. [SAP NetWeaver Portal roadmap includes 'Workspaces,' easier third-party integration]

Well, the UI impressions and the self-service concepts are rather impressive and promising. I do hold on to my opinion that SharePoint is a better overall portal platform. But it looks as if SAP could be making a new step forward in its own portal product.

Standards-Based Interoperability between SAP NetWeaver 7.0 and Microsoft .NET 3.5/4.0

Microsoft opened a new interoperability area within MSDN on Web Service Interoperability between the major web services vendors. Amongst these naturally also SAP. The site contains an extensive (75 pages) Demonstration Scenario of the Collaboration Technology Support Center addressing information about how to set up standards-based Web services communication between Microsoft .NET Framework applications and SAP Application Server ABAP-based consumers and providers.

Portal Embedding of SAP UWL into SharePoint

There are multiple alternatives for utilizing SharePoint as presentation layer to SAP functionality. The most basic is portal launch, next comes portal embedding. Portal embedding has some advantages (mainly being rapidly to achieve: you only visually integrate the 2 [SAP, Microsoft] environments, without any direct systems/applications integration and interoperability), but remains a rather poor man's approach to portal integration. The typical SAP UI / Look and Feel is very different from the SharePoint UI (standard or company-customized), and the SAP Portal pages exhibit themselves browser navigation in addition to the SharePoint navigation.

Andre Fischer a.o. from SAP recently published the whitepaper Integration of SAP Universal Worklist into Microsoft Office SharePoint. This paper contains an example of the portal embedding approach, while also addressing the double navigation issue. In particular it describes an approach to integrating the SAP Universal Worklist into SharePoint context. Basically it comes down at making sure at the SAP Portal side that the portal pages are rendered headerless, without the portal navigation. The elegance of the sketched approach is that it is limited to SAP Portal configuration and customization work, there is no custom development required at either SAP nor SharePoint side.

SharePoint 2010 CMIS Connector

To enable content management interoperability between different CMS repositories, the OASIS organization defined the Content Management Interoperability Standard specification. Although a.o. Microsoft played a major role in the OASIS working group defining this proposed standard, up to now it did not provide a concrete and product-ready implementation of the CMIS specification for SharePoint 2007. There is only a reference/example implementation available on MSDN, with code download.

Apparently Microsoft decided to wait with active support of the CMIS specification for the next SharePoint version. For SharePoint Server 2010 Microsoft now packages a CMIS connector as part of the Administration Toolkit v1.0. The CMIS Connector for SharePoint provides a CMIS (Content Management Interoperability Services) interface over the top of SharePoint as well as a CMIS consumer Web Part that can be used to display content from other CMIS enabled repositories. [source: Microsoft SharePoint Teamblog] Or stated otherwise: via this CMIS Connector, SharePoint Server 2010 can both function as CMIS consumer of content stored in external repositories, and as CMIS producer of content stored within SharePoint lists and libraries.

Mind you...

• the CMIS Connector is not supported for SharePoint Foundation 2010
• and there is still only limited support of the CMIS standard by other CMS vendors; the real value of CMIS requires [at least] 2 to tango...

Beware: timerjob processes invoked via Central Admin deploy solution do not reload FeatureReceiver assembly

Recent we ran into an exception when deploying an external facing website to the production SharePoint farm. The problem originated in the FeatureInstalled() method of a custom FeatureReceiver class. We did not encounter this particular deployment problem in the integration nor QA environment. Since on a production environment it is not viable to debug, we had to resort to inserting logging statements in the code, and then redeploy the assembly. But strangely, no logging was written leaving us still blank with respect to the exact code location and cause of the deployment problem.

After several deployment attempts together with operations, we came up with the explanation why the logging was not done. The timerjob process that executes the FeatureReceiver FeatureInstalled() method still has the old code loaded!! To force that the assembly is reloaded from either GAC or virtual bin after deploySolution and before execution of FeatureInstalled, you need to recycle the timerjobs processes. The right time for this is after the retractSolution of the previous version of the deployed SharePoint solution package.

NB: we didn't notice this 'faulty' deploy/timerjobs behaviour before because it's not very common to actually utilize the FeatureInstalled() method. In this particular case it was necessary to timely correct something before the SharePoint feature framework performs the OOTB feature activation work.

Duet® Enterprise on stage at SAPPHIRE 2010

Duet® Enterprise is now clearly gaining momentum in the marketspace. It was also on the agenda of the SAPPHIRE 2010 Conference. Watch the session presented by Pascal Gilbert (Microsoft). In this presentation Pascal discusses at a conceptual level the business proposition of Duet® Enterprise, enlists in what aspects it is an improvement of the previous Duet versions, and gives a real life example of how Duet Enterprise can be put in sensible action applying strictly the OOTB provided capabilities.

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.

White paper discussing the promise of Duet® Enterprise

CITO Research has published The Business Value of Duet Enterprise, a research white paper sponsored by Microsoft. Such sponsorship always contains the risk of the result being more of an advertorial instead of an independent and thorough analysis + evaluation. This paper at locations certainly qualifies as unconditional product promotion, but it also presents several useful insights and details on the mission and capabilities of Duet Enterprise.

The paper discussions the mission and values of Duet® Enterprise from different viewpoints and angles:

• [as it should be] Starts with the business vision; the why
• the architecture and interoperability approach; the how at high level
• examples of what can be achieved; use cases
• the components of the Duet Enterprise foundation; it's building blocks for composing applications that surface SAP line-of-business content and processes in user interface formats tailored to the needs of the nowadays Information Workers
• the personality of composites that are best realized via either Duet Enterprise, Business Connectivity Services, or rather BizTalk; choosing the right interop tool for the task/scenario at hand

Some of the most noticable points to take from the paper are:

1. The statement that although Duet® Enterprise relies on SAP NetWeaver 7.02; it can handle scenario's where a company's SAP environment consists of many generations of SAP applications. From SAP R3 4.6C to SAP ERP 6.0 and beyond.
2. Duet® Enterprise is SAP / MS interoperability foundation; for rapid development and construction of custom applications
3. Duet® Enterprise enables the rapid development approach by providing the needed interop plumping
4. Duet® Enterprise builds on existing investments in SAP [business applications + architecture] and Microsoft [Information Worker] software.
5. Duet® Enterprise fits in with existing modern IT management, development processes and environment/technologies.
6. Duet® Enterprise is one way for realizing the vision of Office Business Applications when it concerns connecting with SAP line-of-business.

Missing in the paper is a thorough consideration of the strengths versus weaknesses; of the product and of the proposition itself. With respect to that, Duet® Enterprise could be seen as a threat to some of the SAP business. Although it's promise is to extend the reach of SAP business capabilities beyond its traditional usage and departments, it does so via Microsoft instead of SAP software. It will be interesting to watch hows this develops, and what it will mean for the business of both SAP as Microsoft. Ideally, both will prospher from it. Only then, the combined effort will truly deliver, and have a future.

Claims-based SSO with SAML 2.0

On SAP Community Network the presentation Next Generation SSO for SAP Applications with SAML 2.0 is published containing an overview about authentication, single sign-on (SSO), and identity federation for SAP centric applications. Combined with the recent release of Microsoft's Claims-Based identity platform (Windows Identity Foundation, formerly known as Geneva), and IBM enabling Identity Federation via its WebSphere Application Server (Identity federation using SAML and WebSphere software); 3 of the largest software companies are taking significant steps on this requisite for the interoperability puzzle. Of the remaining other large software companies, Oracle has an handle to the OpenSSO product via the SUN acquisition. But doubt rises about the willingness and commitment of Oracle to OpenSSO - a first sign of this is demonstrated by some broken links to OpenSSO information. From the Google camp I yet miss notion of their plans and products on the Claims-Based Identity subject. I expect that it will either originate from the Open Source community, or donate to it. Who knows, perhaps Google (allthough IBM is a more likely candidate) would be the ideal new founder for OpenSSO...

Unable to recover from a corrupted Publishing infrastructure

For a functional extension to the intranet (enterprise portal) of a client organization, we needed to provision a content page to an existing site. A precondition is thus that the Publishing infrastructure is activated within the context of that SharePoint site: at Site level (PublishingSite feature) and Web (PublishingWeb feature). Upon activating the latter we encountered the following error: Provisioning did not succeed. Details: Failed to create the 'Pages' library. OriginalException: The feature failed to activate because a list at 'Pages' already exists in this site. Delete or rename the list and try activating the feature again.

Strangly enough: via the SharePoint GUI the Pages library was not visible. Could be that it was set to hidden. But trying to directly navigate via its url merely resulted in a NotFound. Upon opening the site collection in SharePoint Designer, it showed there was a left-over of the Pages library: merely an empty folder, no Forms nor other content. But this presence was in the way of activating the Publishing feature. So we deleted this folder via SPD. And then tried to activate PublishingWeb feature again. This time it progressed a bit further, to stop with the message: The page you selected contains a list that does not exist. It may have been deleted by another user. Inspecting again: the Pages library was correctly available now, including associations with PublishingPage contenttypes. Missing this time was the Style Library documentlibrary. That is, when inspecting via SharePoint GUI. Again looking at filesystem level via SharePoint designer: same situation, Style Library folder present, but empty. Deleted this folder, and retried to activate the PublishingWeb feature. Sadly we kept on running into the error of missing List. Even after manually adding the Style Library; forcefully deactivate and re-activate the PublishingWeb feature. We did not manage to recover from the initial corrupted situation wrt Pages list. Search results on the Web for information on both the error messages gave some hits to problem descriptions, but sadly not to resolutions.

Due to a pressing time schedule, we therefore had to resort to a pragmatic alternative. Deleting the corrupted site collection, and re-creating it. This was a viable approach due to the current nature of the site collection: containing no content yet. But it leaves me with somewhat of a frustrated / disappointed mind. I would rather have seen us able to recover from the incorrect situation, while preserving the site collection.

A Technical Overview of Duet Enterprise for Microsoft SharePoint and SAP

On the Duet Enterprise Team Blog an article is published discussing on high-level the technical architecture of Duet Enterprise, the positioning within a mixed SAP and Microsoft landscape, and the required products versions within these landscapes: SAP NetWeaver 7.02 together with SharePoint Server 2010 Enterprise Edition.

A perspective from within SAP AG on Duet Enterprise

Up until now, most news on and attention given to the new Duet Enterprise proposition seemed to come from Microsoft only; leaving SAP AG rather silent on this subject. I am therefore pleased with a first concrete signal from SAP commenting and committing onto Duet Enterprise. Somya Kapoor from the Duet Enterprise Solution Management Team at SAP recently shared some thoughts from within SAP on the Duet Enterprise proposition.

Some noticable statements in this short interview:

• "Duet Enterprise is primarily focussed on integrating SAP and SharePoint - as opposed with Duet which focussed on integrating SAP and Microsoft Office"
• "We [SAP] are aiming at customers who have SharePoint deployments, or experiences with it;
• "We [SAP] want to bring the collaboration expertise of SharePoint into the SAP business processes in the back-end.

A compact overview of SSO Technologies supported by SAP NetWeaver for surfacing from .NET based clients

Earlier I blogged some about the area of Single Sign-On in a mixed SAP NetWeaver – Microsoft .NET world. Yesterday Andre Fischer from SAP AG published an up-to-date compact overview on this topic. Recommended reading for those interested in SAP / MS interoperability.

Efficient batch deletion from SharePoint List without filling up the site RecycleBin

For a data management function I need a performant way to first delete all items from a SharePoint list, before re-filling it with up-to-date content. Looping through the list and delete each item one-by-one is not acceptable. It would instantiate an internal SPRequest object for each single listitem deletion, and take a longer time to complete. The answer to do it time-efficient is to use the SPWeb method ProcessBatchData(). You feed this method with a batch string of multiple delete commands to perform in a single SharePoint request.

However, usage of ProcessBatchData has the disadvantage that all deleted items are put in the SharePoint SPSite Recycle Bin. Kinda ridiculous for a programmatic batch-based deletion. And because of the larger number of deleted items (the reason for doing the deletion batch-based...), it makes the Recycle Bin pretty much unworkable thus useless for UI initiated restore of manual deleted content items.

SharePoint does not provide an elegant way to prevent this standard behaviour. Elsewhere on the web it is suggested to temporarily disable the Recycle Bin at SPWebApplication level. This however suffers from 2 drawbacks:

1. The current user needs to have the SPFarm administrator role. This is unlikely for a functional management role, and unacceptable from a security viewpoint.
2. Disabling the Recycle Bin at webapplication level has a nasty side-effect. It namely clears all Recycle Bins in the webapplication. Not only that of your current context site and sitecollection, but all of them in the webapplication. This effectively destroys the Recycle Bin backup-purpose for manual deleted items; and it is thus not isolated to your scope but affects the entire webapplication. This is functional unacceptable.

So if it's not possible to prevent the batch deleted items from appearing in the Recycle Bin, it is then required to delete them there afterwards. This could be done via a call to SPContext.Current.Web.RecycleBin.DeleteAll(). But this clears the entire Recycle Bin, still potential removing too much. What we need is an approach to delete exactly those items from the Recycle Bin that were put there as result of the list batch-deletion. The Recycle Bin has a different API interface as regular SharePoint lists. Usage of ProcessBatchData to delete the same relevant items from the Recycle Bin is not possible. But it is undesirable to first clear the SharePoint list via a batch-deletion, and next be forced to loop-based remove the same items from the Recycle Bin. Luckily the SPRecycleBinItemCollection class exposes its own method to issue a batch deletion: SPRecycleBinItemCollection.Delete(GUID[]). It has a different method signature, which requires you to first determine the GUID per SPRecycleBinItem. Also you must take care of keeping the chunck of deletion below a thresshold. SharePoint namely locks the database tables when executing the Recycle Bin batch deletion, which hangs the SharePoint server upon deleting a larger set. The Recycle Bin cleanup/reset can be done asynchronous in the background, doing it chunk based.

The code for efficient batch deletion all items of a list, and next clear the same deleted items from the Recycle Bin is as follows:

1. Control for time-efficient purge all items from SharePoint List

2. Cleanup the Recycle Bin in the background

Beware: usage of ImageButton can cause a 401 NotAuthorized in external facing site

In one of our custom webparts we are using the ASP.NET ImageButton class. Instead of setting the image-source via the ImageUrl property, we specify the image via CSS. All works fine. That is, until we "got anonymous". Suddenly when browsing to a page with our WebPart on it, the (acceptance test) end-user was confronted with the IE loginbox. Via Fiddler (how I love this http debugging tool) I quickly detected the indirect cause: IE issued an HTTP GET for the URL of the Pages document library. In an authenticated mode this will pass unnoticed. But for an anonymous user the particular HTTP GET will result in a 401 NotAuthorized on trying to directly access the Pages folder URL.

So the next question was what caused the browser to issue this request for the Pages URL? Well, this was the direct result of our on intention lack of setting the ImageUrl property, in favor of flexible CSS specification. The resulting HTML is then something like:

<input type="image" name=" ... " class="ImgClass" src="" ... />

IE (6) browsers interpretate the empty image-src attribute as referring to the relative root of the webpage. In our case with the WebPart placed on a publishing page, this translates to a request for the Pages folder URL. FireFox and Chrome do not exhibit this behavior, they simple ignore the empty source attribute as it should. The solution for preventing IE to request the NotAuthorized Pages URL is to set a non-empty value for the ImageUrl property. It’s not even required to point to an existent image file. In that case the HTTP request will silently result in a 404 NotFound HTTP response. And since the image is set via CSS, the visual effect in the UI remains unnoticed for the end-user. I dislike polluting the HTTP transfer between browser and server with requests which are known before to fail. Therefore I point to ImageUrl to the current and available image-file. Via CSS it is then still possible to later flexible modify the displayed image.

FormsService SSP in farm holds on to previous version of Feature re-deployed InfoPath Form

Earlier I blogged about the ALM manner to develop and deploy InfoPath forms. One major benefit of this approach is that the InfoPath forms are considered as first-class source artifacts in the development environment and project, just as ‘regular’ source code (C#, XML, .js, css). An even bigger benefit is upon deployment: no need for manual actions to publish the form templates to your deployed and provisioned SharePoint application, it’s all done automatic in the context of a feature activation.

SharePoint out-of-the-box provides the XsnFeatureReceiver class to provide the InfoPath Form Templates publishing support. However, the functionality of this standard class is not enough for real-life deployment scenarios. I ran into a few missing parts before, which I handled by extending and augmenting the XsnFeatureReceiver class. This week I was confronted with another issue. After a re-deployment with updated InfoPath forms, the earlier deployed forms were still active. That is, when opening them in the browser. When opening in InfoPath client, the new version was applied. Thus the deployment to SharePoint server was performed, but somehow for InfoPath Forms Services context the earlier deployed version per InfoPath form remained active. I did not experience this effect in my local single-server local development image. But when doing a re-deployment to the distributed test farm-environment, the issue manifests itself.

I inspected the managed forms templates administration of the FormsService SSP, and discovered that still the initial deployed versions were administered. And after uninstalling the InfoPathInfrastructure feature, the InfoPath form templates in FormsService were not cleared. This obstructs the activation of the new versions of the forms upon re-deployment. As solution I extended my InfoPathInfrastructure feature to also make sure the InfoPath forms that it installed, are removed from the FormsService SSP upon uninstalling the feature.

With this fix, I’m able to deploy and activate new versions of the InfoPath forms to the distributed target SharePoint farm environment (test, staging, production) for usage via InfoPath Forms Services. And still conform ALM principles.

SharePoint [2010] as development, composition + application platform

I consider SharePoint having 2 distinct faces:

1. It's in itself an application, with lot's of end-user oriented functionality. This is true for the foundation WSS, and significant more for the licensed version MOSS 2007
2. It's a rich development and runtime application platform, to host your own custom developed applications.

Being primarily development-oriented, it will be clear that personally I like SharePoint best for the second role.

I'm not alone on this. More and more custom company-internal applications are based on and within the SharePoint platform. SharePoint comes out-of-the-box with a well-filled toolbox of both technical as functional building blocks. Developing custom SharePoint applications is therefore a combination of composing and customizing OOTB SharePoint building blocks, and augmenting it with custom developed functionality in which the SharePoint platform does not standard delivers. This implies a significant mindset switch for [old-school] application developers. Instead of the default decision to custom build all application parts, the SharePoint best-practice approach is to first consider the OOTB building blocks. Can you deliver the custom-requested functionality on sufficient level via the application of the standard SharePoint blocks? If so, choose that path. This composition-based approach will gain you in the initial application development stage. But even more it will be cost-benificial within the application maintenance period. It's better to have Microsoft fix and improve on standard building blocks, than have to do it yourself on your own proprietary ones. Of course, this principle can especially be applied on the more technical functionalities. And this gives you more time and relative budget to focus on the differential functionality for your company.

David Chappell has written a conceptual white paper highlighting the application platform aspects of the forthcoming SharePoint 2010. You can download it on the Microsoft site, SharePoint 2010: Developer Platform White Paper.

AllUsersWebPart and SPWebApplication.ApplyWebConfigModifications don't match

• In a Feature, I apply the AllUsersWebPart construct to automatically add default webparts to all publishing pages based on the PageLayout File.
• In a Feature, I utilize the SPWebConfigModification class to add web.config modifications

When done in separate Features, both constructs operate successfully. However, when included within the same Feature activation, the invocation of ApplyWebConfigModifications method results in a SecurityException:

Access Denied
at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at Microsoft.SharePoint.Administration.SPWebApplication.ApplyWebConfigModifications()
at Microsoft.SharePoint.Administration.SPWebService.ApplyWebConfigModifications()

It looks as if internally SharePoint somehow puts a lock on the Administration persistent object. I tried to verify my suspicion via Reflector, but not surprisingly this internal code is obfuscated. The runtime error only manifests itself when the Feature is (re)activated via the GUI. The Feature activation via stsadm reports no problem, and successfully performs the deployment work.

Still, I want to hold on to the idea of one single self-contained Feature to deploy all the required parts. And I want to be able to turn the Feature on and off interactively via the SharePoint GUI (so that I can also operate the feature remote, without access to the deployment server). A resolution is to apply another approach to provision the default webparts on the pagelayouts. Besides the usage of AllUsersWebPart, it is also possible to directly include the webpart specifications in the PageLayout file itself:

With this construction, the invocation of SPWebApplication.ApplyWebConfigModifications method is done successfully. And as a bonus, also another problem is prevented; that of magically duplicating the default webparts provisioned via AllUsersWebPart upon Feature re-activation.

A final word of caution. With this approach I at first encountered another problem. When editing on a created publishing page the properties of the default WebPart provisioned via the PageLayout file, SharePoint displayed an error warning in the edit toolpane, "a web part you attempted to change is either invalid or has been removed by another user". Although the net effect of the WebPart settings is simple done, this is not very trustwordy towards the Web Content Manager. Hard to explain that they can just ignore this warning. Before deciding to then have to abandon the approach, I re-examed the default WebPart specification in the PageLayout file to see if anything there could be causing SharePoint to suspect a concurrent update. And yes there was, 'thanx' to the automatic editing behaviour of Visual Studio. When you add a control within an .aspx file, Visual Studio automatically add a default 'ID' property to the control. For the default WebPart however this is not needed, the property is actually set when creating a publishing page off this PageLayout. But the mere presence of it in the default part results in SharePoint detecting a concurrent update. So remember to don't include the 'ID' property within WebPart specifications included within PageLayout files.