The Service Bus for the Connected Business
I am using the process step "Service Endpoint", to orchestrate a service in a request/response type of message patterns without publishing the message on a specific topic as would happen with the Publish step.
The two configuration seems to result in a different behavior:
Service Endpoint: if everything works fine, only the request message is logged in the audit database;
if an error occurs (for instance one of the service orchestrated is down), still one message is logged but with FaultType = None and a SoapFault response is returned;
Publish step: if everything works fine all the messages can be logged in the audit database (at least the couple send/request, received/reply that allow to gather statistics information on web service response).
However, if an error occurs, (for instance one of the service orchestrated is down), the client faces a Communication reset error, and the receive/reply message is audited with FaultType = Communication , but no SoapFault response is returned.
Is the described behavior correct? Am I implenting the pattern in a wrong way? Is there a way to "merge" the two behaviors, for instance, using the Service Endpoint step (seems to me the best way to implement the orchestration) having statistics logged in the audit database with a valid FaultType?
Is there any other way to get service response time from the data currently available?
Thank you very much
Fabrizio
Tags: endpoint, publish, request/reply, service
Views: 549
Fabrizio - we have two audit tables: Message History and Failed Messages. It seems like you are looking at both. Do you have Auditing enabled at the topic? With auditing enabled at the topic, only messages that are published to the topic are audited. When using the Service Endpoint Step in a process, messages are not published to the topic and are not automatically audited to the message history table. This is by design. But when using the Publish step, messages are audited to the Message History table. If you want to audit messages to the message history table and use the Service Endpoint step, using the Audit step just before the service endpoint step (for the request message) and another one just after the service endpoint step (for the reply message).
Joe
Hi Joe,
thank for the answer.
I am looking at both the table, and I am collecting statistics on service usage/calls correlating send/request messages with receive/reply ones. The audit step allow to choose the action that I am setting to "Receive", however the message Semantic is set as Request, while I would be expecting Reply. Is that correct?
I can always change the semantic using a c# block and it works but it just didn't seem right.
Fabrizio
The "action" on the audit step can be whatever you want, but it's meaning is in relation to the bus. A message coming from a client connector would have a request semantic, but from the publishers point of view you are sending it to the bus. If the audit step was on the on receive event for a subscriber, then the action would be receive as the subscriber is receiving the message from the bus, even though the message semantic is still request.
For the first audit step you should set the action to send and for the second one you would set it to receive.
Joe
Ok... I understand, it perfectly make sens.
As the process contains a cancel step, the message is not published to the bus and its semantic remains request, even though the message is actually returned to the caller as a reply.
I will try to implement a different solution to gather performance data such as the service response time.
Thank you
Fabrizio
Neuron ESB Product Support Forums and Communities
© 2024 Created by Neuron Admin.
Powered by
