node, azuresb.createServiceBusService provide connection string instead of environment variable - node.js

I'm using the package azure-sb to send a message to an Azure Service Bus topic. My problem is that the constructor expects a key for a connection string for example
azuresb.createServiceBusService(KEY_NAME)
Is it possible to provide the connection string itself instead of a KEY_NAME?

Yes, you can. From the documentation of this package, you do need to pass the connection string.
var connStr = process.argv[2] || process.env.CONNECTION_STRING;
var sbService = azure.createServiceBusService(connStr);
Microsoft Azure SDK for Node.js - Gallery https://www.npmjs.com/package/azure-sb
Also, azuresb seems an older SDKs. If you use Azure SDK for Node.js, here is how you can pass the connection string (quite similar!)
var serviceBusService = azure.createServiceBusService(connectionString)
You might have found the answer already... adding it here if someone else visits your question in future. :)

As mentioned in the other answers, you can pass the connection string. Your code seems to be using the older azure-sb library.
I'd recommend using the latest #azure/service-bus library which is based on AMQP protocol and is more performant.
I know this is a late reply, but just in case someone is running into issues with the older service-bus node SDK and landed here, refer to the links below.
The latest version 7.0.0 of #azure/service-bus has been released recently.
#azure/service-bus - 7.0.0
Samples for 7.0.0
Guide to migrate from #azure/service-bus v1 to v7

Related

Graph SDK for .NET doesn't have Request method

