Blog Post: BizTalk: REST getting nice URLs with IIS Url Rewrite

“Ding ding” after spending 4 rounds(hours) in the ring with this guy, I’m taking the gloves off and heading for the showers and salts.

I’m in the middle of some BizTalk work (which is nice for a change) and I’m ticking my tasks off.

I’ve got a REST receive port exposed from BizTalk via IIS and published through the WCF Publishing Wizard.

(there’s Operations mappings and extracting variables from the URL to Context Properties under the Configure – omitted for brevity)

Couple of shots of the WCF Service Publishing Wizard:

The issue here is that – once the Wizard completes you’ll get:

http://<servername>/coreapi/customer/Service1.svc as the URL to call.

The task was simple:

I wanted to call URLs such as

http://<servername>/coreapi/customer/123456789/enquire

http://<servername>/coreapi/customer/123456789/verify

etc. 

And not their equivalents of:

http://<servername>/coreapi/customer/Service1.svc/123456789/enquire

The Solution was to use IIS URL Rewrite which looks to be the Swiss Army knife that MacGuyver uses.. (but he only needs a paperclip to take out an entire train).

Lots of samples and numerous examples of solutions that work and people are high-fiving in about 5 mins of starting…alas not for me . The other point to note here also is that a URL Rewrite module exists for:

• Default Web Site
• Each IIS Application under the Root Website.

I wanted to keep things confined to just my IIS Application and not have to have requirements of changing the Default Web Site for instance.

The tricky part was to find out how IIS works and it’s matching.

Underneath CoreApi I have Customer as an Application as in

/coreapi/customer

**The part that URL Rewrite appears to do** (that floored me for a while)

It chunks the FULL REQUEST and passes just the part required to your app.

So take the full URL:

http://localhost/coreapi/customer/1234234/enquire

As you traverse down the IIS ‘Application tree’ the URL that is passed to each URL Rewrite in each underlying IIS Application is *different*, as in:

• /coreapi = ‘customer/1234234/enquire’
• /coreapi/customer = ‘1234234/enquire’

This was possibly the hardest piece to figure out. I’d setup failed request tracing in IIS and those logs, while I feel like I’m walking into the Engineering room of the century with all the logs, pages and info… I wasn’t seeing ‘URL Rewrite failed to apply your rule because …..’  - it just wasn’t appearing plain and simple.

URL Rewrite – the rules that won the show

1. Under /coreapi/customer in IIS Manager
2. Started off with a Blank Rule and setup the following:

So the RegEx Rule (at this level) simply states – if the Request begins with a number, then prepend ‘Service1.svc/’ to it.

The key is knowing what the URL being passed to URL Rewrite is at this level in the IIS Application/vdir tree.

What the web.config says at this level:

<rewrite>
           <rules>
               <rule name="CoreApi Rule" patternSyntax="ECMAScript">
                   <match url="([0-9].*)" />
                   <action type="Rewrite" url="Service1.svc/{R:1}" appendQueryString="false" logRewrittenUrl="true" />
               </rule>
           </rules>
       </rewrite>

I hope I’ve saved you a bit of time on your next endeavour.