Freshness review - 11-12

Author: spelluru

articles/event-grid/security-authentication.md

@@ -1,8 +1,9 @@
 ---
-title: Authenticate event delivery to event handlers (Azure Event Grid)
+title: Authenticate event delivery to event handlers
 description: This article describes different ways of authenticating delivery to event handlers in Azure Event Grid. 
-ms.topic: conceptual
-ms.date: 08/31/2023
+ms.topic: concept-article
+ms.date: 11/12/2024
+# Customer intent: I want to learn how to authenticate delivery of events to event handlers. 
 ---
 
 # Authenticate event delivery to event handlers (Azure Event Grid)
@@ -14,7 +15,7 @@ Azure Event Grid uses different authentication methods to deliver events to even
 | Authentication method | Supported event handlers | Description  |
 |--|--|--|
 Access key | - Event Hubs<br/>- Service Bus<br/>- Storage Queues<br/>- Relay Hybrid Connections<br/>- Azure Functions<br/>- Storage Blobs (Deadletter) | Access keys are fetched using Event Grid service principal's credentials. The permissions are granted to Event Grid when you register the Event Grid resource provider in their Azure subscription. |  
-Managed System Identity <br/>&<br/> Role-based access control | - Event Hubs<br/>- Service Bus<br/>- Storage Queues<br/>- Storage  Blobs (Deadletter) | Enable managed system identity for the topic and add it to the appropriate role on the destination. For details, see [Use system-assigned identities for event delivery](#use-system-assigned-identities-for-event-delivery).  |
+Managed System Identity <br/>&<br/> Role-based access control | - Event Hubs<br/>- Service Bus<br/>- Storage Queues<br/>- Storage  Blobs (Deadletter) | Enable managed system identity for the topic and add it to the appropriate role on the destination. For details, see [Use system-assigned identities for event delivery](#use-system-assigned-identities-for-event-delivery). |
 |Bearer token authentication with Microsoft Entra protected webhook | Webhook | See the [Authenticate event delivery to webhook endpoints](#authenticate-event-delivery-to-webhook-endpoints) section for details. |
 Client secret as a query parameter | Webhook | See the [Using client secret as a query parameter](#using-client-secret-as-a-query-parameter) section for details. |
 
@@ -26,7 +27,7 @@ You can enable a system-assigned managed identity for a topic or domain and use
 
 Here are the steps: 
 
-1. Create a topic or domain with a system-assigned identity, or update an existing topic or domain to enable identity. For more information, see [Enable managed identity for a system topic](enable-identity-system-topics.md) or [Enable managed identity for a custom topic or a domain](enable-identity-custom-topics-domains.md)
+1. Create a topic or domain with a system-assigned identity, or enable identity on an existing topic or domain. For more information, see [Enable managed identity for a system topic](enable-identity-system-topics.md) or [Enable managed identity for a custom topic or a domain](enable-identity-custom-topics-domains.md)
 1. Add the identity to an appropriate role (for example, Service Bus Data Sender) on the destination (for example, a Service Bus queue). For more information, see [Grant identity the access to Event Grid destination](add-identity-roles.md)
 1. When you create event subscriptions, enable the usage of the identity to deliver events to the destination. For more information, see [Create an event subscription that uses the identity](managed-service-identity.md). 
 
@@ -54,5 +55,5 @@ For more information on delivering events to webhooks, see [Webhook event delive
 If you're already familiar with Event Grid, you might be aware of the endpoint validation handshake for preventing abuse. CloudEvents v1.0 implements its own [abuse protection semantics](end-point-validation-cloud-events-schema.md) by using the **HTTP OPTIONS** method. To read more about it, see [HTTP 1.1 Web Hooks for event delivery - Version 1.0](https://github.com/cloudevents/spec/blob/v1.0/http-webhook.md#4-abuse-protection). When you use the CloudEvents schema for output, Event Grid uses the CloudEvents v1.0 abuse protection in place of the Event Grid validation event mechanism. For more information, see [Use CloudEvents v1.0 schema with Event Grid](cloud-event-schema.md). 
 
 
-## Next steps
+## Related content
 See [Authenticate publishing clients](security-authenticate-publishing-clients.md) to learn about authenticating clients publishing events to topics or domains. 

articles/event-hubs/event-hubs-auto-inflate.md

@@ -3,7 +3,7 @@ title: Automatically scale up throughput units in Azure Event Hubs
 description: Enable Auto-inflate on a namespace to automatically scale up throughput units (standard tier).
 ms.topic: article
 ms.custom: devx-track-arm-template
-ms.date: 07/28/2023
+ms.date: 11/12/2024
 ---
 
 # Automatically scale up Azure Event Hubs throughput units (standard tier) 

articles/service-bus-messaging/service-bus-amqp-protocol-guide.md

@@ -2,7 +2,7 @@
 title: AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide | Microsoft Docs
 description: Protocol guide to expressions and description of AMQP 1.0 in Azure Service Bus and Event Hubs
 ms.topic: article
-ms.date: 06/08/2023
+ms.date: 11/12/2024
 ---
 
 # AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide
@@ -263,10 +263,10 @@ To begin transactional work, the controller must obtain a `txn-id` from the coor
 
 | Client (Controller) | Direction | Service Bus (Coordinator) |
 | :--- | :---: | :--- |
-| attach(<br/>name={link name},<br/>... ,<br/>role=**sender**,<br/>target=**Coordinator**<br/>) | ------> |  |
-|  | <------ | attach(<br/>name={link name},<br/>... ,<br/>target=Coordinator()<br/>) |
-| transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (**Declare()**)}| ------> |  |
-|  | <------ | disposition( <br/> first=0, last=0, <br/>state=**Declared**(<br/>**txn-id**={transaction ID}<br/>))|
+| `attach(<br/>name={link name},<br/>... ,<br/>role=**sender**,<br/>target=**Coordinator**<br/>)` | ------> |  |
+|  | <------ | `attach(<br/>name={link name},<br/>... ,<br/>target=Coordinator()<br/>)` |
+| `transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (**Declare()**)}`| ------> |  |
+|  | <------ | `disposition( <br/> first=0, last=0, <br/>state=**Declared**(<br/>**txn-id**={transaction ID}<br/>))`|
 
 #### Discharging a transaction
 
@@ -276,33 +276,33 @@ The controller concludes the transactional work by sending a `discharge` message
 
 | Client (Controller) | Direction | Service Bus (Coordinator) |
 | :--- | :---: | :--- |
-| transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}| ------> |  |
-|  | <------ | disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))|
+| `transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}`| ------> |  |
+|  | <------ | `disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))`|
 | | . . . <br/>Transactional work<br/>on other links<br/> . . . |
-| transfer(<br/>delivery-id=57, ...)<br/>{ AmqpValue (<br/>**Discharge(txn-id=0,<br/>fail=false)**)}| ------> |  |
-| | <------ | disposition( <br/> first=57, last=57, <br/>state=**Accepted()**)|
+| `transfer(<br/>delivery-id=57, ...)<br/>{ AmqpValue (<br/>**Discharge(txn-id=0,<br/>fail=false)**)}`| ------> |  |
+| | <------ | `disposition( <br/> first=57, last=57, <br/>state=**Accepted()**)`|
 
 #### Sending a message in a transaction
 
 All transactional work is done with the transactional delivery state `transactional-state` that carries the txn-id. When sending messages, the transactional-state is carried by the message's transfer frame. 
 
 | Client (Controller) | Direction | Service Bus (Coordinator) |
 | :--- | :---: | :--- |
-| transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}| ------> |  |
-|  | <------ | disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))|
-| transfer(<br/>handle=1,<br/>delivery-id=1, <br/>**state=<br/>TransactionalState(<br/>txn-id=0)**)<br/>{ payload }| ------> |  |
-| | <------ | disposition( <br/> first=1, last=1, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**))|
+| `transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}`| ------> |  |
+|  | <------ | `disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))`|
+| `transfer(<br/>handle=1,<br/>delivery-id=1, <br/>**state=<br/>TransactionalState(<br/>txn-id=0)**)<br/>{ payload }`| ------> |  |
+| | <------ | `disposition( <br/> first=1, last=1, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**))`|
 
 #### Disposing a message in a transaction
 
 Message disposition includes operations like `Complete` / `Abandon` / `DeadLetter` / `Defer`. To perform these operations within a transaction, pass the `transactional-state` with the disposition.
 
 | Client (Controller) | Direction | Service Bus (Coordinator) |
 | :--- | :---: | :--- |
-| transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}| ------> |  |
-|  | <------ | disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))|
-| | <------ |transfer(<br/>handle=2,<br/>delivery-id=11, <br/>state=null)<br/>{ payload }|  
-| disposition( <br/> first=11, last=11, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**))| ------> |
+| `transfer(<br/>delivery-id=0, ...)<br/>{ AmqpValue (Declare())}`| ------> |  |
+|  | <------ | `disposition( <br/> first=0, last=0, <br/>state=Declared(<br/>txn-id={transaction ID}<br/>))`|
+| | <------ |`transfer(<br/>handle=2,<br/>delivery-id=11, <br/>state=null)<br/>{ payload }`|  
+| `disposition( <br/> first=11, last=11, <br/>state=**TransactionalState(<br/>txn-id=0,<br/>outcome=Accepted()**))`| ------> |
 
 
 ## Advanced Service Bus capabilities

articles/service-bus-messaging/service-bus-auto-forwarding.md

@@ -1,9 +1,10 @@
 ---
 title: Autoforwarding Azure Service Bus messaging entities
 description: This article describes how to chain an Azure Service Bus queue or subscription to another queue or topic.
-ms.topic: article
-ms.date: 07/27/2022
+ms.topic: concept-article
+ms.date: 11/12/2024
 ms.custom: devx-track-csharp
