A quick example of using the Between function for the Dynamics 365 Web API.
$filter=Microsoft.Dynamics.CRM.Between(PropertyName='createdon',PropertyValues=["2017-01-01T00:00:01Z","2017-04-30T23:59:00Z"]) and statecode eq 0
- The dates need to be defined in UTC format to ensure quality of the data returned. It can be specified as “mm/dd/yyy” but this may be confusing if you are operating in non-US date formats.
- The Functions can be combined with your other standard filters e.g. statecode eq 0.
I have found Postman to be a very useful tool for testing Web Api’s, but according to Postman’s documentation, sending certain restricted headers can be an issue. Using Postman Interceptor allows you to overcome this restriction but I came across one problem when setting the restricted Date header.
I had been using the Pre-requests scripts to set the Date dynamically using environment variables, again following the documentation. However, each time I submitted the request my Date header was coming through as null. The problem turned out to be the date format as this needs to be in GMT format and fortunately the fix turned out to be relatively simple.
Here is the scenario:
- .NET Web Api running on an IIS Server (8.5 – although the problem was recreated on 7.5 too)
- v4.0 Integrated Application Pool with a domain account identity.
- Only Windows Authentication is enabled. No anonymous access is allowed.
- Making requests to the Web Api works in the following configuration:
- Using a different domain account to the one used by the Application Pool AND
- From a different machine and using a browser or the Invoke-RestMethod PowerShell command
- Making requests to the Web Api does not work in the this configuration and results in a 401:Unauthorized error being displayed.
- Using a different domain account from the same server OR
- Using the same domain account to the one used by the Application Pool AND
- From either the same or different machine, using a browser or the Invole-RestMethod PowerShell command
The problem was that a Schedueld Job, created as a PowerShell script, was being run from the same server and the Invoke-RestMethod was generating the 401:Unauthorized error.
The solution was to set the relevant Service Principle Names for the IIS Server, but instead of doing it for the specific domain user account it was configured for the server. This included SPN’s for the computers NetBIOS name and the FQDN as well as the host name of the Web Api.
This post just covers a few useful things I have found while I have been developing an ASP.NET Web API that uses AttributeRouting for Web API and ELMAH for Web API.
I found AttributeRouting much easier to configure and administer than using MapHttpRoute in the WebApiConfig.cs file; especially using the RoutePrefix at the controller level. Running tests on the attributes using the Route.axd was also very straight forward. I also found Fiddler (v18.104.22.168) to be very helpful in throwing different unit tests at my newly created web API. This is simple and powerful configuration that works straight out of the box.
Using the Elmah.Contrib.WebApi took a little more configuring to get working but I found a good place to start, after you had installed the NuGet packge was on the sample web.config page. This provides detailed examples of the configuration settings needed for the different types of log stores as well the basic settings for the different flavours of IIS. There were a couple of additional tweaks I would recommend:
- Since I am not generating any View I removed the
filters.Add(new HandleErrorAttribute()); in the FilterConfig. The HandleErrorAttribute to serve up a View called Error. Since this is a Web API project and I don’t have any Views then it wasn’t needed.
- Instead, there is a rather neat process for capturing unhandled errors that I found here.
- Finally, if you are using a simple XML file to store your errors you need to make sure that the security configuration is correct for the folder where the files will be generated and stored. For example, I had my files stored in the App_Data folder under the root of the web site on IIS 7.5. The application pool for this site was running under the ApplicationPoolIdentity account and so this account needed to have write permissions to the App_Data folder. Instructions for doing this can be found here under the Securing Resources section of the article.