Pluggable message id strategy #69
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andreasohlund
force-pushed
the
message-id-strategy
branch
from
6a1e804 to
23be8ae
Compare
| var properties = channel.CreateBasicProperties(); | ||
|
|
||
| //for now until we can patch the serializer to infer the type based on the root node | ||
| properties.Headers = new Dictionary<string, object> { { Headers.EnclosedMessageTypes, typeof(MyRequest).FullName } }; |
There was a problem hiding this comment.
@SimonCropp @johnsimons @yvesgoeleven should we consider making the serializers smarter when it comes to inferring messages type to make external integrations easier? (json serializers also needs to the header to be set)
For XML we can match on the root node and for json we can use the $type thing?
|
@johnsimons can you review this one? |
andreasohlund
added a commit
that referenced
this pull request
Jan 9, 2015
Pluggable message id strategy
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The strategy for detecting message id's are now pluggable to provide better interop with non NServiceBus endpoints
Part of fixing #13
Documentation
By default NServiceBus uses the
message-idproperty of the AMQP standard to relay the stable message id. If this header isn't set the transport will throw an exception since NServiceBus needs a message id in order to perform retries, deduplication etc in a safe way. In integration scenarios where you might not control the sender you might want to use your own custom scheme eg. a customer header or some data contained in the actual message body. In these cases you can plugin in your own strategy by calling:insert final config call here.