jsquire

Microsoft Messaging: AMQP client library (early concept)

The high-level goal for the Microsoft Messaging client library is to provides a unified experience for core messaging scenarios needed by developers wishing to interact with Microsoft Fabric, Azure Event Grid, Azure Service Bus, and Azure Event Hubs.

Things to know before reading

• The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during discussions.

• Some details not related to the high-level messaging operations are not illustrated; the scope of this is limited to the high level shape and paradigms for the feature area.

jsquire

Event Grid: AMQP (early concept)

Things to know before reading

• The names used in this document are intended for illustration only. Some names are not ideal and will need to be refined during discussions.

• Some details not related to the high-level concept are not illustrated; the scope of this is limited to the high level shape and paradigms for the feature area.

• Fake methods are used to illustrate "something needs to happen, but the details are unimportant." As a general rule, if an operation is not directly related to one of the Event Grid types, it can likely be assumed that it is for illustration only. These methods will most often use ellipses for the parameter list, in order to help differentiate them.

jsquire

Connections

Create connection

• Use AMQP version 1.0.0.0

• Use SASL with "MSSBCBS" as the mechanism name

• Authorize via CBS to a dedicated link named "$cbs"

jsquire

Service Bus: Batch Delete

Currently, when messages are sent to Service Bus, they can only be removed by reading/completing them or waiting for them to age-out based on the retention policy. This can often become troublesome for applications that accumulate messages in their dead-letter queue when they do not wish to process them, or for applications with messages that are not actionable after a certain age.

Historically, developers have had to write code that loops to perform destructive reads for the messages that they want to remove. While this is relatively straightforward for purge scenarios, it can be tricky to do correctly when the desire is only to remove messages older than a given point in time.

To make this scenario easier for developers, Service Bus is adding a new operation capable of deleting batches of messages and limiting them to a specific time.

Goals

jsquire

Overview

Issues in the Azure SDK repositories use a two label system in order to classify the issue and identify the responsible party. Each issue must have a "service label" (pink) and a "category label" (yellow) to be valid. It is this combination of labels that identifies which specific library an issue is for and, by extension, who should be responsible for the issue. For example, an issue tagged with Event Hubs and Client is owned by Jesse's team. An issue tagged with Event Hubs and Mgmt is owned by Arthur's team.

This constraint is built into the AI label service; if it cannot successfully predict both labels, it will return none. When performing automated triage, the rule will always have access to both tags and needs to take both into account to find the correct owner to triage the issue to. Currently, this is not how triage handles the scenario. Instead, the rule will collect the owners of both tags and consider them both owners. For example, an issue tagged with Event Hubs and

jsquire

Azure SDK: Target frameworks and polyfill packages

Problem statement

Developers using the Azure SDK on modern versions of .NET are required to download unnecessary packages that serve as polyfills for the legacy .NET framework and unsupported versions of .NET Core.

Impact

Developers are faced with longer build times, increased application size, and unnecessary network use.

jsquire

Azure SDK for .NET repository issue rules and process

Goal

This document attempts to define the set of rules used for triaging and managing issues in the Azure SDK for .NET repository. These rules were once part of a standardized process owned by Alex Ghiondea and were at least loosely followed in the other language repositories. It is unknown whether there has been drift in the processes between languages since.

History

At one point, these were documented in OneNote and then moved to a DevOps wiki, and then moved again. I do not know where the documentation exists today - if it still does. All that I'm aware of is a high-level view of the process.

jsquire

AppConfiguration: Data loss with strongly typed settings

Overview

The general form of settings stored in AppConfiguration are simple key/value string pairs, where both have no formal structure. AppConfiguration also has the notion of "feature flag" and "secret reference" configuration settings, which are loosely structured data, conforming to a minimal and extensible JSON schema. These settings are expected to include all elements from the JSON schema but are also permitted to include additional data in the form of simple or complex elements.

Primary champion scenario

• A developer creates settings in the portal, using a combination of the schema entry form and advanced JSON-centric view for custom attributes.
• The settings are read by a client application using a platform integration package owned by the service team owns (e.g. ASP.NET, Spring).

jsquire

// Package Reference: Azure.Data.AppConfiguration
// Package Reference: System.Text.Json
  
using Azure;
using Azure.Core;
using Azure.Core.Pipeline;
using Azure.Data.AppConfiguration;
using System.Threading.Tasks;
using System.Text.Json;
using System.Text.Json.Serialization;

jsquire

Schema Registry: JSON Serializer

Azure Schema Registry currently supports the Avro schema type and is adding support for JSON Schema. The Azure SDK library for Schema Registry offers an Avro serializer that is integrated with the Schema Registry client. In order to provide parity between the schema formats, serializer support for JSON Schema with a developer experience consistent with Avro is needed.

Business impact

• Contributes to the Kafka/Confluent compete story for Event Hubs. (marketing "checkbox" feature)

• Contributes to the Kafka interoperability story for Event Hubs, focusing on cross-product producing and consuming scenarios. (marketing "checkbox" feature)

• Enables a consistent developer experience with Schema Registry across different schema formats, reducing support costs and special-case documentation needs.