Workaround for 401 problem with POST and NTLM authentication

Context: Invoke SharePoint Lists.asmx webservice from a WPF client to retrieve listitems. The SharePoint site is hosted by an external provider, and secured via NTLM authentication. To invoke the Lists webservice a WCF proxy is generated. The client WCF binding is set to basicHttpBinding, with security = NTLM.

Issue: When invoking the service from the WPF client, a 401 is returned. Via Fiddler inspected the http-request. The NTLM authentication protocol handling in 3-steps is visible, but despite that no succesfull authentication. A simple GET via WebClient to the Lists.asmx page, with same NTLM credentials applied does succeed.
And strangely, in case this is done before sending the POST webrequest, the latter does also succeed. That is..., when Fiddler is active. Without Fiddler monitoring the http transfer, the HTTP-GET request still succeeds, however the WCF proxy call then again fails.

Although I love Fiddler, it's no option to oblige application end-users to run it just to allow the WCF proxy call to succeed...
Instead I tried to implement the SOAP behaviour explicity self via WebClient, and abandon the WCF framework in this particular case. And this works!

N.B. The probable cause of the POST malfunctioning with HttpWebRequest / WCF proxy and NTLM authentication is described in the post 401 Error on HttpWebRequest with NTLM Authentication.

Embrace the New Way of Work

This morning I had an appointment at the headquarters of Microsoft Netherlands, at a location nearby Amsterdam. According to the route planner it ought to take me about an hour and a quart. However, due to a capital traffic jam it took me almost 3 hours (!!) to finally get there. Even despite my build-in marge I thus arrived late for the meeting, and could only attend the last 45 minutes. What a waste of time... Therefore next time we'll value our precious time, and organise via Microsoft Office Live Meeting a virtual and location-independent meeting. Cheers for that...

Tip - HowTo package multiple project-assemblies in a single WPF executable

It's a good practice to structure your Visual Studio solution according to the application layers. You can do that via a folder structure within a single project. But I prefer to structure each application layer within it's own VS project. This approach allows (the build of) each VS project to depend only on the architectural layer direct beneath it.

A consequence of structuring within multiple VS projects, is that each project will build its own assembly file. Often this is also required for deployment and update flexibility. Sometimes however its handier to package it all within a single assembly for deployment. An example is the build of a WPF .exe. Especially for a smaller application, it's a bit overdone to have to deploy one or more .dll assemblies besides the .exe.

Luckily it's easy possible to also package the other project-assemblies within the main .exe executable. The tool to the rescue here is ILMerge. You can modify the project file to automatically merge the dependant .dll assemblies within your main .exe:

<PropertyGroup>
<PostBuildEvent>ILMerge.exe /internalize /ndebug /out:$(TargetFileName) $(TargetFileName) TopForce.Communication.Application.dll TopForce.Communication.Integration.dll</PostBuildEvent>
</PropertyGroup>

Online interview explaining the business case of OBAs in the field of SAP/MS

At Tech-Ed Australia Kristian Kalsing has a session on the subject of OBAs in the field of SAP/MS. He was also interviewed on this subject. In this interview Kristian at first gives a good explanation of the business case of applying SAP / MS integration within the information worker's workplace, typical a non-casual user of the SAP environment. At the end he also gives some solid best practices to apply when starting with SAP / MS interoperability. You can watch the interview online.

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability OBA

Tip - HowTo Enable Anonymous Access to discussion board listview within a public readonly publishing site

For a public exposed website you'll need to enable anonymous access, to allow arbitrair visitors to see the published content, and search crawlers to index your site. You'll also want the site visitors to only be able to view the site contents, not to modify it.

There are some exceptions to this general permission rule. One is when the website contains 1 or more discussion boards. To enable any arbitrair visitor to participate in a discussion thread, she needs update permission rights within the SharePoint DiscussionBoard. In a former project we learned that it's not trivial to enable update rigths for anonymous users in a further readonly publishing SharePoint site. To spare you the time to discover yourself how to still achieve this, I decided to publish here the steps I needed to perform.

1. [Central Admin] create new web app
2. [Central Admin] create a site collection with Publishing Portal as template
3. [Central Admin] extend the web application for internet; and allow Anonymous.
   

   Note: in this stadium still WA allowed at the extended site.

4. [Site itself] open up the extended site; since WA allowed possible to change settings
5. [Site itself] enable anonymous access for entire site
   (site settings \ advanced settings \ settings \ Anonymous Access \ Entire Website)
6. [Central Admin] disable Integrated WA for the extended site to make it totally anonymous
7. [Shell/CMD on SharePoint server] !! toggle the lockdown feature on the extended site; and do either app pool recycle or IIS reset
8. [Site itself] provision a DiscussionBoard, and set its permission to allow anonymous access.
9. [Central Admin] re-enable WA on the extended site
10. [Site itself] allow anonymous access for both viewing and adding items on the discussionboard list
11. [Central Admin] disable again WA

This sequence of steps, and in this exact order, worked out for us. When deviating from it, we still experienced access denied issues; either upon trying to display the discussionboard ListView, or when trying to add a new thread or reply to existing discussion.

See also: Allow anonymous user access to display forms of discussion board list(view)

Tip - Provision a Functional Management page for application data

One of the faces/capabilities of the SharePoint platform is that of Web/Enterprise Content Management System (WCM, ECM). When we architect and setup a WCM-enabled SharePoint (publishing) site, there are actually 2 different types of users to take into consideration:

1. The end-users browsing and using the website;
2. The content managers, who have the responsibity for maintaining the content on the website up-to-date

