SAP Influencer Summit '09 exhibits evidence of the Microsoft connection

Source: The Clear Path Forward for the SAP Super Tanker...

Above blog reports on the SAP Influencer Summit held last week in Boston. At this summit, the mid-term future directions of SAP as IT and solutions company where presented to the audience of 275 analysts and IT influencers.

Noticable in the context of SAP / Microsoft interoperability are the following observations:

• Silverlight was formally named as the user interface surface of choice over Adobe’s Flex, and Sharepoint & Office interoperability is clearly seen as the path forward over that horizon. The dev environment is similarly on the .net side of the ocean.
• Excel and Crystal Reports (and SAP’s Xcelsius) are similarly foundational components to analytics reporting and dashboarding.

Makes me wonder: is SAP finally making a renewed stand on the integration and interoperability of the SAP and Microsoft platforms + products? The fact that noise and attention from SAP on the recently by Microsoft announced DUET Enterprise is yet effectively non-present, is at least confusing with the messages made at the summit. I guess we'll still have to wait and see whether and in which direction(s) the 2 companies will interoperate and partner.

Silverlight and WCF Faults

The WCF FaultContract behaviour is a nice functionality to report functional faults to the invoking client. The WCF service implements this by throwing a FaultException<T> instance. The proxy side catches this, and extracts the functional error.

Well, that's the general idea. With a standard .NET WCF proxy client this works perfectly. However, in Silverlight you ran into some problems. At first, the generic version of FaultException is not available. So you cannot catch and distinguish at WCF client side a FaultException<T>, but must resort to catching generic FaultException. But the real problem is that Silverlight treats all WCF Fault HttpResponse as general CommunicationException iso SOAP FaultResponse. The underlying cause of this is that the WCF service side default sets the HTTP status code to 500 in case of an unhandled exception, even in case of the SOAP FaultException. At Silverlight side (and also Flash) any non-200 HTTP response is generally treated as a communication error. Thereby ignoring/loosing the functional fault information that is responded by the WCF service:

Several posts suggest to prevent this situation by modifying the WCF service side to not return HTTP 500 errorcode for a WCF Fault. This will work if you yourself also have the control over the WCF service. Still, personally I feel this is the wrong approach. The problem is namely at Silverlight side, so you should correct it there. Additional benefit is that you are so also prepared for SOAP faults of external webservices (WCF or other).

My solution would be to implement a custom channel for Silverlight. I thankfully used the example code on this blog for the initial setup. Next I wanted to hook into the proper place in the custom channel to convert 500 HTTP status codes into 200 codes.

However, I've to admit I failed to correct the problem at the Silverlight client side. The reason is that the HTTP transfer is handled up in the stack via inaccessible Silverlight internal clients (System.Net.BrowserHttpRequest, InternalWebRequest, ...), and that all information of the HTTP Response is lost when reaching the context of the channel. Even Reflection cannot give an helping hand here, since the responsestream is closed already when returning to the channel context.

So for now I have to satisfy with letting the own WCF service also return HTTP status code OK (200) when a functional fault is thrown. The bigger drag is the inconsistency in all of this between Silverlight versus standard .NET CLR; in the latter the SOAP response for s:fault is always given priority above the HTTP status code. I think this is as it should be. Moreover given the ongoing discussion what is the correct and standard HTTP status code in case of SOAP FAULT (SOAP and HTTP status codes (200 vs 500 etc), Issue #12: HTTP Status Codes 500 v 200).

Tip - Silverlight's AsyncCallbackException on invoking WCF service

A Silverlight application deployed to the testserver gave a browser error upon invoking a WCF service. This WCF service is running on the same testserver. The error message is:

Error: Unhandled exception in Silverlight2 application [AsyncCallbackException]

According to the callstack, the error occurred somewhere in the completion of the asynchronous WCF call. This makes the bug analysis somewhat trickier, since you cannot simple use System.Windows.Browser.HtmlPage.Window.Alert then. The call completion namely does not run at the UI thread. However, searching around gave me an idea of the problem cause: I forgot to deploy a clientaccesspolicy.xml file within the folder of the deployed WCF service. Copied it there, and the call from the Silverlight client executes successfully.

Silverlight app errors when WCF Contract Has Sync Operations

For a WCF service, it does not matter what type of client is invoking it. .NET, Java, PHP or whatever based, as long has the consumer conforms to the W3* standards. For a WCF proxy however, it does matter what type of .NET client is using it to invoke WCF operations. Although a regular CLR-based client supports both synchronous and asynchronous invocations of the WCF service, a Silverlight client only allows asynchronous operations. In a Proof-of-Concept setup in which I have both a regular WebPart (server side operation) and a Silverlight application (client side operation) hosted in a SharePoint portal, I dealt with this by letting the Silverlight strictly use the asynchronous methods. This worked perfectly in my development environment. However, running at the remote test-server, I get an error indication in the browser when trying to invoke from the Silverligth client an asynchronous method on the WCF proxy. Even although the Silverlight code only uses the asynchronous methods, the Silverlight runtime checks at forehand whether the proxy contract also supports synchronous operations, and if so errors out:

Error: Unhandled Error in Silverlight2 Application [ContractHasSyncOperations]
Arguments:IExpensesHandlingAsync

The quick fix in the PoC is to exclude the synchronous methods when compiling the interface/contract for Silverlight client usage, and included in the .xap package. This can be done through a check on the conditional symbol SILVERLIGHT. This way, it is still possible to code-reuse and share a single interface sourcefile, both for non-Silverlight and Silverlight clients.

Tip - howto retrieve non-required Lookup column via List webservice

When running my deployed Silverlight application on a remote test server, I ran into a runtime problem. Debugging (since I deployed to a remote test server without Visual Studio support, I needed to resort using 'System.Windows.Browser.HtmlPage.Window.Alert'...), I discovered that the cause was a missing column in the returned XElement result of the GetListItemsAsync List webservice call. The missing column is a lookup to information in another list, and non-required. And moreover, this column is not included in the default view (it is in my local development environment, therefore I did not experience the problem earlier). So there's the explanation why it is not included. The solution is to explicitly specify via the ViewFields parameter to include this field in the result. However, even then I did not get the column included (?) The cause of this is that not all items in the list have a value for this non-required field. And for that you have to cope by specifying that the viewfield may be nullable: