You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature related to a problem? Please describe.
In cases when bridged messages are generated by a third-party non-NServiceBus system there might be a need to transform them on the bridge so that they can be properly consumed by an NServiceBus endpoint on the other side of the bridge
Describe the requested feature
Add an extensibility point that allows transformation of messages going through the bridge. The extensibility point would be in form of a callback or an interface method that takes as input the MessageContext from the transport and returns the TransportMessage to be send to the transport on the other side.
Describe alternatives you've considered
The alternative is to use the message mutators to transform the messages in the destination endpoint.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
To add an example where this would be useful: RabbitMQ messages might have message properties (maybe from 3rd party senders) which by default aren't forwarded when using the bridge as the bridge only forwards message headers. On a regular endpoint, the properties can be accessed using the native RabbitMQ message available in the message context, however this isn't possible with the bridge as there is no extension point that gives users access to the message context of the incoming/outgoing messages.
Describe the feature.
Is your feature related to a problem? Please describe.
In cases when bridged messages are generated by a third-party non-NServiceBus system there might be a need to transform them on the bridge so that they can be properly consumed by an NServiceBus endpoint on the other side of the bridge
Describe the requested feature
Add an extensibility point that allows transformation of messages going through the bridge. The extensibility point would be in form of a callback or an interface method that takes as input the
MessageContext
from the transport and returns theTransportMessage
to be send to the transport on the other side.Describe alternatives you've considered
The alternative is to use the message mutators to transform the messages in the destination endpoint.
Additional Context
No response
The text was updated successfully, but these errors were encountered: