Issue on Azure Function during the configuration of CosmosDB output binding with Managed System identity - node.js

Currently on one of my project, I've an Azure function (NodeJS 16) running to be triggered on a blob creation and that need to take few informations and saved them to a cosmos db. For that I use a Cosmos DB output binding.
At the start, I used the classic connection for that with the connection string. It worked well. But now, I don't want to deal with the rotation of the keys for this connection string. That's why I wanted to move to the version 4+ of the azure extension in order to connect with Managed System Identity.
Right now it works well for the blob trigger with MSI, it is triggered and it run the function. But at the end, when I do the context.done() in order to save the datas to the cosmos db, I get this error.
2022-10-31T15:59:00.203 \[Error\] Executed 'Functions.SaveToCosmosDB' (Failed, Id=9162f53b-8c79-44bf-82b9-ca9c4267cc76, Duration=359ms)
Could not load file or assembly 'System.Configuration.ConfigurationManager, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified
I'm stuck with it since fews days. I don't get it, why do I get a .NET package error ? I'm using a NodeJS function. Do someone already get this issue before ? Or am I wrong with my configuration ?
Thanks in advance for your help
Here is my host.json:
{
"version": "2.0",
"extensionBundle":
{
"id": "Microsoft.Azure.Functions.ExtensionBundle.Preview",
"version": "[4.*, 5.0.0)"
}
}
and here is my function.json
{
"bindings": [
{
"name": "imageBlob",
"type": "blobTrigger",
"direction": "in",
"path": "images/{name}.bmp",
"connection": "MYAPP_BLOB"
},
{
"direction": "out",
"name": "metadata",
"type": "cosmosDB",
"databaseName": "MYAPP_COSMOS_DATABASE",
"containerName": "MYAPP_COSMOS_CONTAINER",
"connection": "MYAPP_COSMOS",
"preferredLocations": "Central US"
}
]
}
When I change from extension version 3+ to 4+, I change the property collectionName to containerName as described in the MS documentation https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-cosmosdb-v2-output?tabs=in-process%2Cextensionv4&pivots=programming-language-javascript
But I've seen a mismatch in the documentation, for the .Net version, if we use a 4+ version of the extension, the property ConnectionStringSetting change for Connection but for the JS version of the code, it remains ConnectionStringSetting. Is it normal or is it a typos mistake in the documentation ?
Thanks in advance for your help.

Related

Azure Data Factory V2 bug in Set-AzureRmDataFactoryV2Dataset when dataset type json

