search

Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.49k stars 4.82k forks source link

[FEATURE REQ] Azure Functions Service Bus output - support setting message metadata #21884

Closed anthonychu closed 5 hours ago

anthonychu commented 3 years ago

Library or service name. Microsoft.Azure.WebJobs.Extensions.ServiceBus

Is your feature request related to a problem? Please describe.

For out of process languages, including the .NET isolated worker, it's not possible to set metadata on output messages such as correlation ID. Provide a way to optionally set these properties on output messages.

https://github.com/Azure/azure-functions-dotnet-worker/issues/474

Dave-Kiwi commented 3 years ago

Should the library you quote be Microsoft.Azure.Functions.Worker.Extensions.ServiceBus in the case of the .Net Isolated Worker?

JoshLove-msft commented 3 years ago

Should the library you quote be Microsoft.Azure.Functions.Worker.Extensions.ServiceBus in the case of the .Net Isolated Worker?

I think so. This is being tracked in https://github.com/Azure/azure-functions-dotnet-worker/issues/496

anthonychu commented 3 years ago

Should the library you quote be Microsoft.Azure.Functions.Worker.Extensions.ServiceBus in the case of the .Net Isolated Worker?

No. This request is for the WebJobs extension to support metadata properties on output messages; this is language worker agnostic. Once this ability is there, each language can add support in a way that makes sense for their language.

JoshLove-msft commented 3 years ago

So this is asking for a way to set these properties outside of the strong model type (similar to how you can bind to string versions of the properties for the trigger)?

anthonychu commented 3 years ago

I think so. This a problem across several bindings and they should probably be addressed in a consistent manner. See also:

For example, one possible solution would be to add a prop that indicates that the worker is returning a message envelope instead of just the data itself.

{
  "name": "$return",
  "type": "serviceBus",
  "queueName": "testqueue",
  "connection": "MyServiceBusConnection",
  "includeMetadata": true,
  "direction": "out"
}

JavaScript: 

return {
  body: "my message",
  correlationId: "foo",
  userProperties: { /* ... */ }
}

/cc @fabiocav @ankitkumarr @brettsam

fabiocav commented 2 years ago

Additional requests are coming for this in order to support sessions in OOP scenarios.

https://github.com/Azure/azure-functions-dotnet-worker/issues/681

@anthonychu should we schedule a sync to go over the requirements?

Archomeda commented 2 years ago

Is there any update on this? It's baffling that this is an issue for a year now and that .NET 6 is LTS with isolated functions being the way to go from now on, but has somehow been shipped without this critical feature.

JoshLove-msft commented 2 years ago

Hi @Archomeda, I've added this to our July milestone, which means we will work on this in June with the plan to have something shippable for July.

Archomeda commented 2 years ago

Thanks for the update! 😀

jsquire commented 2 years ago

Note: The session id needs to be settable as part of $return

jsquire commented 2 years ago

Duplicate: #28671

GeordieStew commented 2 years ago

Hi

Any update or timescale on this functionality?

aliosmanisikk commented 1 year ago

Hi, Any update on this feature?

raunaknarooka commented 1 year ago

any updates on this? Dont exactly understand the point of having a service bus output binidng, if it is just used for sending messages and not able to set properties on the outgoing message. If we can have a logic app service bus connector to send a message with the parameters, why not for azure functions :)

Scooper2 commented 1 year ago

JoshLove-msft said:

Hi @Archomeda, I've added this to our July milestone, which means we will work on this in June with the plan to have something shippable for July.

@JoshLove-msft July 2022 was more than 1 year ago. Any updates? Now message settlement has been introduced for isolated functions, this feature might be the last one for us to actually be able to transition from in proc functions.

BoasHoeven commented 8 months ago

Has this been fixed yet? Today I tried to set the session id and return a servicebus message to an output binding and it did not find the SessionId correctly.

jormasyrja commented 7 months ago

+1 for implementing this, I am working on a system that relies heavily on ServiceBus outputs and I would prefer not to have to refactor all of them to not use function bindings just to get this to work.

Currently running our functions in in-process mode, but migration to isolated mode is necessary in the future due to in-process mode support being dropped.

Dave-Kiwi commented 7 months ago

+1 for implementing this, I am working on a system that relies heavily on ServiceBus outputs and I would prefer not to have to refactor all of them to not use function bindings just to get this to work.

Currently running our functions in in-process mode, but migration to isolated mode is necessary in the future due to in-process mode support being dropped.

I gave up on timely implementation of this feature, and moved to the isolated process model anyway, injecting 'ServiceBusClient' in the constructor and then using it like this, for example, to create messages. You can still consume messages using the binding if you want to.

ServiceBusSender mySender = serviceBusClient.CreateSender("topicName"); var myMessage = new ServiceBusMessage("Some message"); myMessage.CorrelationId = "whatever"; await mySender.SendMessageAsync(myMessage).ConfigureAwait(false);

github-actions[bot] commented 6 months ago

Hi @anthonychu, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

cataggar commented 3 weeks ago

I have an internal pull request that switches an app from in-process to isolated. My first attempt had to be reverted.

How do I port this in-process output binding to isolated?

[<ServiceBus("meter")>] collector: IAsyncCollector<ServiceBusMessage>

I have this, and I return a List<ServiceBusMessage> which does not work.

[<ServiceBusOutput("meter")>]

My workaround appears to be to inject my own ServiceBusClient. Is that recommended migration strategy?

jsquire commented 5 hours ago

@cataggar: Yes, injecting your own ServiceBusSender is the recommended approach.

When last we spoke with the Functions team on the topic of output bindings, the strategy for the isolated model was to remove emphasis on the output bindings in favor of using the client types directly. To my knowledge, that has not changed, though we've reached out to the Functions team to confirm.

In order for the extensions to be able to pass ServiceBusMessage to the output bindings, work would be needed in the Functions host infrastructure to enable an RPC channel with binary serialization support that could be used to do so. To our knowledge, that is not something currently planned. The closest tracking issues that I was able to find in the Functions host repository are:

In short, if the Functions team decides to invest in more robust support for output bindings in the isolated model, the Azure SDK extensions - including Service Bus - will support passing strongly-typed data. Until there is confirmation of that direction, I'm going to close this back out, as it is not actionable.