I'm trying to use the Graph SDK and NuGet 5.0.0-preview16 and forwarding the example it says to use Request method in example
var users = await graphClient.Users.Request().GetAsync();
but I have an error in the code:
'UsersRequestBuilder' does not contain a definition for 'Request' and
no accessible extension method 'Request' accepting a first argument of
type 'UsersRequestBuilder' could be found (are you missing a using
directive or an assembly reference?
Since C# SDK V5 Request method is removed and you can call directly GetAsync method. But V5 is still in preview and it's better to use latest V4 version.
var users = await graphClient.Users.GetAsync();
Upgrade guide can be found here.
Fixed: I changed Microsoft.Graph on NuGet from 5.0.0-preview16 to 4.47.0

Creating a main account twilio client on a subaccount node function

I'm developing a twilio function on a subaccount that needs to acces a twilio client on the main account. The function is being deployed through a Github action to the subaccount.
For this, on the subaccount function I have:
const mainClient = new twilio(context.MAIN_TWILIO_ACCOUNT_SID, context.MAIN_TWILIO_AUTH_TOKEN);
Then I need to access serverless.services but I'm getting serverless undefined therefore can't access services.
i.e.
return mainClient.serverless.services(...
I tested code locally and it worked but failed on deployment. Is it possible to access services on main account from a subaccount function??
Thanks.
For anyone experiencing a similar issue.
My problem was that deploying without being explicit about dependencies doesnt install the latests version of dependencies.
Deploy through github installed twilio node sdk version 3.29.0 but this version doesn includes serverless api yet. So I explicitly added latest twilio node sdk (3.75.0 at the moment) and that fixed the problem.
Thanks.

Nodejs version on Google App Engine standard

Googles docs indicate they support the latest LTS of Nodejs, and that they support the latest version of the specified version.
https://cloud.google.com/appengine/docs/standard/nodejs/runtime
it uses the latest stable release of the version you choose.
Currently, NodeJS is on 14 for LTS, and 12.18.4 for version 12. However, App Engine Standard appears to be stuck on 12.16.3 as it's latest version.
Is there any indication of their release cadence? When can we expect an upgrade?
Motivation: I'm trying to setup a typescript monorepo with published packages & App engine. This relies package.json specifying "exports" field, but 12.16 seems not to support it, even behind the --experimental-exports tag.
I have deployed a quickstart with node12 in AppEngine Standard and had the sames results than yours, the current latest TLS for Node seems to be: v12.16.3.
I printed the version with this code:
app.get('/', (req, res) => {
res.status(200).send('Hello, world!>>'+process.version).end();
});
The result was:
This is happening also in the Flexible environment, I faced a similar issue in which is supposed to pick the latest major version, instead always pick a lower, but it is consistent on picking always the same. This seems to be a expected behavior, but it is well worth to know the reason.
I tried setting the specific version 12.18.4 but with no success.
**ERROR**: (gcloud.app.deploy) INVALID_ARGUMENT: The 'package.json' configuration file must specify a supported nodejs12 version that is compatible with the runtime specified in the deployment. Please pin your application to a compatible major version of the runtime via the 'engines.node' property. Supported 'engines.node' values for the runtime 'nodejs12' are: [12.x.x, 12.X.X, 12.x, 12.X, 12.*.*, 12.*, ~12, ~12.0, ~12.0.0, 12, ^12, ^12.0, ^12.0.0, >=12, >=12.0, >=12.0.0, >12.0, >12.0.0, >=1, >=1.0, >=1.0.0, >1, >1.0, >1.0.0, >=2, >=2.0, >=2.0.0, >2, >2.0, >2.0.0, >=3, >=3.0, >=3.0.0, >3, >3.0, >3.0.0, >=4, >=4.0, >=4.0.0, >4, >4.0, >4.0.0, >=5, >=5.0, >=5.0.0, >5, >5.0, >5.0.0, >=6, >=6.0, >=6.0.0, >6, >6.0, >6.0.0, >=7, >=7.0, >=7.0.0, >7, >7.0, >7.0.0, >=8, >=8.0, >=8.0.0, >8, >8.0, >8.0.0, >=9, >=9.0, >=9.0.0, >9, >9.0, >9.0.0, >=10, >=10.0, >=10.0.0, >10, >10.0, >10.0.0, >=11, >=11.0, >=11.0.0, >11, >11.0, >11.0.0].
I think you can file an issue in the Public Issue Tracker, I found this similar in Flexible. This issue could be related to some internal stuff architecture of App Engine. When filing the issue, provide as much information as possible, always sanitizing to avoid sharing sensitive information, such as project ID, passwords, etc.

Keyword not supported: 'authentication' error for azure integrated connection

Getting Keyword not supported: 'authentication' error while trying to connect an azure DB through 'Active Directory Integrated' option in .NET core 2.1 project.
Note: I am using EF core to connect the Data source.
TL;DR
As called out by #Aamir Mulla in the comments, this has officially been added since Version 2.0.0
UPDATE - 16/08/2019
Active Directory Password Authentication has now been added for .NET Core in Microsoft.Data.SqlClient 1.0.19221.1-Preview
Unfortunately, the authentication keyword is not yet fully supported in .NET Core. Here is an issue which discusses this.
But .NET Core 2.2 has added some support for this use case as mentioned in this comment. The basic idea is to get the access token by any means (ADAL, REST, etc.) and set SqlConnection.AccessToken to it.
As for using this with EF Core, there's a good discussion about this in this github issue and in particular the comment by mgolois provides a simple implementation to the solution that cbriaball mentions in the thread.
Here is the same for reference
Note that this sample is using the Microsoft.Azure.Services.AppAuthentication library
// DB Context Class
public class SampleDbContext : DbContext
{
public SampleDbContext(DbContextOptions<TeamsDbContext> options) : base(options)
{
var conn = (System.Data.SqlClient.SqlConnection)this.Database.GetDbConnection();
conn.AccessToken = (new AzureServiceTokenProvider()).GetAccessTokenAsync("https://database.windows.net/").Result;
}
}
// Startup.cs
services.AddDbContext<SampleDbContext>(options =>
{
options.UseSqlServer(<Connection String>);
});
The connection string would be something like this
Server=tcp:<server_name>.database.windows.net,1433;Database=<db_name>;
If you're still having the issue, make sure you have
Microsoft.Data.SqlClient package installed, not System.Data.SqlClient. They both contain SqlConnection class, switching the package for the first one fixed the issue for me.
As of today 7/18/2022 , I am still getting the issue from Azure when trying to use it through ManagedIdentity.
The microsoft doc at https://learn.microsoft.com/en-us/azure/app-service/tutorial-connect-msi-sql-database?tabs=windowsclient%2Cefcore%2Cdotnetcore
to use managed identity we need to use the connection string in this format!
"Server=tcp:.database.windows.net;Authentication=Active Directory Default; Database=;"
But looks like Azure is not liking it!
However, adding the access token helped!
var connectionString =
"Server=tcp:yourazuresqlservername.database.windows.net; Database=yourazuresqldbname;";
var con = new SqlConnection(connectionString);
//And then
con.AccessToken = (new AzureServiceTokenProvider()).GetAccessTokenAsync("https://database.windows.net/").Result;
con.Open();
//Do sql tasks
con.Close();

Issue with returning JArray from Azure Functions HttpTrigger

I'm trying to return JArray object from Azure Function of HttpTrigger type:
JArray a = JArray.Parse("[{\"reportId\": \"1111\",\"reportName\": \"AAAA\"}]");
return req.CreateResponse(HttpStatusCode.OK, a);
However, for some reason, the response body returned as:
[{"reportId":[],"reportName":[]}]
What am I doing wrong?
I can repro the issue with Newtonsoft.Json version 10+. If downgrade is possible, please have a try to use Newtonsoft.Json version 9.0.1. Then it works correctly on my side. We also could rasie an issue to Azure function team.
Azure Functions requires that you use Newtonsoft.Json version 9.0.1, as we don't support binding redirects. Your code is running in the same process as the Functions host, which means you have the same binding redirects.
We're improving the Visual Studio experience so that it's clear that there's a strict upper bound on the dependency.

Resources