1) Insight to your problem
I suspect the reason for this error is that the request message is not correctly formed. The configuration looks good.
i.e. It does not have the correct ResolveName and Context in the request, must match that of the Configuration.
I suspect this is because you did not setup the BSDL with a Request Schema Root Element Name and Namespace.
As a result, when you click "Sample Request" (which creates the sample using the BSDL), it will not create a request message that invokes your service.
2)What to do to fix it
Option 1 [recommended] - Populate the BSDL supplying a valid schema name and namespace to match your request.
To do this:
i)From the service pipeline configuration page, select the "View BSDL" for the service.
ii)Near the top of the page, there's a
Service Definition File Path
tag with the path to the service definition next to it.
Open up that file with a text editor, and change the bits in
<?xml version="1.0" encoding="utf-8"?>
<Services xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:au.com.keystroke.serviceDefinition.version_1_0_0_0">
<ServiceProviderName>Keystroke IT Australia</ServiceProviderName>
iii)Save the file & then generate the sample request again.
Option 2[if it all gets too hard] - Create a message manually and paste it into the Generic Request Sender page.
3)Useful background info
3.1) The Service Pipeline Manager runs & looks for matches, caches in hashtable etc.
The ConventionOverConfiguration functionality is simple a handler that runs at the end of the Service Pipeline (configured in the Pipeline) and look for scenarios where there was no Configured match
in the Pipeline for a given request.
Once it detects this, it runs it's rules - Based upon a Convention, to detect whether the request can be handled using the Convention built into the ConventionOverConfiguration handler.
In this case, because the request sent did not match any configuration, the ConventionOverConfiguration handler decided to try & see if there was anything that would match it's convention that could
satisfy this request.
4.1)If you plan to not use the ConventionOverConfiguration feature for a particular instance, you should probably disable it to improve performance, as it will otherwise kick in needlessly.
If you plan to still use it in conjunction with the configured services, then leave it in.
4.2)It's great to hear that you're planning to build lots of services with ESB.NET.
Note that you can write/customize the ConventionOverConfiguration handler to meet your own requirements.
If you have an existing structure that has a rigid convention, then maybe this can be a way to minimize the amount of work you need to do to route the services through ESB.NET.
4.3)With that many services, I suggest you plan your federation strategy. For many reasons, you'd want to group your services into logical namespaces & probably related ESB.NET instances. This will
greatly help with maintenance & overall availability/uptime.
Instances that map to namespaces are a great way to get up & running quickly. Override by re-routing requests [configure in a routing config for that service or request re-mapping if needed on a
large scale etc.] on an as-need basis.
You can also modify the RequestHandlerProxy to have any routing logic conventions/configuration built into it to make life on the server side easier/cleaner if you need to [just keep this option in
your back pocket in case you need it].
4.4)With the services you've got built, you can also look at having an interpreter handler run before/after each of your service to do any generic translation that needs to be done for each service
If you need any more guidance, email me on email@example.com.