When designing the website, the primary focus is almost naturally on the end-users. Understandable, after all a site which does not attract and keeps the interest of end-users is in fact useless for the company. However, it certainly is also beneficial to give appropriate attention to the usage model for the content manager role. If they can do their content work in a more user-friendly and efficient manner, the site will most likely benefit from this by being more and more often kept up-to-date. Content management is a task difficult enough on the functional level, without the technical / usage model burden of SharePoint content management.

Content in a publishing website comes in various forms. Most known are of course the publishing / web pages, as the entities to which the end-user navigates. But there are more type of content-entities possible:

• downloadable documents (administered in document libraries)
• pictures displayed somewhere in the site (administered in picture libraries)
• data displayed somewhere in the site. Examples are news items, events calendar, links to related information (administered in SharePoint lists)

When the SharePoint is based on one of the publishing site templates, content management of the individual pages is already to a certain amount enabled for the site contributors. An authorized contributor can start the creation of a new page, or the modification of an existing one directly from the siteactions menu. However, if the contributor needs to change one of the other types of content (document, picture, basic list data), there is no such direct usage model. Instead one has to follow the path of Site Actions --> Site Settings --> List and Libraries --> identify and then select the appropriate list ... This is rather cumbersone, and involves a lot of mouseclicks (irritating) + the retrieval and rendering of multiple application pages before arriving at the final destination (time-costly for the user). Another disadvantage is that the content owner must self identify in the listed overview of all the SharePoint lists and libraries in the current site, the particular list/library which holds the content type.

Wouldn't it be nice to apply a comparable usage model as for page-modification to non-page content items ? I thought so, and have realized it within various SharePoint CMS-projects. The basic usage model is:

1. A contributor selects the Site Actions menu
2. The Site Actions menu is extended with a custom action for functional data management

   
3. The functional data management menu entry navigates the browser to a functional data management page. On this page the different relevant content types are enumerated in list form, with direct recognizable identifications.

   
4. Clicking on one of the content type links navigates the browser to a page on which the data items of the related list are displayed. The contributor can here manage the content of this specific type, for instance news messages.

   

This usage pattern improves the user experience for the content management role:

• The usage model for non-page content applies the same pattern as for publishing page content
• The navigation is direct, and orientated at functional level
• Lesser mouseclicks and page retrievals
• Contributor is shielded of from confrontation with the total collection of SharePoint lists and libraries in the site

At SharePoint technical level the following is done to enable this usage pattern:

1. Entry on Site Actions menu: Provision via a feature a custom action, to add an entry to the Site Actions menu, with it's action set to navigate to functional CMS management page.
2. Functional CMS Management page: Provision a web page with on it a Content Editor webpart (CWEP), and add htlm to render a list of the different content types. Each item in the list hyperlinks to the same edit page for editing the contents of the selected list. The listname is propagated via the QueryString.
3. Editable list view: Provision a second web page with on it a ListView webpart. The ListView webpart is used to display the different items in the SharePoint list or library, and to enter new item or edit existent item. This web page is reused to display the contents of the different content lists and libraries. For this it is required to runtime connect the contained ListView to a specific list or library, following the selection the content manager made from the overview. The ListView webpart itself does not exhibit QueryString behaviour. Therefore a hidden technical webpart is added to the page which parses the QueryString to detect the requested list, and next runtime push this setting onto the ListView webpart on same page.

And that's basically it. Your site's content managers will thank you for delivering this CMS functionality. At least, that has been my experience on several occassions/projects...

Apply WCF BizTalk Adapter Pack to service-enable SAP BAPI/RFC's

One way to expose native SAP BAPI and RFC function modules is by generating a web service within SAP NetWeaver. In some cases this is less appropriate. For starters, you need to have a SAP Developer Key to be allowed to use the SAP web service wizard, and also have the required SAP authorizations. In other cases it may not be allowed by IT operations to make any modification to the SAP environment, even if it's limited to the full-automatic generation and activation of the BAPI webservice(s). Another reason from a system architecture viewpoint, is that the single BAPI and/or RFC calls may be of too low granularity. You actually want to perform a 'business transaction', consisting of multiple method invocations which must be treated as a Logical Unit of Work (LUW). SAP has introduced the concept of SAP Enterprise Services for this, and has delivered a first set of them. This is by far not complete yet, and SAP will augment it the coming years.

The by SAP delivered Enterprise Services will of course be limited to standard SAP functionality. In case of custom functionality you'll need to provide your own 'Enterprise Service' behaviour. This can be done in the SAP environment as a custom BAPI/RFC function module, and then exposed as BAPI webservice. However, another option is to apply the .NET WCF LOB Adapter SDK and the related BizTalk Adapter Pack. The LUW behaviour is then implemented within a .NET class. For transactional update behaviour, the .NET class must invoke BAPI_TRANSACTION_COMMIT at the end in case no problems are encountered, and otherwise BAPI_TRANSACTION_ROLLBACK to rollback all the earlier performed updates in the LUW.

Basic Steps:

1. complement your local development environment:
   i) install the WCF LOB Adapter SDK 2.0
   ii) install the BizTalk Adapter Pack 2.0
   iii) install the SAP RFC SDK
   


2. Generate in VS2005/2008 an 'Adapter Service Reference'; select the SAPbinding, configure the connection to the SAP system and connect, and next select the BAPI's and RFC's function modules that you're going to invoke in your business functionality. Important: if you need to implement a transactional update, also include the BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK function modules.
   


3. Design and implement the client context that applies and invokes the SAP adapter binding.
   

The whitepaper Windows Communication Foundation (WCF) LOB Adapter SDK and the BizTalk Adapter Pack gives the reader a good and thorough insight on the vision and functionality of both. And excellent read for the ones interested in approaches to integrate arbitrair .NET clients (e.g. MOSS) with external Lines of Business application (e.g. SAP HR).

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability WCF LOB Adapter