当前位置: 首页 > 知识库问答 >
问题:

拒绝Azure函数中的服务总线连接字符串

周超英
2023-03-14

我正在使用Azure功能完成本指南,以将IoTHub消息提交到Azure存储。我在第5d节,在那里我需要为我的函数创建一个新的服务总线连接字符串,但无论我使用什么,包括指南中的格式:

Endpoint=<Event Hub-compatible endpoint>;SharedAccessKeyName=iothubowner;SharedAccessKey=<Primary key>

我得到一个错误:

不是有效的服务总线连接字符串。

我尝试使用IoT中心endpoint中的事件中心兼容endpoint,以及iothubboss访问策略中的连接字符串-主键,但它再次拒绝它。

然后我创建了一个新的服务总线,并使用了这个连接(见下面我的回答和最初的乐观!)但是当我试图编辑函数时,我得到了一个404吐司通知:

函数($DeviceDataToStorage)错误:函数的函数的侦听器。DeviceDataToStorage“无法启动。微软ServiceBus:消息传递实体的管理操作失败。状态代码:404,状态描述:找不到消息实体'sb://{已接受的MY SERVICE BUS连接字符串}/{EVENTHUBNAME}'找不到。

以前使用过Azure功能的任何人是否可以建议这需要采用什么格式,或者更重要的是,我可以从门户中的什么位置获得这些功能?

共有2个答案

慕容玉书
2023-03-14

根据你的描述,我检查了这个问题。正如“准备物联网集线器连接以读取消息”所述,您需要为物联网集线器endpoint构建连接字符串,如下所示:

Endpoint={与事件中心兼容的endpoint}; SharedAccessKeyName=iothubOwers; SharedAccessKey={主键}

将{Event Hub compatible endpoint}替换为:

将{Primary key}替换为:

不是有效的服务总线连接字符串。

我假设您在创建新的事件中心连接时遇到此错误,如下所示:

为事件中心添加新连接字符串时,应该如下所示:

注意:我假设您混淆了服务总线连接字符串和物联网集线器连接字符串。

服务总线的连接字符串:

Endpoint=sb://{您的servicebus名称}。服务总线。窗户。净/;SharedAccessKeyName={SharedAccessKeyName};SharedAccessKey={SharedAccessKey}

尹凌龙
2023-03-14

我原以为我知道了,但我没有。这是我认为有效的,但没有

*

教程中缺少它,但是您需要手动创建一个新的服务总线终结点(参见https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-get-started-with-queues),并从共享访问策略RootManageSharedAccessKey策略中复制CONNECTIONSTRING-PRIMARYKEY

*

 类似资料:
  • 我需要将一条消息从运行在SQL Server2014下的SSIS包放入Azure ServiceBus队列中。正如本文所建议的:从ssis连接到azure服务总线队列,我编写了一个引用“azure SDK2.9”的脚本任务。这种方法适用于Azure存储帐户处理Blob(引用Microsoft.WindowsAzure.Storage程序集),但不适用于Azure存储总线(引用Microsoft.S

  • 下面的电话 返回此错误: "找不到有效的帐户信息组合。" 使用直接从Azure service Bus访问策略上的连接字符串–主键字段复制的连接字符串- endpoint=sb://xxx。服务总线。窗户。净/;SharedAccessKeyName=xxx;SharedAccessKey=xxx;EntityPath=xxx 我需要CloudQueueClient和CloudQueue实例来执行

  • 我是库伯内特斯的初学者。我正在尝试安装迷你库贝,想在库伯内特斯中运行我的应用程序。我正在使用乌班图 16.04 我已遵循此处提供的安装说明https://kubernetes.io/docs/setup/learning-environment/minikube/#using-带有http代理的minikube 问题1:在安装了kubectl、virtualbox和minikube之后,我运行了命

  • 我目前正在评估使用一个服务总线和azure函数来触发一些需要通过下游api调用来完成的工作。这都是相当标准的,只是我没有很好地处理当下游系统过载和/或返回header到trottle时会发生什么(即每分钟最大调用数/等)。对于队列触发器的强制节流,我们似乎没有任何动态控制。 我知道我们可以手动设置最大并发,但这并不一定解决问题,因为我们无法控制下游系统,需要考虑它随时可能脱机或变慢。 假设消费计划

  • 我正在尝试连接两个docker容器,一个是posgresql,另一个是python flask应用程序。两者都链接正确,python应用程序中的所有连接变量都直接取自postgres容器中通过链接公开的连接变量,并且与检查postgresql容器时发现的连接变量相同。当我将psql与连接字符串中的精确参数一起使用时,即: 成功连接到postgres容器中的数据库,因此我知道postgres正在通过

  • 在.NET core 2.0中使用创建时,我遇到了一个问题。 在体系结构中,当在用于创建用户的队列中创建新消息时,服务必须接收该消息并根据其中的信息在数据库中创建用户。 在Visual Studio2017中,我在下创建了一个新项目。 这种的正确实现是什么?在GitHub上有什么例子吗?提前道谢。