Merge pull request #291261 from spelluru/freshness1202

Freshness, Acrolynx, and Learn Linter

Author: denrea

articles/event-hubs/schema-registry-overview.md

@@ -1,12 +1,13 @@
 ---
-title: Use Azure Schema Registry from Apache Kafka and other apps
+title: Azure Schema Registry in Azure Event Hubs
 description: This article provides an overview of Schema Registry support by Azure Event Hubs and how it can be used from your Apache Kafka and other apps.
-ms.topic: overview
-ms.date: 07/28/2023
+ms.topic: concept-article
+ms.date: 12/02/2024
 ms.custom: references_regions
+# Customer intent: As an Azure Event Hubs user, I want to know how Azure Event Hubs supports registering schemas and using them in sending and receiving events. 
 ---
 
-# Use Azure Schema Registry in Event Hubs from Apache Kafka and other apps
+# Azure Schema Registry in Event Hubs
 In many event streaming and messaging scenarios, the event or message payload contains structured data. Schema-driven formats such as [Apache Avro](https://avro.apache.org/) are often used to serialize or deserialize such structured data. 
 
 An event producer uses a schema to serialize event payload and publish it to an event broker such as Event Hubs. Event consumers read event payload from the broker and deserialize it using the same schema. So, both producers and consumers can validate the integrity of the data with the same schema. 
@@ -25,7 +26,7 @@ With schema-driven serialization frameworks like Apache Avro, moving serializati
 
 Having schemas stored alongside the events and inside the eventing infrastructure ensures that the metadata that's required for serialization or deserialization is always in reach and schemas can't be misplaced. 
 
-## Next steps
+## Related content
 
 - To learn more about Azure Schema registry, see [Azure Schema Registry Concepts](schema-registry-concepts.md).
 - To learn how to create a schema registry using the Azure portal, see [Create an Event Hubs schema registry using the Azure portal](create-schema-registry.md).

articles/service-bus-messaging/message-expiration.md

@@ -1,18 +1,15 @@
 ---
 title: Azure Service Bus - message expiration
 description: This article explains about expiration and time to live (TTL) of Azure Service Bus messages. After such a deadline, the message is no longer delivered.
-ms.topic: conceptual
-ms.date: 10/10/2023
+ms.topic: concept-article
+ms.date: 12/02/2024
+# Customer intent: As an Azure Service Bus user, developer or architect, I want to know whether the message enqueued expires after a certain amount of time. 
 ---
 
 # Azure Service Bus - Message expiration (Time to Live)
-The payload in a message, or a command or inquiry that a message conveys to a receiver, is almost always subject to some form of application-level expiration deadline. After such a deadline, the content is no longer delivered, or the requested operation is no longer executed.
-
-For development and test environments in which queues and topics are often used in the context of partial runs of applications or application parts, it's also desirable for stranded test messages to be automatically garbage collected so that the next test run can start clean.
-
-> [!NOTE]
-> If you aren't familiar with Service Bus concepts yet, see [Service Bus concepts](service-bus-messaging-overview.md#concepts), and [Service Bus queues, topics, and subscriptions](service-bus-queues-topics-subscriptions.md).
+The payload in a message, or a command or inquiry that a message conveys to a receiver, is almost always subject to some form of application-level expiration deadline. After such a deadline, the content is no longer delivered, or the requested operation is no longer executed. For development and test environments in which queues and topics are often used in the context of partial runs of applications or application parts, it's also desirable for stranded test messages to be automatically garbage collected so that the next test run can start clean.
 
+## Time to live and expires at UTC
 The expiration for any individual message can be controlled by setting the **time-to-live** system property, which specifies a relative duration. The expiration becomes an absolute instant when the message is enqueued into the entity. At that time, the **expires-at-utc** property takes on the value **enqueued-time-utc** + **time-to-live**. The time-to-live (TTL) setting on a brokered message isn't enforced when there are no clients actively listening.
 
 > [!NOTE]
@@ -22,15 +19,15 @@ Past the **expires-at-utc** instant, messages become ineligible for retrieval. T
 
 Extremely low TTL in the order of milliseconds or seconds might cause messages to expire before receiver applications receive it. Consider the highest TTL that works for your application.
 
-> [!NOTE]
-> For [scheduled messages](message-sequencing.md#scheduled-messages), you specify the enqueue time at which you want the message to materialize in the queue for retrieval. The time at which the message is sent to Service Bus is different from the time at which the message is enqueued. The message expiration time depends on the enqueued time, not on the time at which the message is sent to Service Bus. Therefore, the **expires-at-utc** is still **enqueued time + time-to-live**. 
->
-> For example, if you set the `ScheduledEnqueueTimeUtc` to 5 minutes from `UtcNow`, and `TimeToLive` to 10 minutes, the message will expire after 5 + 10 = 15 minutes from now. The message materializes in the queue after 5 minutes and the 10 minute counter starts from then.
+## Scheduled messages
+For [scheduled messages](message-sequencing.md#scheduled-messages), you specify the enqueue time at which you want the message to materialize in the queue for retrieval. The time at which the message is sent to Service Bus is different from the time at which the message is enqueued. The message expiration time depends on the enqueued time, not on the time at which the message is sent to Service Bus. Therefore, the **expires-at-utc** is still **enqueued time + time-to-live**. 
+
+For example, if you set the `ScheduledEnqueueTimeUtc` to 5 minutes from `UtcNow`, and `TimeToLive` to 10 minutes, the message will expire after 5 + 10 = 15 minutes from now. The message materializes in the queue after 5 minutes and the 10 minute counter starts from then.
 
 ## Entity-level expiration
 All messages sent into a queue or topic are subject to a default expiration that is set at the entity level. It can also be set in the portal during creation and adjusted later. The default expiration is used for all messages sent to the entity where time-to-live isn't explicitly set. The default expiration also functions as a ceiling for the time-to-live value. Messages that have a longer time-to-live expiration than the default value are silently adjusted to the default message time-to-live value before being enqueued.
 
-The **expires-at-utc** is by design. If the message TTL is not set and only the entity TTL is set then **expires-at-utc**  is a computed value and is not computed in the Peek path but is computed in the Receive/Peeklock path. If the message has TTL then this **expires-at-utc** is computed at the time message is sent and stored. So in this case Peek will return correct **expires-at-utc** values.
+The **expires-at-utc** is by design. If the message TTL isn't set and only the entity TTL is set then **expires-at-utc**  is a computed value and isn't computed in the Peek path but is computed in the Receive/Peeklock path. If the message has TTL then this **expires-at-utc** is computed at the time message is sent and stored. So in this case Peek will return correct **expires-at-utc** values.
 
 > [!NOTE]
 > - The default time-to-live value for a brokered message is the largest possible value for a signed 64-bit integer if not otherwise specified.
@@ -71,6 +68,7 @@ Here's what considered idleness of entities (queues, topics, and subscriptions):
 > If you have auto forwarding setup on the queue or subscription, that is equivalent to having a receiver peform receives on the queue or subscription and they will not be idle.
  
 ## SDKs
+You can set the time-to-live property using Software Development Kits (SDKs). 
 
 - To set time-to-live on a message: [.NET](/dotnet/api/azure.messaging.servicebus.servicebusmessage.timetolive), [Java](/java/api/com.azure.messaging.servicebus.servicebusmessage.settimetolive), [Python](/python/api/azure-servicebus/azure.servicebus.servicebusmessage), [JavaScript](/javascript/api/@azure/service-bus/servicebusmessage#@azure-service-bus-servicebusmessage-timetolive)
 - To set the default time-to-live on a queue: [.NET](/dotnet/api/azure.messaging.servicebus.administration.createqueueoptions.defaultmessagetimetolive), [Java](/java/api/com.azure.messaging.servicebus.administration.models.createqueueoptions.setdefaultmessagetimetolive), [Python](/python/api/azure-servicebus/azure.servicebus.management.queueproperties), [JavaScript](/javascript/api/@azure/service-bus/queueproperties#@azure-service-bus-queueproperties-defaultmessagetimetolive)
@@ -79,23 +77,9 @@ Here's what considered idleness of entities (queues, topics, and subscriptions):
 
 
 
-## Next steps
-
-To learn more about Service Bus messaging, see the following articles: 
-
-- [Message sequencing and time stamps](message-sequencing.md)
-- [Messages, payloads, and serialization](service-bus-messages-payloads.md)
-- [Message sessions](message-sessions.md)
-- [Duplicate message detection](duplicate-detection.md)
-- [Topic filters](topic-filters.md)
-- [Message browsing](message-browsing.md)
-- [Message transfers, locks, and settlement](message-transfers-locks-settlement.md)
-- [Dead-letter queues](service-bus-dead-letter-queues.md)
-- [Message deferral](message-deferral.md)
-- [Prefetch messages](service-bus-prefetch.md)
-- [Autoforward messages](service-bus-auto-forwarding.md)
-- [Transaction support](service-bus-transactions.md)
-- [Geo-disaster recovery](service-bus-geo-dr.md)
-- [Asynchronous messaging patterns and high availability](service-bus-async-messaging.md)
-- [Handling outages and disasters](service-bus-outages-disasters.md)
-- [Throttling](service-bus-throttling.md)
+## Related content
+
+If you aren't familiar with Service Bus concepts yet, see [Service Bus concepts](service-bus-messaging-overview.md#concepts), and [Service Bus queues, topics, and subscriptions](service-bus-queues-topics-subscriptions.md).
+
+To learn about advanced features of Azure Service Bus, see [Overview of advanced features](advanced-features-overview.md). 
+

articles/service-bus-messaging/service-bus-amqp-overview.md

@@ -1,8 +1,9 @@
 ---
 title: Overview of AMQP 1.0 in Azure Service Bus
 description: Learn how Azure Service Bus supports Advanced Message Queuing Protocol (AMQP), an open standard protocol.
-ms.topic: article
-ms.date: 08/16/2023
+ms.topic: concept-article
+ms.date: 12/02/2024
+# Customer intent: As an Azure Service Bus user, I want to know how Azure Service Bus supports the AMQP protocol. 
 ---
 
 # Advanced Message Queueing Protocol (AMQP) 1.0 support in Service Bus
@@ -71,10 +72,8 @@ In addition, you can use Service Bus from any AMQP 1.0 compliant protocol stack:
 
 [!INCLUDE [messaging-oss-amqp-stacks.md](../../includes/messaging-oss-amqp-stacks.md)]
 
-## Summary
-* AMQP 1.0 is an open, reliable messaging protocol that you can use to build cross-platform, hybrid applications. AMQP 1.0 is an OASIS standard.
 
-## Next steps
+## Related content
 Ready to learn more? Visit the following links:
 
 * [Using Service Bus from .NET with AMQP]

articles/service-bus-messaging/service-bus-ip-filtering.md

@@ -1,9 +1,10 @@
 ---
 title: Configure IP firewall rules for Azure Service Bus
-description: How to use Firewall Rules to allow connections from specific IP addresses to Azure Service Bus. 
-ms.topic: article
+description: This article describes how to use Firewall Rules to allow connections from specific IP addresses to Azure Service Bus. 
+ms.topic: how-to
 ms.custom: devx-track-azurecli, devx-track-azurepowershell
-ms.date: 10/10/2023
+ms.date: 12/02/2024
+# Customer intent: As an IT administrator, I would like to know how to configure IP firewall rules for an Azure Service Bus namespace. 
 ---
 
 # Allow access to Azure Service Bus namespace from specific IP addresses or ranges
@@ -15,7 +16,7 @@ This feature is helpful in scenarios in which Azure Service Bus should be only a
 The IP firewall rules are applied at the Service Bus namespace level. Therefore, the rules apply to all connections from clients using any **supported protocol** (AMQP (5671) and HTTPS (443)). Any connection attempt from an IP address that doesn't match an allowed IP rule on the Service Bus namespace is rejected as unauthorized. The response doesn't mention the IP rule. IP filter rules are applied in order, and the first rule that matches the IP address determines the accept or reject action.
 
 ## Important points
-- Virtual Networks are supported only in the **premium** tier of Service Bus. If upgrading to the **premium** tier isn't an option, it's possible to use IP firewall rules. We recommend that you keep the Shared Access Signature (SAS) token secure and share it with only authorized users. For information about SAS authentication, see [Authentication and authorization](service-bus-authentication-and-authorization.md#shared-access-signature).
+- Virtual Networks are supported only in the **premium** tier of Service Bus. If upgrading to the **premium** tier isn't an option, it's possible to use IP firewall rules using [Azure Resource Manager templates](#use-resource-manager-template), [Azure CLI](#use-azure-cli), [PowerShell](#use-azure-powershell) or [REST API](#rest-api). We recommend that you keep the Shared Access Signature (SAS) token secure and share it with only authorized users. For information about SAS authentication, see [Authentication and authorization](service-bus-authentication-and-authorization.md#shared-access-signature).
 - Specify **at least one IP firewall rule or virtual network rule** for the namespace to allow traffic only from the specified IP addresses or subnet of a virtual network. If there are no IP and virtual network rules, the namespace can be accessed over the public internet (using the access key).  
 - Implementing firewall rules can prevent other Azure services from interacting with Service Bus. As an exception, you can allow access to Service Bus resources from certain **trusted services** even when IP filtering is enabled. For a list of trusted services, see [Trusted services](#trusted-microsoft-services). 
 
@@ -156,11 +157,11 @@ Use the following Azure PowerShell commands to add, list, remove, update, and de
 
 ### REST API
 
-The default value of the `defaultAction` property was `Deny` for API version **2021-01-01-preview and earlier**. However, the deny rule isn't enforced unless you set IP filters or virtual network (VNet) rules. That is, if you didn't have any IP filters or VNet rules, it's treated as `Allow`. 
+The default value of the `defaultAction` property was `Deny` for API version **2021-01-01-preview and earlier**. However, the deny rule isn't enforced unless you set IP filters or virtual network rules. That is, if you didn't have any IP filters or virtual network rules, Service Bus treats it as `Allow`. 
 
-From API version **2021-06-01-preview onwards**, the default value of the `defaultAction` property is `Allow`, to accurately reflect the service-side enforcement. If the default action is set to `Deny`, IP filters and VNet rules are enforced. If the default action is set to `Allow`, IP filters and VNet rules aren't enforced. The service remembers the rules when you turn them off and then back on again. 
+From API version **2021-06-01-preview onwards**, the default value of the `defaultAction` property is `Allow`, to accurately reflect the service-side enforcement. If the default action is set to `Deny`, IP filters and virtual network rules are enforced. If the default action is set to `Allow`, IP filters and virtual network rules aren't enforced. The service remembers the rules when you turn them off and then back on again. 
 
-The API version **2021-06-01-preview onwards** also introduces a new property named `publicNetworkAccess`. If it's set to `Disabled`, operations are restricted to private links only. If it's set to `Enabled`, operations are allowed over the public internet. 
+The API version **2021-06-01-preview onwards** also introduces a new property named `publicNetworkAccess`. If you set it to `Disabled`, operations are restricted to private links only. If you set it to `Enabled`, operations are allowed over the public internet. 
 
 For more information about these properties, [Create or Update Private Endpoint Connections](/rest/api/servicebus/controlplane-preview/private-endpoint-connections/create-or-update).
 
@@ -169,11 +170,11 @@ For more information about these properties, [Create or Update Private Endpoint
 
 ### Azure portal
 
-Azure portal always uses the latest API version to get and set properties.  If you had previously configured your namespace using **2021-01-01-preview and earlier** with `defaultAction` set to `Deny`, and specified zero IP filters and VNet rules, the portal would have previously checked **Selected Networks** on the **Networking** page of your namespace. Now, it checks the **All networks** option. 
+Azure portal always uses the latest API version to get and set properties. If you previously configured your namespace using **2021-01-01-preview and earlier** with `defaultAction` set to `Deny`, and specified zero IP filters and virtual network rules, the portal would have previously checked **Selected Networks** on the **Networking** page of your namespace. Now, it checks the **All networks** option. 
 
 :::image type="content" source="./media/service-bus-ip-filtering/firewall-all-networks-selected.png" alt-text="Screenshot of the Azure portal Networking page. The option to allow access from All networks is selected on the Firewalls and virtual networks tab.":::
 
-## Next steps
+## Related content
 
 For constraining access to Service Bus to Azure virtual networks, see the following link: