search

Azure / azure-webjobs-sdk

Azure WebJobs SDK
MIT License
737 stars 358 forks source link

Support Table Bindings (input) from BrokeredMessage Custom Properties #798

Open JoeBrockhaus opened 8 years ago

JoeBrockhaus commented 8 years ago

I have a S/O question which highlights my current issue.

If I json-serialize the model representing the message body, and construct the BrokeredMessage from that string, subsequent Table bindings that rely on properties in that message body fail with error:

No value for named parameter ...

Being able to bind to BrokeredMessage Custom Properties would solve this problem, because I'm moving these values (which can be unique across duplicate messages) to that collection anyway, so that I can utilize duplicate message detection on the service bus topics.

I would take a stab at implementing it, but rather than go at it blindly it might be best if someone from the team give a gut check on level of effort & roughly where the extensions would ideally be made (adding the functionality is surely less involved than learning the architecture ;-) :100:).

christopheranderson commented 8 years ago

This is something we could probably support. We'll review this at our next review cycle.

MikeStall commented 7 years ago

Is this saying that the binding data for a SB trigger should include the "custom properties"? Normally binding data needs to be static. Maybe related to https://github.com/Azure/azure-webjobs-sdk/issues/968

mathewc commented 7 years ago

Yeah, making arbitrary/variable custom properties violates a bunch of rules we have now in the system that binding data is static. However, if there are some non-variable properties in the property bag, those could be promoted to binding data (similar to what we do with Queue dequeue count, etc.). Related issue: https://github.com/Azure/azure-webjobs-sdk/issues/1004

mathewc commented 7 years ago

We recently added support for binding to BrokeredMessage.Properties as documented here: https://github.com/Azure/azure-webjobs-sdk/wiki/Trigger-Binding-Data. I believe that gets us half way where you want to go, however there is still no way for you to "dot into" the Properties data in your table binding expression (e.g. can't do {Properties.PK}).