“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 startingalas 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.

    Blog Post by: Mick Badran