When I try to use Set-AzureRmDataFactoryV2Dataset and dataset type is "Json" in incoming file for some reason in ADFV2 code changed so that type = "Dataset" and ADFV2 says files is corrupted.
This is the end result in ADFV2:
"properties": {
"type": "Dataset",
"typeProperties": {
"location": {
"type": "AzureBlobFSLocation",
"fileName": "somefile",
"folderPath": "folder/files",
"fileSystem": "source-data"
},
If I modify file in ADFV2 value "Dataset" back to "Json" its not corrupted anymore. See above.
"properties": {
"type": "Json",
"typeProperties": {
"location": {
"type": "AzureBlobFSLocation",
"fileName": "somefile",
"folderPath": "folder/files",
"fileSystem": "source-data"
},
Is there bug in parser?
The type in the dataset json tells data factory which kind of storage you are accessing. It looks like you are trying to access a blob storage or a data lake v2. In those cases, the type attribute must be set to:
AzureBlobStorageLocation if its a blob storage as seen here: https://learn.microsoft.com/en-us/azure/data-factory/connector-azure-blob-storage#dataset-properties
AzureBlobFSLocation if its a lake v2 as seen here: https://learn.microsoft.com/en-us/azure/data-factory/connector-azure-data-lake-storage#dataset-properties
You can also check out an example json if you scroll down a bit in those links.
Hope this helped!
In case anyone else runs into this issue, I can confirm this is a bug in the Az/AzureRM PowerShell module, which appears to have been fixed as of Az version 2.5.0 (at least, possibly earlier).
I hit the same problem when trying to define a dataset with a type 'Binary'. The JSON I provided had it correct, but when it was actually created the type was 'Dataset'. When playing around I realized it was only happening on my Windows VM, running the Az module version 2.1.0. Running from my Linux OS with Az version 2.5.0 worked fine. On updating my Windows VM to 2.6.0 the problem went away.

Deploy Azure Function dynamically enabled/disabled using ARM template

I have a class library, timer-based Azure Function that is deployed using an ARM template. Everything works fine except I would like a slightly different behavior based on the target environment. When deploying to a test environment I would like the function to be initially disabled but in production it should always be enabled. Is this possible?
My current workaround is to have an app setting that tells the function to immediately exit when set to a specific value. However, this seems like a poor solution, especially since the timer-triggered function is executed quite frequently. To solve this I manually disables the function using the following switch in the Azure portal:
Is there perhaps possible to specify the desired state of this switch from the ARM template?
Seems you don't need to set to a specific value in the app settings, azure function has a built-in property.
Try to use the setting in the template snippet below to disable the function, it should work.
"siteConfig": {
"appSettings": [
{
"name": "AzureWebJobs.MessageQueueMonitorFunction.Disabled",
"value": "true"
}
]
}
Expanding on Joy's answer, which worked like a charm!
For the benefit of others, the "name" property above is composed like so:
AzureWebJobs.<YouFunctionName>.Disabled
where <YouFunctionName> is specified in your template.json here:
{
"resources": [
"name": "<YourFunctionName>",
"type": "functions",
"properties": {
"config": {
"bindings": [
{
...
}
]
}
}
]
}

Azure Function Runtime version: 2.0.11888.0 (beta) become connot able to connect to cosmosDB

I'm developing the simple node.js code for inserting of new document to cosmosDB via Azure function app by using http trigger function. That's simply get the input value from http's parameter and output to cosmosDB(SQL api). About last 2 weeks, it was successfully running but now facing with internal server error. That's why? Is is affect on azure function's runtime minor version update?
->function.json
{
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "req"
},
{
"name": "outputDocument",
"type": "cosmosDB",
"databaseName": "ToDoList",
"collectionName": "Items",
"createIfNotExists": true,
"connectionStringSetting": "COSMOSDB_CONNECTION",
"direction": "out"
}
]
}
->index.js
module.exports = function (context, req) {
context.bindings.outputDocument = JSON.stringify({
name: req.query.name
});
context.done();
};
->browsing error
INTERNAL SERVER ERROR
You are right, function runtime update(begin with 2.0.11857) has a breaking change for JavaScript functions. See this issue comment.
We are deprecating support for Node v6, which may affect deployed function apps. Please change WEBSITE_NODE_DEFAULT_VERSION in App Settings to an 8.x version that is >=8.4.0 (for example: 8.11.1).
Have done some tests, it does cause Internal Server Error if I keep WEBSITE_NODE_DEFAULT_VERSION as 6.5.0.
Before 2.0.11857 releases, WEBSITE_NODE_DEFAULT_VERSION is 6.5.0 in both v1 and v2 function. After then, when we upgrade function runtime from ~1 to beta, WEBSITE_NODE_DEFAULT_VERSION changes to 8.11.1 automatically.
Update
Node version changing doesn't work for you, maybe it's cased by cosmosdb extension being broken. You could have a try while I can't reproduce your problem on my side.
Steps to reinstall extension:
Stop your function app.
Visit https://<functionappname>.scm.azurewebsites.net/DebugConsole and navigate to D:\home\site\wwwroot.
Delete the folder bin and extension.csproj.
Go back to function portal and create a cosmosdb trigger to install the extension again.
Start your function app to test.

Error with Azure Function Service Bus Output Binding

I'm having an issue with an Azure Service Bus output binding that I'm uncertain about how to proceed with. I've had no luck finding a similar question, so I apologize if this is a duplicate.
I'm trying to use the local VS 2017 development process, so the function.json bindings should be generated automatically. The function signature is as follows:
[FunctionName("RequestNewPaladinInvitation")]
public static HttpResponseMessage Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "post")]HttpRequestMessage req,
[ServiceBus("thequeue")] ICollector<Invitation> invitationOutputQueue,
TraceWriter log)
{
//Do some stuff and write to the queue
invitationOutputQueue.Add(invite);
}
I get the following error when running the function locally.
Microsoft.Azure.WebJobs.Host: Error indexing method
'RequestNewPaladinInvitation.Run'. Microsoft.Azure.WebJobs.Host:
Cannot bind parameter 'invitationOutputQueue' to type ICollector`1.
Make sure the parameter Type is supported by the binding. If you're
using binding extensions (e.g. ServiceBus, Timers, etc.) make sure
you've called the registration method for the extension(s) in your
startup code (e.g. config.UseServiceBus(), config.UseTimers(), etc.).
[9/1/2017 5:42:49 PM] Error indexing method
'RequestNewPaladinInvitation.Run'
Both my host.json and local.settings.json are defined as follows:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "<MyStorageAccountInfo>",
"AzureWebJobsDashboard": "<MyDashboardInfo>",
"AzureWebJobsServiceBus": "<MyServiceBusConnectionString>"
}
}
I was under the impressing that defining the AzureWebJobsServiceBus value would make that the default ServiceBusAccount for any ServiceBus bindings throughout the function app.
I also tried explicitly pointing the ServiceBus binding to the connection string for the account with the following alternative attribute [ServiceBus("createpaladininvitation",Connection = "ServiceBus")]. My understanding of the convention is that the AzureWebJobs portion of the property should not be included. Just in case I misunderstood, I tried [ServiceBus("createpaladininvitation",Connection = "AzureWebJobsServiceBus")] as well. I even tried to decorate both the method and parameter with the following attribute, [ServiceBusAccount("ServiceBus")]. I also tried the same variations as with the Connection parameter for the ServiceBus attribute.
In all cases, I get the same function.json output, which shows no binding generated for the ServiceBus output binding.
Here's the function.json:
{
"generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
"configurationSource": "attributes",
"bindings": [
{
"type": "httpTrigger",
"methods": [
"post"
],
"authLevel": "anonymous",
"name": "req"
}
],
"disabled": false,
"scriptFile": "..\\bin\\AzureFunctionsPoc.dll",
"entryPoint": "AzureFunctionsPoc.RequestNewPaladinInvitation.Run"
}
It feels like I'm missing something obvious.
[Update]
As I tried to continue to figure out what's going on, I ran the function locally and edited the generated function.json file and added the binding that I think should have been generated. The resulting manually edited function.json is:
{
"generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
"configurationSource": "attributes",
"bindings": [
{
"type": "httpTrigger",
"methods": [
"post"
],
"authLevel": "anonymous",
"name": "req"
},
{
"type": "serviceBus",
"name": "invitationOutputQueue",
"queueName": "createpaladininvitation",
"connection": "ServiceBus",
"direction": "out"
}
],
"disabled": false,
"scriptFile": "..\\bin\\AzureFunctionsPoc.dll",
"entryPoint": "AzureFunctionsPoc.RequestNewPaladinInvitation.Run"
}
With those edits, the method works exactly as expected.
This feels even more like either a syntax or convention issue that I'm missing, or a tooling bug.
There is currently an outstanding tooling bug in regards to ServiceBus output triggers. It will work if you 'deploy' your app to Azure Functions, just not locally with the tooling
Please see relevant GitHub issues here: Service Bus output binding issue
and here: Latest v1.0.0 not working with ServiceBus. alpha 6 still works.
This is related to the lazy load. We're not picking up the service bus extension, hence the indexing error. (Azure/azure-webjobs-sdk-script#1637)
The reason for that is that ServiceBus extension is different than the others. We expect extensions to have a public parameterless config object that implements IExtensionConfigProvider.
SB is internal (https://github.com/Azure/azure-webjobs-sdk/blob/663a508e8a851629c26a51e7de3af36629dfd120/src/Microsoft.Azure.WebJobs.ServiceBus/Config/ServiceBusExtensionConfig.cs#L17 ) so our scan for ExportedTypes misses it (see https://github.com/Azure/azure-webjobs-sdk-script/blob/b1445485807bb190ba0716af1a8dc81a864b5228/src/WebJobs.Script/Host/ScriptHost.cs#L735) .
SB's config does not have a parameterless ctor, so the Activator.createInstance call will fail too.
This hotfix (which we made to script runtime) Azure/azure-webjobs-sdk-script#1804 would fix it; but that would need to be pulled to CLI.

Azure-functions: Can environment variables be used in function.json?

I'm currently using the git push deployment option to deploy a few copies of an azure-function. The function's function.json file has multiple "connection" entries linking to different storage accounts (i.e. for a blob trigger & table output). In different copies of the deployed function I'd like to connect to different storage accounts. Is there any special syntax that can be used in function.json to populate the "connection" string from an environment variable?
I guess an alternative would be to edit function.json as part of a custom kudu step, but environment variables seems more consistent with the other azure app service offerings.
This already works, and is actually the recommended way for you to handle connection strings, since you don't want those checked in with your source code. You can use an app setting name for the connection value, and we'll resolve it. In the following EventHub triggered function, the values MyEventHubReceiver, MyEventHubSender and MyEventHubPath will be auto resolved from app settings:
"bindings": [
{
"type": "eventHubTrigger",
"name": "input",
"direction": "in",
"connection": "MyEventHubReceiver",
"path": "%MyEventHubPath%"
},
{
"type": "eventHub",
"name": "output",
"direction": "out",
"connection": "MyEventHubSender",
"path": "%MyEventHubPath%"
}
]
}
In general, most of the binding properties support the %% resolution syntax, allowing you to store the actual values in app settings for both security as well as configurability.

Resources