在Azure Logic App中反序列化ServiceBus内容 [英] Deserializing ServiceBus content in Azure Logic App

查看:99
本文介绍了在Azure Logic App中反序列化ServiceBus内容的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在Azure Logic应用中读取消息的内容主体,但没有取得太大的成功.我看到了很多建议,这些建议说该主体是base64编码的,并建议使用以下内容进行解码:

I'm trying to read the content body of a message in an Azure Logic App, but I'm not having much success. I have seen a lot of suggestions which say that the body is base64 encoded, and suggest using the following to decode:

@{json(base64ToString(triggerBody()?['ContentData']))}

base64ToString(...)部分正在将内容正确解码为字符串,但是该字符串似乎在开头包含一个带有一些额外序列化信息的前缀:

The base64ToString(...) part is decoding the content into a string correctly, but the string appears to contain a prefix with some extra serialization information at the start:

@string3http://schemas.microsoft.com/2003/10/Serialization/�3{"Foo":"Bar"}

该字符串中还有一些多余的字符未在我的浏览器中显示.因此json(...)函数不接受输入,而是给出一个错误.

There are also some extra characters in that string that are not being displayed in my browser. So the json(...) function doesn't accept the input, and gives an error instead.

InvalidTemplate.无法在中处理模板语言表达式 行"1"和列"2451"的操作"HTTP"输入:模板 语言函数'json'参数无效.提供的价值 @string3http://schemas.microsoft.com/2003/10/Serialization/�3{"Foo":"bar" } 无法解析:Unexpected character encountered while parsing value: @. Path '', line 0, position 0..有关用法的详细信息,请参见 https://aka.ms/logicexpressions#json .

InvalidTemplate. Unable to process template language expressions in action 'HTTP' inputs at line '1' and column '2451': 'The template language function 'json' parameter is not valid. The provided value @string3http://schemas.microsoft.com/2003/10/Serialization/�3{"Foo":"bar" } cannot be parsed: Unexpected character encountered while parsing value: @. Path '', line 0, position 0.. Please see https://aka.ms/logicexpressions#json for usage details.'.

作为参考,使用.NET服务总线客户端将消息添加到该主题(客户端无关紧要,但这看起来有点像C#风格):

For reference, the messages are added to the topic using the .NET service bus client (the client shouldn't matter, but this looks rather C#-ish):

await TopicClient.SendAsync(new BrokeredMessage(JsonConvert.SerializeObject(item)));

如何在Logic App中将其作为JSON对象正确读取?

How can I read this correctly as a JSON object in my Logic App?

推荐答案

是由如何将消息放置在ServiceBus上(尤其是C#代码)引起的.我正在使用以下代码添加新消息:

This is caused by how the message is placed on the ServiceBus, specifically in the C# code. I was using the following code to add a new message:

var json = JsonConvert.SerializeObject(item);
var message = new BrokeredMessage(json);
await TopicClient.SendAsync(message);

此代码看起来不错,并且可以在不同的C#服务之间正常工作.问题是由BrokeredMessage(Object)构造函数序列化提供给它的有效负载的方式引起的:

This code looks fine, and works between different C# services no problem. The problem is caused by the way the BrokeredMessage(Object) constructor serializes the payload given to it:

通过将DataContractSerializer与二进制XmlDictionaryWriter结合使用,从给定的对象初始化BrokeredMessage类的新实例.

Initializes a new instance of the BrokeredMessage class from a given object by using DataContractSerializer with a binary XmlDictionaryWriter.

这意味着内容被序列化为二进制XML,该XML解释了前缀和无法识别的字符.反序列化时,C#实现将其隐藏,并返回您期望的对象,但是当使用其他库(例如Azure Logic Apps使用的库)时,该对象将变得显而易见.

That means the content is serialized as binary XML, which explains the prefix and the unrecognizable characters. This is hidden by the C# implementation when deserializing, and it returns the object you were expecting, but it becomes apparent when using a different library (such as the one used by Azure Logic Apps).

有两种方法可以解决此问题:

There are two alternatives to handle this problem:

  • 确保接收方可以处理二进制XML格式的消息
  • 确保发件人实际上使用了我们想要的格式,例如JSON.

帕科·德拉克鲁兹(Paco de la Cruz)的答案使用substringindexOflastIndexOf处理第一种情况:

Paco de la Cruz's answer handles the first case, using substring, indexOf and lastIndexOf:

@json(substring(base64ToString(triggerBody()?['ContentData']), indexof(base64ToString(triggerBody()?['ContentData']), '{'), add(1, sub(lastindexof(base64ToString(triggerBody()?['ContentData']), '}'), indexof(base64ToString(triggerBody()?['ContentData']), '}')))))

对于第二种情况,从根本上解决问题仅涉及使用BrokeredMessage(Stream)构造函数.这样,我们可以直接控制内容:

As for the second case, fixing the problem at the source simply involves using the BrokeredMessage(Stream) constructor instead. That way, we have direct control over the content:

var json = JsonConvert.SerializeObject(item);
var bytes = Encoding.UTF8.GetBytes(json);
var stream = new MemoryStream(bytes);
var message = new BrokeredMessage(stream, true);
await TopicClient.SendAsync(message);

这篇关于在Azure Logic App中反序列化ServiceBus内容的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