【问题标题】:Deserialize strongly typed object from Azure Service Bus Queue (v1) using BrokeredMessage使用 BrokeredMessage 从 Azure 服务总线队列 (v1) 反序列化强类型对象
【发布时间】:2018-10-02 16:04:40
【问题描述】:

无论出于何种原因,我似乎都无法弄清楚如何将我的对象从队列中拉出并将其反序列化回放入其中的内容(An AccountEventDTO)。

Azure 函数成功将对象放入队列:

[FunctionName("AccountCreatedHook")]
public static async Task<HttpResponseMessage> Run([HttpTrigger(AuthorizationLevel.Function, "post", Route = null)]HttpRequestMessage req,
    TraceWriter log, [ServiceBus("topic-name", Connection = "BusConnectionString", EntityType = Microsoft.Azure.WebJobs.ServiceBus.EntityType.Topic)] IAsyncCollector<BrokeredMessage> accountCreatedTopic)
{
    var accountEvent = await req.Content.ReadAsAsync<AccountEventDTO>();

    if (accountEvent != null && accountEvent.Name != null)
    {
        // Serialization
        var bytes = Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(accountEvent));
        var memoryStream = new MemoryStream(bytes, writable: false);
        var message = new BrokeredMessage(memoryStream) { SessionId = Guid.NewGuid().ToString() };

        await accountCreatedTopic.AddAsync(message);
        return req.CreateResponse(HttpStatusCode.OK, "Account successfully added to topic.");
    }

    return req.CreateResponse(HttpStatusCode.BadRequest, "Account was not formed well.");
}

Azure 函数从队列中拉取对象:

[FunctionName("AccountCreatedSubscriber")]
public static void Run([ServiceBusTrigger("topic-name", "license-keys", Connection = "BusConnectionString")]BrokeredMessage accountEvent, ILogger log)
{
    // ERROR on this line during deserialization
    var account = accountEvent.GetBody<AccountEventDTO>();

    var accountAddedEvent = Mapper.Map<AccountEventDTO, AccountAddedEvent>(account);
    _accountHandler.Handle(accountAddedEvent);
    GenericLogger.AccountLogging(log, accountAddedEvent);
}

错误信息:

AccountEventDTO:

public class AccountEventDTO : IAccountEvent
{
    public string Name { get; set; }
    public string SugarId { get; set; }
    public string AccountSubTypeRaw { get; set; }
    public AccountType AccountType { get; set; } = AccountType.Customer;
    public AccountSubType? AccountSubType { get; set; } = null;
    public string Phone { get; set; }
    public string PhoneAlternate { get; set; }
    public string BillingAddressCity { get; set; }
    public string BillingAddressCountry { get; set; }
    public string BillingAddressPostalCode { get; set; }
    public string BillingAddressState { get; set; }
    public string BillingAddressStreet { get; set; }
    public string ShippingAddressCity { get; set; }
    public string ShippingAddressCountry { get; set; }
    public string ShippingAddressPostalCode { get; set; }
    public string ShippingAddressState { get; set; }
    public string ShippingAddressStreet { get; set; }
    public string Website { get; set; }
}

【问题讨论】:

  • 需要设置 sessionid 吗?我问它是因为您可以避免操纵代理消息并直接与您的 POCO 合作
  • 是的。我们的主题依赖 FIFO,并且必须有一个 sessionid 才能确保这一点。

标签: c# azure azure-functions azureservicebus azure-servicebus-topics


【解决方案1】:

您正在使用BrokeredMessage(用于 .NET 的旧 Azure 服务总线客户端,WindowsAzure.ServiceBus)。当消息作为内存流发送时,必须使用相同的方法对其进行接收和反序列化。如果您构造 BrokeredMessage 并传入 T 类型的对象,GetBody&lt;T&gt; 将起作用。

注意:下一代客户端 (Microsoft.Azure.ServiceBus) 仅适用于原始字节数组(旧客户端的内存流)。如果这是一个新项目,建议坚持使用这种方法而不是序列化类型。更多信息可在 GitHub 问题here 中获得。

【讨论】:

  • 我完全同意,有一些原因我暂时必须坚持使用 v1,但您的回答为我指明了正确的方向,谢谢。
  • 设计原理:在最新的 Microsoft.Azure.ServiceBus 中删除了内置 POCO 序列化支持。这是因为“虽然这种隐藏的序列化魔法很方便,但应用程序应该明确控制对象序列化并将其对象图转换为流,然后再将它们包含到消息中,并在接收端执行相反的操作。这会产生可互操作的结果。” docs.microsoft.com/en-us/azure/service-bus-messaging/…
【解决方案2】:

最终通过改变我在发送端序列化我的消息的方式以及我在接收端拉下它的方式来解决这个问题。

发送序列化:

var jsonString = JsonConvert.SerializeObject(accountEvent);
var message = new BrokeredMessage(jsonString);
message.SessionId = Guid.NewGuid().ToString();
message.ContentType = "application/json";

接收反序列化:

var content = accountEvent.GetBody<string>();
var account = JsonConvert.DeserializeObject<AccountEventDTO>(content);

【讨论】:

    猜你喜欢
    • 2015-01-03
    • 1970-01-01
    • 1970-01-01
    • 2018-06-27
    • 2017-02-25
    • 1970-01-01
    • 2015-07-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多