Valid XHTML 1.0!

Valid CSS!

Powered by PHP

Get FireFox

1&1 Internet

Archived News

BizTalk WCF-SQL retrieving XML columnWednesday 24th February 2016
I'm currently going through a BizTalk migration project, one of the things to migrate is the SQL Adapter to the newer WCF-SQL adapter.

One of the interesting ideas is dealing with a single XML column from SQL (e.g. a stored message or similar). I stumbled upon Richard Seroter's blog covering the same subject, with a working solution.

Another approach, and the one I've taken is to utilise the same logic behind handling FOR XML SQL queries. In such a query, you get an XML column back, which you'll note is very similar to the requirement above.

This approach is described in the above link, but essentially requires the following steps:

  1. The use of "Procedure" when selecting your procs in the Consume Adapter wizard

  2. Setting the SOAP Action mapping to use "XmlProcedure" instead of "Procedure" in the Port

  3. Setting the WCF binding tab to use XmlPolling (if not done already) and providing an XML Root and Namespace

  4. Setting your result schema (wrapped in whatever you popped in the above step) as the response message type in your Orchestration

This will give you your XML message typed directly into BizTalk. Be aware of qualified/unqualified element default form as the WCF-Adapter will "intelligently" muck about with your namespacing in the result set.

MVC5 Complex model binding with DictionariesTuesday 16th February 2016
There are a few references to Scott Hanselman's blog on model binding. It covers mapping from an HTML form to complex objects in the .NET controller with MVC.

I suspect things have moved on since this was written so I thought I'd point out how much easier it is now.

If you want a Dictionary of complex objects as a result of your form posting (e.g.a multi-record sort of affair) then languages such as PHP offer this up easily with associative arrays. Luckily MVC 5's model binder does a similar job:

Let's consider this C#
public class Company {
public string CompanyName { get; set; }
public bool? Active { get; set; }

public ActionResult UpdateCompany(Dictionary companies) {
foreach(Company c in companies) { ... }
It's a simple enough requirement - so how do we match that up on an HTML form?
<input type="text" name="company[MSFT].CompanyName" value="Microsoft" />
<input type="checkbox" name="company[MSFT].Active" value="true" checked="checked" />
<input type="text" name="company[AAPL].CompanyName" value="Plaaple" />
<input type="checkbox" name="company[AAPL].Active" value="false" />
As you can see, the key for the dictionary entry is used in the markup, this might not be available in run-time, so then we'd just use a standard List, but this pattern is incredibly useful for updating existing records.

Raising HTTP errors from MVC5Monday 8th February 2016
MVC provides a lot of nice friendly ways of doing things, especially around user authorisation and authentication. You can easily mark a section as requiring authorisation and if it fails MVC handles this and takes the client to the logon screen.

But when you start to dig a little into it, things start getting very Microsofty, losing compliance with how the net should work with things like HTTP Status codes.

If you've logged in, but are unauthorised for a certain resource, you should be presented with an 403 error, not a logon screen. You have to implement this logic yourself by overriding the HandleUnauthorizedRequest() of the AuthorizeAttribute and implementing whatever checks you want before triggering some logic to return a 403.

Unfortunately things start to fall apart with IIS and MVC trying to make things easy for you with those confusing "user-friendly" error messages.

I've found the simplest way to handle this is to throw new HttpException(403, "Forbidden"). Then add a relevant <error /> tag into your Web.Config's customError section. I set this to point back to another MVC action that can then set the Response.StatusCode = 403 and returns whatever pretty view I want.

In terms of what happens over the wire, you still get an icky 302 when you try to access the original resource, but the final page you land on brings back with the correct 403 error. This should be fine for most web-clients and crawlers.

Previous Next