+# Customer intent: I want to learn how to automatically forward messages received by one entity to another entity in Azure Service Bus. 
 ---
 
 # Chaining Service Bus entities with autoforwarding
@@ -23,7 +24,7 @@ You can use autoforwarding to scale out an individual topic. Service Bus limits
 ![Diagram of an autoforwarding scenario showing a message processed through an Orders Topic that can branch to any of three second-level Orders Topics.][0]
 
 ### Decouple message senders from receivers
-You can also use autoforwarding to decouple message senders from receivers. For example, consider an Enterprise Resource Planning (ERP) system that consists of three modules: order processing, inventory management, and customer relations management. Each of these modules generates messages that are enqueued into a corresponding topic. Alice and Bob are sales representatives that are interested in all messages that relate to their customers. To receive those messages, Alice and Bob each create a personal queue and a subscription on each of the ERP topics that automatically forward all messages to their queue.
+You can also use autoforwarding to decouple message senders from receivers. For example, consider an Enterprise Resource Planning (ERP) system that consists of three modules: order processing, inventory management, and customer relations management. Each of these modules generates messages that are enqueued into a corresponding topic. John Doe and Jane are sales representatives who are interested in all messages that relate to their customers. To receive those messages, John Doe and Jane Doe each create a personal queue and a subscription on each of the ERP topics that automatically forward all messages to their queue.
 
 ![Diagram of an autoforwarding scenario showing three processing modules sending messages through three corresponding topics to two separate queues.][1]
 
@@ -47,7 +48,7 @@ If Alice goes on vacation, her personal queue, rather than the ERP topic, fills
 - Source queue tries to forward messages to the destination entity in the same order it received, but the destination could be a topic that doesn't support ordering. If either the source or destination entity is a partitioned entity, order isn't guaranteed.
 
 
-## Next steps
+## Related content
 To learn how to enable or disable auto forwarding in different ways (Azure portal, PowerShell, CLI, Azure Resource Management template, etc.), see [Enable auto forwarding for queues and subscriptions](enable-auto-forward.md).