I'm having trouble sending requests from sample client application to the ESB.NET test service (everything works fine when using the EMC). I get the following response error every time:
ErrorEntry Code="42" Description="No handler configured for request. Successfully created CLR based component but it did not match the service request parameters, so it was not invoked ==>EsbNetTest01.myServiceHandler<== on Server==>D:\Esb\184.108.40.206_x64\Source\ESB\LobSystems\ns\EsbNetTest01\bin\EsbNetTest01.dll<==Component
Server = D:\Esb\220.127.116.11_x64\Source\ESB\LobSystems\ns\EsbNetTest01\bin\EsbNetTest01.dll; Resolve name sought was:ESBEnvelope::urn:keystroke.com.au.esb.envelope.esbEnvelope.version_1_0_6_0; ResolveName from ServiceHandler Attributes was:WfMessage::http://www.wfmc.org/standards/docs/Wf-XML;
Service Version sought was:; Service Version from ServiceHandler Attributes was:18.104.22.168; Context:m_sTransactionComponent=EsbNetTest01.myServiceHandler;Context=EsbNetTest01.myServiceHandler; Handler NOT Invoked by Convention Over Configuration Handler."
Source="ESB.Adaptors.Application.Services.ConventionOverConfig.InvokeViaConvention:InvokeObject. In Assembly:D:\Esb\22.214.171.124_x64\Source\ESB\Base\Solutions\Main\ApplicationAdaptors\ESB.Adaptors.Application.Services.ConventionOverConfig\bin\ESB.Adaptors.Application.Services.ConventionOverConfig.dll"
Can you point me in the right direction?
Jan 21, 2009 at 6:47 PM
The ConventionOverConfiguration handler looks at some attributes on the handler (after locating the actual assembly), to verify the intended handler is being invoked.
You need to change the attributes of the service handler from something like:
to something that matches the payload of your first Document in the Envelope.
In this case, it seems your payload ia another Envelope
so you'd need to change the above attribute to
in order for it to work.
I suspect this is NOT what you actually intended though. Your client-side code seems to be adding another envelope to the Envelope :).
Check the serialized XML to see what's being sent. This can be done by:
2)Using a Network sniffer...
3)Looking at the logs using the ESB.NET Management Console once you've submitted the message [probably easiest at this point I guess].
What you generally want to pass in as the Document is some Business-Level meaningful data.
Hi Minas, thank you for your answer. I have one more question... Does the ESB.NET support the 'Fire and forget' communication?
Jan 22, 2009 at 11:25 AM
Yes it does, but not in the traditional queue on client-side sense.
This is by design. (There is also an interface for completely async. processing, but it's not fully implemented).
The current transports wait for an acknowledgement. As such, it's not completely asynchronous from the client's point of view. It actually waits for the server to respond, saying - YES, I've got your message - and from then on, the processing is asynchronous.
The point of this is to be able to guarantee early, that the server is up, has received the request, and will process it.
It also then frees the client of any state management responsibilities for asynchronous processing.
eg. If something like MSMQ was used client-side, then the client applications would have the additional overhead of managing queues etc.
This setup ensures clients can be fairly lightweight in that respect.
When an ESB.NET server is the client, you can achieve a completely async server request by this same mechanism. Just configure a local instance to process the request, and send the request to that local instance. The local instance can then store the message.
Messages are stored in MSMQ.
In the request payload, set the callSynchronizationType in the header
<address>MSMQ:.\private$\esbclientresponseq</address> (where response is sent...can be another ESB.NET instance URL eg. http://localhost/ESB/Source/CoreInternetTransportAdaptors/Wcf/ESBSoapXmlDocTransport.svc/Default etc.)
2)Server - Pipeline Processing.
If you have a configured service, you can configure multiple handlers. Each of these handlers can be set to run in Parallel to the main Pipeline Request Processing Thread. i.e. Run Async.
(where response is sent...as above...)
- There is currently no retry functionality built-in. This is left to WF Orchestrations.
If a transactional Q is setup & error occurs, then the message is available in the Q for re-processing.
thnx once again!