Publisher Semantics

Replies to This Discussion

Permalink Reply by Martin Wasznicky on March 21, 2017 at 12:29pm

true.  if you are doing a request/reply, you want to make sure there is only ONE possible subscriber to that request.  usually this can be done with sub topics.  in fact that's how we do a lot of dynamic routing scenarios for multi cast as well.  

The reply semantic you'll probably never use.  we use that internally to assist in routing a reply message back to the original caller. 

direct can be useful.  if you set Direct to true, you also have to set the DestId property on the ESB message header to the name of the subscriber you want to send the message to. When you use Direct, no one else will get the message other than the Subscriber name you set as the DestID.

Routed is a special case when you are doing Itinerary routing.  we ship a sample that demonstrates this. 

• ▶ Reply

Permalink Reply by Marc P. on March 24, 2017 at 7:38am

thanks Marty. that makes sense.

It seems at though with the Direct and setting a specific dest id, I get a semantic mismatch if the dest has a service connector with a request-reply semantic. But in that scenario since I have a specific destination, I'd think calling the service connector directlywith the Service Endpoint process step would be the way to go.

thanks.

• ▶ Reply

Permalink Reply by Martin Wasznicky on March 24, 2017 at 8:21am

you'll get a semantic mismatch if the message semantic you are sending to a configured "request/response" service connector.  its really designed for party to party communication.  You are correct though....you can call the service endpoint directly using the service endpoint process step. you can also dynamically set the service connector to be called using that step by setting the name of the service connector in the context.data.header.Service property

• ▶ Reply