Azure Functions docs#8237
Conversation
004f58a to
0e65bc1
Compare
e9334b5 to
0bbaae0
Compare
andreasohlund
left a comment
There was a problem hiding this comment.
Did a first shallow pass
|
|
||
| An endpoint is a partial class composed of three parts: | ||
|
|
||
| - The class is decorated with `[NServiceBusFunction]`. |
There was a problem hiding this comment.
It can be on the trigger method as well so we need to decide which approach to lead with
| snippet: azure-functions-program-builder | ||
|
|
||
| > [!NOTE] | ||
| > `AddNServiceBusFunctions` is a source-generated extension on `FunctionsApplicationBuilder` declared in the project's default namespace. Ensure `Program.cs` imports that namespace. |
There was a problem hiding this comment.
| > `AddNServiceBusFunctions` is a source-generated extension on `FunctionsApplicationBuilder` declared in the project's default namespace. Ensure `Program.cs` imports that namespace. | |
| > `AddNServiceBusFunctions` is a source-generated extension on `FunctionsApplicationBuilder` declared in the project's default namespace. Ensure `Program.cs` imports that namespace. At least one function needs to be defined for the method to be available. |
|
|
||
| ## Send-only endpoints | ||
|
|
||
| A send-only endpoint can be registered for components that need to dispatch messages without listening for incoming traffic, for example a function fronting an HTTP API: |
There was a problem hiding this comment.
| A send-only endpoint can be registered for components that need to dispatch messages without listening for incoming traffic, for example a function fronting an HTTP API: | |
| A [send-only endpoint](/nservicebus/hosting#self-hosting-send-only-hosting) can be registered for components that need to dispatch messages without listening for incoming traffic, for example a function fronting an HTTP API: |
|
|
||
| ## Connection configuration | ||
|
|
||
| The connection string for Azure Service Bus is read from the Functions configuration. The same setting name is referenced in two places: |
There was a problem hiding this comment.
| The connection string for Azure Service Bus is read from the Functions configuration. The same setting name is referenced in two places: | |
| The [connection for Azure Service Bus](https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus-trigger#connections) is read from the Functions configuration. The same setting name is referenced in two places: |
|
|
||
| NServiceBus log output is forwarded to the Azure Functions logging pipeline automatically. Configure log levels and providers through the standard Functions logging configuration; no additional NServiceBus log setup is required. | ||
|
|
||
| Startup diagnostics are written when the host starts. In Azure they appear in the Functions host log stream and in any configured destination such as Application Insights. |
There was a problem hiding this comment.
The default behavior is a no-op; writing to the log can be opted into via the new API @danielmarbach added in v10.2. Not sure if we have documented that yet?
| { | ||
| [Function(nameof(Orders))] | ||
| public partial Task Orders( | ||
| [ServiceBusTrigger("orders", Connection = "ServiceBusConnection", AutoCompleteMessages = false)] |
There was a problem hiding this comment.
Since the default is AzureWebJobsServiceBus, I wonder if this can be leading users to use this one instead and get tripped up? (ie should we omit it since this shows basic usage)
| { | ||
| var transport = new AzureServiceBusServerlessTransport(TopicTopology.Default) | ||
| { | ||
| ConnectionName = "ServiceBusConnection" |
There was a problem hiding this comment.
Same as above, should we go with the default or not set this as all?
No description provided.