Open JoeBrockhaus opened 7 years ago
christopheranderson
commented
7 years ago Related: https://github.com/Azure/azure-webjobs-sdk/issues/798
Same message: This is something we could probably support. We'll review this at our next review cycle.
JoeBrockhaus
commented
7 years ago Just want to follow-up that I was able to use the UserTypeToBrokeredMessageConverter to create ..Convert(new MyPoco()) & push IAsyncCollector<BrokeredMessage> BrokeredMessages in one function, and then receive those in another function triggered on a queue and using a POCO parameter [ServiceBusTrigger('topic','subscription')] MyPoco entity.
I initially wanted to subclass the appropriate AsyncCollector implementation to add overrides for custom properties, and then inject that manually, but quickly ran into issues because it looks like the code was never intended to be extensible.
If IAsyncCollector could be extended to support external context with a new (extensible) type introduced to wrap incoming entities to include any additional (webjob-extension-platform-specific) context, that would still allow strong typing and easy consumption, and give nice middle-ground of extensibility to support fully-featured scenarios.
JoeBrockhaus
commented
7 years ago any update on this?
There is a lot of power baked into the WebJobs SDK to allow easy triggering & consumption of queue/service bus messages that are json-serialized from custom user POCOs.
However, there are drawbacks because there is no access to the BrokeredMessage objects created behind-the-scenes, which means Functions can't modify fixed or custom properties, which can then be utilized by the TopicSubscription Rules & Actions. And vice versa, custom properties set by Rule Actions cannot be retrieved by the webjob functions.
In addition, it appears that POCO- & BrokeredMessage-based triggers are (by default) mutually exclusive: If the sending function creates and pushes the BrokeredMessage with a manually-json-serialized body, the resulting BrokeredMessage/Body is incompatible with Functions defined with POCO Triggers or tokenized Input Binders (blobs/tables).\ workaround for this posted as a comment below.Being able to both set and access the various header-level message properties would provide the ability to both spin up functions with little overhead, but also leverage the inherent power of the ServiceBus entities.
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:).