I have requirements that all of our endpoints be unobtrusive. This has worked fine until I started working on a new DataBus strategy for a new feature. The DataBus solution is very nice and saves a lot of code, however using unobtrusive mode with it does not allow me to properly clean up the databus attachment in the fileshare. Usually, with DataBus, we use the DataBusProperty<byte[]> type which stores the filepath and provides access to the byte[] content with the Value property. This property also has a Key property which I can use to find the file in the fileshare. I can use this Key property to then clean up the attachment and remove it from the fileshare after I have successfully handled the message.
The problem is that when I use an unobtrusive mode for the databus transfer I am forced to use a byte[] with a conventional name. The content is automatically supplied in the hadler but I lose access to the Key property which I need to then clean up the attachment from the fileshare after successfully handling the message. This forces me to do a manual cleanup strategy for the fileshare which really sucks. In the end, it is forcing me to not use the databus strategy but to just use the old fashioned fileshare practices for the message transfer.
My question is, is there a better cleanup strategy when using the FileShareDataBus with unobtrusive mode? A suggestion would be to use a tuple<string, byte[]> that provides access to the key for the file in the fileshare instead of just using byte[] for the databus transfer.
Hi Chris
In theory there should be a header you can inspect. The header key logic is the following
headerKey = $"{message.GetType().FullName}.{property.Name}";
"NServiceBus.DataBus." + headerKey
So for a message MyDataBusMessage with a property MyPayload the key would look like
NServiceBus.DataBus.Namespace.MyDataBusMessage.MyPayload
The key should contain the information you are looking for. Just read the corresponding header from the message.
Hope that helps
Regards
Daniel
Hello Daniel,
That helps tremendously. I see the key in the header info.
Thanks for the reply,
Chris
Hello again Daniel,
Is there a way to configure the keys so that they do not use the subdirectory structure within the fileshare. For example, instead of having multiple subdirectories sorted by date with the databus objects stored inside I can just have all databus objects in one main fileshare directory.
Regards,
Chris
Hi Chris,
Yes but I’m a little bit afraid to tell you that as of now it requires you to go down the custom data bus path as described here
You could essentially copy paste the impl from https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/DataBus/FileShareDataBusImplementation.cs
and then tweak it to your needs.
Another options is to adopt this sample Handling Stream Properties Via the Pipeline • NServiceBus Samples • Particular Docs
which moves you away from the databus.
Sorry to say that it is not just “set some flag and you are good to go”
Regards
Daniel
Hello again Daniel,
I see. I’ll take a look at that. Once again your info is a tremendous help.
I thought the benefit of the FileShareDataBus was that it is just less code for me to write. I can then handle BLOBs like I would handle a normal message. If I have to write a custom DataBus for this then would it not be easier or pretty much the same to just write my files to a share and read them in the handler? The benefit is lost it seems. Maybe you could argue that it still abstracts that logic from the handler maintaining the separation of concerns?
Regards,
Chris
Hi Chris,
I think it is fair to say that the DataBus hasn’t received the required love it should have received over the past, and we have a lot to improve there. We are tracking it and prioritise it when the time is ready.
In the meantime, we appreciate feedback like yours so that we can feed it back into our DataBus vNext roadmap.
Regards
Daniel
Hi Daniel,
In case you’re interested, it looks like I was able to implement a custom DataBus while still using the generic DataBus endpoint configuration.
// DataBus
var dataBusFileShare = ConfigurationManager.AppSettings[“DataBus”];
var dataBus = endpointConfiguration.UseDataBus<MccFileShareDataBusDefinition>();
dataBus.BasePath(dataBusFileShare);
So far it’s working,
Chris
Hi Chris,
Yeah that is exactly what I meant with customizing the data bus.
Regards
Daniel