Resolving Http 405 – Method not Allowed

I have an API App named the StorageConnector. After adding a new method named CheckIfAGABeoordeling, I suddenly got a Http 405 – Method Not Allowed error on another methode in the StorageConnector, being DeleteAGABijlage.

I first tried to add a Http Header Allow when calling DeleteAGABijlage, but that didn’t work:
Header Allow: DELETE

Next I started searching on the Internet and found it could potentially be a routing issue. Below are the relevant method signatures and a snippet from the webapi.config:

[box type=”info”]

public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// Web API configuration and services
config.Formatters.Insert(0, new TextMediaTypeFormatter());

// Web API routes
config.MapHttpAttributeRoutes();

config.Routes.MapHttpRoute(
name: “DefaultApi”,
routeTemplate: “api/{controller}/{action}/{id}”,
defaults: new { id = RouteParameter.Optional }
);

[SwaggerOperation(“GetObjectData”)]
[HttpGet]
//[ActionName(“GetObjectData”)]
[Route(“api/Storage/{objectName}/{objectId}”)]
public HttpResponseMessage GetObjectData(string objectName, string objectId)

[SwaggerOperation(“CheckIfAGABeoordeling”)]
[HttpGet]
//[ActionName(“CheckIfAGABeoordeling”)]
[Route(“api/Storage/{errorMessage}”)]
public HttpResponseMessage CheckIfAGABeoordeling(string errorMessage)

[SwaggerOperation(“DeleteAGABijlage”)]
[HttpDelete]
[ActionName(“DeleteAGABijlage”)]
//[Route(“api/Storage/AGABijlage/{integrationId}”)]
public HttpResponseMessage DeleteAGABijlage(string integrationId, string documentId, string formCode)

[/box]

[box type=”info”] A Http 405 error can be caused by a routing issue. [/box]

As you can see, it’s quite a mess. Sometimes routes are taken from the webapi.config, sometimes routes are taken from the method signature. Also, the routing template in the webapi.config is not very pretty. Take for example the variable {action}, which does in fact not refer to the ActionName. Confusing. Anyhow, I tried different things, like adding the action name to CheckIfAGABeoordeling, but I couldn’t get it to work. I was also a bit afraid to make changes to solve this particular issue and then create other issues.

So, what I did next, is change the method CheckIfAGABeoordeling to a private method. I renamed the method to ResumeAfterFailure. Next I called the method from GetObjectData.

private bool ResumeAfterFailure(string context, string errorMessage)

public HttpResponseMessage GetObjectData(string objectName, string objectId)
{

switch (objectName)
{
case “AGABeoordeling”:
bool result = ResumeAfterFailure(objectName, objectId);
if (result)
response = this.Request.CreateResponse(HttpStatusCode.OK);
else
response = this.Request.CreateResponse(HttpStatusCode.InternalServerError);
break;

I now made the following call from my Logic App:
https://tstahakstorageconnector.azurewebsites.net/api/Storage/AGABeoordeling/Opdracht%20LIA-006003782985%20heeft%20niet%20de%20correcte%20status%20voor%20bericht%20met%20type%20AGA.%20Huidige%20status%3A%20AGAssets%20goedkeuring%20verzonden

Unfortunately I received a Http 404 error this time: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable. I opened a browser and entered the address to get the same result. Than I started experimenting a bit and found out that the error message after AGABeoordeling contained ‘.’ and ‘:’. Those characters caused the issue. After adding replace functions to my logic app, I finally received successful calls.

https://@encodeURIComponent(parameters(‘storageConnectorName’)).azurewebsites.net/api/Storage/@encodeURIComponent(‘AGABeoordeling’)/@encodeURIComponent(replace(replace(body(‘PostAGAssets’),’.’,”),’:’,”))

[box type=”success”] A Http 404 error can be caused by invalid characters in your URL like . or : [/box]

Routing failures in BizTalk

Om fouten op een nette manier af te handelen, kan de optie ‘Enable routing for failed messages’ worden aangezet. Het effect hiervan is dat er ErrorReport properties worden gepromote, waarop je je vervolgens kunt abonneren. Dit voorkomt het ontstaan van suspended messages in de BizTalk Administration Console.

Routing failures zijn een speciaal geval. In geval van routing failures ontstaan er twee suspended instances:

  • Een resumable instance with error code 0xc0c016a2.
  • Een non-resumable routing failure report met errorcode 0xC0C01B4e. De context properties van het routing failure report kunnen worden gebruikt voor trouble shooting. Toelichting: The routing failure report is literally a dummy message associated with a dummy instance. The only really interesting part to this message is the context. This is the context of the message which failed to route at the time of the routing failure.

Als je een error handling orchestration maakt met subscription ‘ErrorReport.FailureCode exists’, dan wordt de resumable instance opgepakt. De non-resumable routing failure report blijft echter staan. Probleem is ten eerste dat ik het via Powershell niet voor mekaar krijg om de context van het routing failure report op te halen. De context moet je immers ophalen als property van de message instance en bij routing failure reports is er geen message instance voorhanden.

Een tweede probleem is, dat de routing failure reports zonder handmatige actie in de BizTalk Administration Console blijven staan. Dit heeft een negatieve impact op de performance. Voor het automatisch opschonen van routing failure reports, kun je de volgende link als uitgangspunt nemen: http://msdn.microsoft.com/en-us/library/bb203857.aspx. Het sample script kan worden aangepast, zodat alle routing failure reports worden opgeschoond.