I am building a console application that will be run as a continuous Azure WebJob. I am using the Azure WebJobs SDK via the Nuget Package Microsoft.Azure.Jobs.ServiceBus v0.3.1-beta (prerelease). I have static method that triggers on an Azure ServiceBus queue. I do some processing and then want to have the option to send a response via the output parameter to another queue. The method signature looks like this:
public static void TriggerOnQueue(
[ServiceBusTrigger(QueueName)] BrokeredMessage receivedMessage,
[ServiceBus(QueueResponseName)] out BrokeredMessage responseMessage)
{
...
}
My initial thought was to set the responseMessage to null. However, when I do this an error appears in the console window. It doesn't stop execution (so it technically does what I want it to do), but I would rather not push something throwing errors to production. Is there any non-hackish way to set a value in the response message that will not throw an error, but will not submit the message to the response queue?
If not, is there another pattern I am missing that I could use? I would prefer to use the pipeline feature of the WebJobs SDK as opposed to creating the output queue manually. I could probably submit the requests that need a response on to a separate queue and have 2 separate triggers, but with the small amount I am having this do I would rather keep it simple and together.
Thoughts?
This pattern of specifying null for an out parameter works for Azure Queues but it throws an exception for Service Bus Queues. This looks like bug in the SDK. I will open a bug for us to fix it. Thank you for reporting this issue
Related
I'm new to Azure Functions and I couldn't find a good explanation about output bindings.
For example, if I want to upload a blob to Azure Storage when is recommended to use output binding and when to manually upload (which are advantages/disadvantages in each case)?
And which is the difference between output binding as a parameter in the Run function, and as an attribute?
Parameter:
[FunctionName("MyFunction")]
public static void Run([ServiceBusTrigger("myqeue")] Message message,
[Blob("output-container/{name}", FileAccess.Write)] Stream stream)
{ }
Attribute:
[FunctionName("MyFunction")]
[return: Blob("output-container/{name}")]
public static string Run([ServiceBusTrigger("myqeue")] Message message, ILogger log)
{ }
when is recommended to use output binding and when to manually upload (which are advantages/disadvantages in each case)?
Here is the clear overview of when to use output bindings and for which service gives what features when using output bindings!
As we know, Bindings cannot co-exist without Azure Function triggers and 2 types of bindings available: Input and Output.
Output Binding: Data sent by your function is an example of an output binding.
Let's discuss the 2 ways of using output binding:
1) Stored Queue's data from the blob container acts as output binding
Scenario:
In the Azure Functions EF Core Http Trigger Context, Queue will be utilized as an output binding to store the data to the local storage once the data has been saved to the database.
Second, when data is added to the Queue store, a new function will be formed. In this case, the data in the queue will be saved in the Blob container as an output binding, with the queue serving as the input binding. By including the Blob property for each queue trigger, the Blob container is used as output binding.
2) Service bus queue from Azure storage acting as output binding
Scenario:
Firstly, upon triggering of HTTP request, the HTTP request body will be sent as a request to Server Bus-Queue by using an output binding.
Secondly, after the message is sent to the server bus queue, function will be triggered and the data will be logged in the application.
Here is the blog article provided the use cases and features of each service in detailed format, thanks to Ashish Patel.
A storage queue can be the ideal choice if you want to create code as soon as possible or if you want to transmit each message to just one recipient/destination. Otherwise, Service Bus queues offer a lot more flexibility and possibilities.
I need to add correlationId to my logging context and I did it on my MVC project by adding CorrelationId nuget to the project and setting up its middleware, but I could not do the same in Azure functions.
I have loaded the ICorrelationContextAccessor using Dependency injection and then set my correlationId like this:
[FunctionName("func1")]
public async Task Run([ServiceBusTrigger("mytopic", "MySubscription", Connection = "ServiceBusConnectionString")]Message message)
{
_correlationContextAccessor.CorrelationContext = _correlationContextFactory.Create(message.CorrelationId, "X-Correlation-ID");
_logger.LogInformation($"C# ServiceBus topic trigger function processed message: {message.MessageId}, {Encoding.UTF8.GetString(message.Body)}");
It works fine and I see my correlationId in the log line below and in my services in the function. The only part that I am missing is that I have logs regarding the start and finish of the function that still has no correlationId, which kind of make sense becaue when the function wants to log that it has received the message the correlationId is not set.
The short version is that you can't effect the logging code that runs before your function using the built in bindings.
You won't be able to change that first "C# Timer trigger function processed message" as the message hasn't been read at that point-- it would be the same as trying to get the correlation ID set in your MVC project before reading the incoming HTTP request.
You could add logging as soon as the message is first received by creating a custom binding. I would encourage you to consider carefully whether or not it is worth building and maintaining a custom binding to get your logging setup a few lines sooner.
I'm building as part of a larger process that analyzes the results of the build once it has completed. I used to work with XAML builds via C# code, and I had the following code:
QueuedBuild.Connect();
QueuedBuild.PollingCompleted += PrivateServerBuildRequest.BuildCompleted;
(QueuedBuild was IQueuedBuild type),
With new WebApi builds, do I have an event that let me know that the build has completed?
I found BuildCompletedEvent in Microsoft.TeamFoundation.Build.WebApi.Events but I didn't manage to find the way to use it.
Is there any equivalent to PollingCompleted event in WebApi builds? Something that'll fire once all build results are available?
One of the possible alternatives with the new REST API is to use Service Hooks. In particular, you might want to pay attention to the generic Web Hook, whcih can basically instruct VSTS to POST some JSON payload (once a certain event occurs) to some endpoint.
The endpoint can be anything: your custom home-made service hosted on-prem, OR an Azure Function, for instance. This article can give you an idea how to trigger an Azure Function in response to a VSTS event.
The 'Build Completed' event is in the list of available events.
So, to sum it all up, I would try the following in your case:
Create an Azure Function to accept the build info payload and process it accordingly
Subscribe to Build Completed event with the Web Hook and make sure the Azure Function URL is used as the endpoint
This is the first time I'm using Azure Notification Hubs and I'm having some trouble getting it working properly with my application.
The part I'm stuck on (at the moment) is registering my device with the notification hub. I'm using the backend method to do the registration ... that is, I'm creating an Installation object and using the CreateOrUpdateInstallationAsync method to register the device via my Web API. I'm only testing it at this stage so I'm hitting my API endpoint with dummy data via Postman.
When I step through my code, I'm getting the following error when I execute CreateOrUpdateInstallationAsync ...
The remote server returned an error: (404) Not Found. Entity does not
exist.TrackingId:203cba37-007d-4dcb-ae25-ced33fa012aa_G1,TimeStamp:2/4/2018
10:24:02 PM
I've tested that I am connecting to the Notification Hub correctly by calling GetAllRegistrationsAsync. This returns an empty list (expected) and no error ... so I have my endpoints set up correctly. I'm wondering if there is a problem with my dummy data? For the installation Id, I've just created a random GUID (Guid.NewGuid). The Device ID and Push Notification Handle are random numbers and letters. And I'm testing this for the Android platform (NotificationPlatform.Gcm).
Has anyone seen this error before and know what it means? Am I able to just use random data for testing purposes (I'm only interested in registering devices at this stage) or do I need legitimate data (real device id's, etc)?
Thanks in advance.
The CreateOrUpdateInstallationAsync method would essentially invoke the REST API Create or Overwrite an Installation. When you register with a notification hub from your custom backend using the Installation, the core code would look like as follows:
NotificationHubClient hubclient = NotificationHubClient.CreateClientFromConnectionString(listenConnString, hubName);
await hubclient.CreateOrUpdateInstallationAsync(installation);
Note: You could install the Microsoft.Azure.NotificationHubs package for back end operations.
For a simpler way, I just created a console application and test this operation as follows:
Note: I just created a new Azure Notification Hub and did not set any notification settings. And I set a GUID as the InstallationId and a random string as the PushChannel, the rest operation could work as expected.
And I could retrieve the previous added registration as follows:
Has anyone seen this error before and know what it means? Am I able to just use random data for testing purposes (I'm only interested in registering devices at this stage) or do I need legitimate data (real device id's, etc)?
The operation could work on my side, I would recommend you debug your application and leverage fiddler to capture the network traces to narrow this issue. Moreover, you could follow Registration management for more details about registering devices with azure notification hubs.
Ok, it turns out that I had the wrong value for Hub Name when instantiating the NotificationHub object using NotificationHubClient.CreateClientFromConnectionString. I was using the namespace, instead of the hub name (visible on the Overview tab in the Azure Portal).
If I have a hub method that accepts parameters
e.g.
public IObservable<MyStreamItem> StreamData(SomeRequestData request)
{}
How do I propogate validation errors in the request?
An actual http request is only made when the socket connection is established.
So subsequent calls to Hub methods dont pass through any middleware. They are just frames/messages in the open websocket.
I've had a look at this package which is for the previous version of Signalr (for the full .net framework)
https://github.com/AGiorgetti/SignalR.Validation
This uses a HubPipelineModule which doesn't seem to exist in the new .net core Signalr.
Is there an appropriate place in the pipeline that I can tap into to do the validation?
Or should it be done in the hub method itself? And if so, how would you conditionally return a structured set of errors, as opposed to what the actual return type is meant to be?
thanks
There are currently no HubPipelineModules in SignalR alpha but we're looking at an equivalent for preview 2. Today, you'd need to do it in the method and potentially throw an error to get it back to the client.