We often get people saying they are losing messages with using the MSMQ topic...

When we investigate, they aren't. But, some things are happening that can confuse.

The number one offender for message "loss" is using two instances of the same Party Id . This is easy to do with Adapters and Connectors and Queued Topics.

The net effect of that is the message will always be delivered to one Party..It's a non mulitcasting queue under there so that makes

… Continue

Many times load balancing can change what the optimal solution is for a given deployment.

Unless careful consideration is given to what is trying to be accomplished then some erroneous conclusions can be arrived at...

For example, people take it as gospel that netTcp binding is superior for performance... That might not be the case depending on how you're using it. Pooling and affinity are great...unless you want to scale in a round robin fashion.

… Continue

I thought I'd share a couple of tips

First Tip : REST drop off point

You can set up a Pipeline that allows the client to POST a message and get a 200 response very easily with Neuron.

1)Create a Pipeline and adding whatever logic you wish to process the POST. Many times this may simply be a Publish step.

2)Next add a Code step that sets context.Data to a new ESBMessage and then uses the FromString method with "" as an argument. You don't have to use an empty string of course you can put anyt… Continue

The component Neuron uses for it's Pipeline code step stores the fully qualified assembly name. This causes issues sometimes for people who have set up assembly versioning in their projects.

When we ask people why they are versioning an internal dll that they never intend to run side by side the most common answer we get is so they can be sure the right one is deployed to production.

So, how can you achieve a process where you provide yourselves this kind of information and not break your pipe… Continue

Sometimes it's efficacious to attach a pipeline unconditionally to the Party's On Client Receive in a Service Connector that uses the SetProperty step to always set the Semantic to "Request" even if the Messaging Pattern in the connector is already set to Request-Reply.

Why would you do that? Well, if the message came from a Client Connector the Semantic is likely already set correctly so this doesn't really do anything.. But if the message came from an Adapter or Pipeline that has published th… Continue