Acrolinx suggestions

phecke · phecke · commit a6245cef458d · 2024-07-26T17:26:07.000-07:00
diff --git a/powerapps-docs/developer/data-platform/azure-integration.md b/powerapps-docs/developer/data-platform/azure-integration.md
@@ -17,7 +17,7 @@ contributors:
 
 [!INCLUDE[cc-terminology](includes/cc-terminology.md)]
 
-Microsoft Dataverse supports integration with Azure. Developers can register plug-ins with Dataverse that can pass runtime message data, known as the execution context, to one or more Azure solutions in the cloud. This is especially important because Azure is one of a few supported solutions for communicating runtime context to external line-of-business (LOB) applications.
+Microsoft Dataverse supports integration with Azure. Developers can register plug-ins with Dataverse that can pass runtime message data, known as the execution context, to one or more Azure solutions in the cloud. This capability is especially important because Azure is one of a few supported solutions for communicating runtime context to external line-of-business (LOB) applications.
 
 The Azure Service Bus provides a secure and reliable communication channel between Dataverse runtime data and external cloud-based line-of-business (LOB) applications. This capability is especially useful in keeping disparate Dataverse systems or other Dataverse servers synchronized with business data changes.
 
@@ -27,9 +27,9 @@ The Azure Service Bus provides a secure and reliable communication channel betwe
   
 ### Data Context
 
- The *data context* contains the business data that is being processed as part of the current Dataverse operation. This processing was initiated when a request to perform a certain Dataverse operation was made by a user, workflow, or application. The data context is passed to any plug-ins or custom workflow activities that are registered with the event pipeline to execute on the specific request and table combination that is currently being processed. The data context is of type <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext> when it is being passed along the event execution pipeline and <xref:Microsoft.Xrm.Sdk.RemoteExecutionContext> when it is posted to the Service Bus.  
+ The *data context* contains the business data that is being processed as part of the current Dataverse operation. This processing was initiated when a request to perform a certain Dataverse operation was made by a user, workflow, or application. The data context is passed to any plug-ins or custom workflow activities that are registered with the event pipeline to execute on the specific request and table combination that is currently being processed. The data context is of type <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext> when when passed along the event execution pipeline and <xref:Microsoft.Xrm.Sdk.RemoteExecutionContext> when  posted to the Service Bus.  
   
- The data context contained within the message that is posted to the Azure Service Bus can be formatted in XML or JSON in addition to the default .NET binary format. This allows for cross-platform interoperability where Azure hosted non-.NET clients can read Dataverse data from the service bus.
+ The data context contained within the message that is posted to the Azure Service Bus can be formatted in XML or JSON in addition to the default .NET binary format. Support for such data formats allows for cross-platform interoperability where Azure hosted non-.NET clients can read Dataverse data from the service bus.
 
 > [!IMPORTANT]
 > When the size of the entire HTTP payload exceeds 192Kb, the following properties will be removed:
@@ -51,7 +51,7 @@ The Azure Service Bus provides a secure and reliable communication channel betwe
   
 ### Plug-ins
 
-Plug-ins are one of two methods used to initiate posting the message containing the data context to the Azure Service Bus, the other method being a custom workflow activity. There are two kinds of plug-ins supported by the Dataverse-Azure connection feature: out-of-box (OOB), and custom. In either case, it is recommended that you register the plug-in to run asynchronously for best system performance.  
+Plug-ins are one of two methods used to initiate posting the message containing the data context to the Azure Service Bus, the other method being a custom workflow activity. There are two kinds of plug-ins supported by the Dataverse-Azure connection feature: out-of-box (OOB), and custom. In either case, it's recommended that you register the plug-in to run asynchronously for best system performance.  
   
 An Azure-aware default (OOB) plug-in is available and can be registered with Dataverse by registering a service endpoint using the Plug-in Registration tool. You must register a plug-in 'step' in the event execution pipeline that identifies the message and table combination that triggers the plug-in to execute and perform the posting notification. When executed, the plug-in notifies the asynchronous service, through a service endpoint notification service (<xref:Microsoft.Xrm.Sdk.IServiceEndpointNotificationService>), to post the current request data context to the Azure Service Bus.  
   
@@ -67,19 +67,19 @@ Similarly to plug-ins, custom workflow activities can be written to initiate pos
 
 Once notified by the service endpoint notification service, the asynchronous service handles posting the  data context of the request message currently being processed by the event execution pipeline to the Azure Service Bus. Each post is performed by a system job of the asynchronous service. A user can view the status of each system job by using the **System Jobs** view of the Power Apps web application. In the web application, choose **Advanced settings** to display the legacy Dynamics 365 interface. Next, select **Settings** > **System jobs**.
   
-For more information about the asynchronous service see [Asynchronous service](asynchronous-service.md).  
+For more information about the asynchronous service, see [Asynchronous service](asynchronous-service.md).  
   
 ### Microsoft Azure Service Bus
 
-The service bus relays the request message data context between Dataverse and Azure Service Bus solution listener applications. The service bus also provides data security so that only authorized applications can access the posted Dataverse data.  Authorization of Dataverse to post the data context to the service bus and for listener applications to read it is managed by Azure Shared Access Signatures (SAS).  
+The service bus relays the request message data context between Dataverse and Azure Service Bus solution listener applications. The service bus also provides data security so that only authorized applications can access the posted Dataverse data.  Authorization of Dataverse to post the data context to the service bus and for listener applications to read it's managed by Azure Shared Access Signatures (SAS).  
 
  For more information about service bus, see [Service Bus](https://azure.microsoft.com/services/service-bus/). For more information about service bus authorization, see [Service Bus authentication and authorization](/azure/service-bus-messaging/service-bus-authentication-and-authorization).  
   
 ### Microsoft Azure solution
 
 For the Dataverse and Azure connection to work, there must be at least one solution in an Azure Service Bus solution account, where the solution contains one or more service endpoints. For a relay endpoint contract, a listener application that is “Dataverse-aware” must be actively listening on the endpoint for the Dataverse request on the Service Bus. For a queue endpoint contract, a listener doesn’t have to be actively listening. A listener is made Dataverse-aware by linking it to the <xref:Microsoft.Xrm.Sdk> assembly so that type <xref:Microsoft.Xrm.Sdk.RemoteExecutionContext> is defined. More information: [Write a Listener for a Microsoft Azure Solution](write-listener-application-azure-solution.md)  
   
-Dataverse supports sending event data to an Azure Event Hubs solution. More information about event hubs, see [Work with event data in your Azure Event Hub solution](work-event-data-azure-event-hub-solution.md).  
+Dataverse supports sending event data to an Azure Event Hubs solution. More information about event hubs, see [Work with event data in your Azure Event Hubs solution](work-event-data-azure-event-hub-solution.md).  
   
 <a name="bkmk_describing"></a>  
 
@@ -93,7 +93,7 @@ The following diagram shows the physical elements that make up the scenario.
   
 The sequence of events as identified in this diagram are as follows:  
   
-1. A listener application is registered on a Azure Service Bus solution endpoint, and begins actively listening for the Dataverse remote execution context on the Service Bus.  
+1. A listener application is registered on an Azure Service Bus solution endpoint, and begins actively listening for the Dataverse remote execution context on the Service Bus.  
 
 2. A user performs some operation in Dataverse that triggers execution of the registered OOB plug-in or a custom Azure-aware plug-in. The plug-in initiates a post, through an asynchronous service system job, of the current request data context to the Service Bus.  
 3. The claims posted by Dataverse are authenticated. The Service Bus then relays the remote execution context to the listener. The listener processes the context information and performs some business-related task with that information. The Service Bus notifies the asynchronous service of a successful post and sets the related system job to a completed status.  
@@ -106,13 +106,13 @@ For each solution endpoint, you configure a contract that defines the handling o
   
 ### Queue
 
-A queue contract provides a message queue in the cloud. With a queue contract, a listener doesn’t have to be actively listening for messages on the endpoint. For queues, there is a destructive read and a non-destructive read. A destructive read reads an available message from the queue and the message is removed. A non-destructive read doesn’t remove a message from the queue.  
+A queue contract provides a message queue in the cloud. With a queue contract, a listener doesn’t have to be actively listening for messages on the endpoint. For queues, there's a destructive read and a nondestructive read. A destructive read reads an available message from the queue and the message is removed. A nondestructive read doesn’t remove a message from the queue.  
   
 The type of queue supported by Dataverse is called a persistent queue. Persistent queues have a long but finite message availability duration that can be specified in code.  
   
 ### One-way
 
-A one-way contract requires an active listener. If there is no active listener on an endpoint, the post to the Service Bus fails. Dataverse will retry the post in exponentially larger and larger time spans until the asynchronous system job that is posting the request is eventually aborted and its status is set to “Failed.”  
+A one-way contract requires an active listener. If there's no active listener on an endpoint, the post to the Service Bus fails. Dataverse will retry the post in exponentially larger and larger time spans until the asynchronous system job that is posting the request is eventually aborted and its status is set to “Failed.”  
   
 ### Two-way
 
@@ -126,9 +126,9 @@ A REST contract is similar to a two-way contract on a REST endpoint.
 
 Similar to a queue except that one or more listeners can subscribe to receive messages from the topic.  
   
-### Event Hub
+### Event Hubs
 
-This contract type applies to Azure Event Hub solutions.
+This contract type applies to Azure Event Hubs solutions.
   
 Identifying the kind of security a contract uses is part of the contract’s configuration. A contract can use Transport security, which uses Transport Layer Security (TLS) or Secure Sockets Layer (SSL) (https).  
   
diff --git a/powerapps-docs/developer/data-platform/configure-azure-integration.md b/powerapps-docs/developer/data-platform/configure-azure-integration.md
@@ -18,19 +18,19 @@ You can post the message request data for the current Dataverse core operation t
 
 ## Configure Azure For Dataverse integration
 
-Because you will use SAS for authorization, you need to configure the rules and issuers of your Azure solution to allow a listener application to read the Dataverse message posted to the Azure Service Bus. In addition, you must configure the service bus rules to accept the Dataverse issuer claim. The recommended method to configure Azure is to use the Plug-in Registration tool (PRT).
+Because you'll use SAS for authorization, you need to configure the rules and issuers of your Azure solution to allow a listener application to read the Dataverse message posted to the Azure Service Bus. In addition, you must configure the service bus rules to accept the Dataverse issuer claim. The recommended method to configure Azure is to use the Plug-in Registration tool (PRT).
 
 For instructions on configuring authorization see [Tutorial: Configure Azure (SAS) for integration with Dataverse](walkthrough-configure-azure-sas-integration.md).
 
 ## Test Configuration
 
-After configuring Azure integration, you will need to perform these additional tasks.
+After configuring Azure integration, you'll need to perform these other tasks.
 
-1. Write and register a listener application with a Azure Service Bus solution endpoint. For more information, see the Azure Service Bus [documentation](/azure/service-bus-messaging/service-bus-messaging-overview).
-1. Register an Azure aware plug-in or a Azure-aware custom workflow activity with Dataverse. More information: [Tutorial: Register an Azure-aware plug-in using the Plug-in Registration tool](walkthrough-register-azure-aware-plug-in-using-plug-in-registration-tool.md)
+1. Write and register a listener application with an Azure Service Bus solution endpoint. For more information, see the Azure Service Bus [documentation](/azure/service-bus-messaging/service-bus-messaging-overview).
+1. Register an Azure aware plug-in or an Azure-aware custom workflow activity with Dataverse. More information: [Tutorial: Register an Azure-aware plug-in using the Plug-in Registration tool](walkthrough-register-azure-aware-plug-in-using-plug-in-registration-tool.md)
 1. Perform the necessary Dataverse operation that triggers the plug-in or custom workflow activity to run.
 
-If all of the preceding steps were performed correctly, a message containing the Dataversse data context should be sent to a Azure queue or topic and ultimately received by the listener application. You can navigate to the System Jobs grid in the Power Apps web application, under **Advanced settings**, and check the status of the related system job to see if the post to the Azure Service Bus succeeded. In case of errors, the message section of the system job displays the error details.
+If all of the preceding steps were performed correctly, a message containing the Dataverse data context should be sent to an Azure queue or topic and ultimately received by the listener application. You can navigate to the System Jobs grid in the Power Apps web application, under **Advanced settings**, and check the status of the related system job to see if the post to the Azure Service Bus succeeded. If errors occur, the message section of the system job displays the error details.
 
 ### See also
 
diff --git a/powerapps-docs/developer/data-platform/write-custom-azure-aware-plugin.md b/powerapps-docs/developer/data-platform/write-custom-azure-aware-plugin.md
@@ -21,17 +21,17 @@ Writing a plug-in that works with Azure is similar to writing any other Datavers
 
 ## Plug-in design considerations
 
-For a plug-in that executes synchronously, the recommended design is for the plug-in to send a message to Azure for the purpose of retrieving information from a listener application or other external service. Use of a two-way or REST contract on the Azure Service Bus endpoint allows a data string to be returned to the plug-in.  
+For a plug-in that executes synchronously, the recommended design is for the plug-in to send a message to Azure for retrieving information from a listener application or other external service. Use of a two-way or REST contract on the Azure Service Bus endpoint allows a data string to be returned to the plug-in.  
   
-It is not recommended that a synchronous plug-in use the Azure Service Bus to update data with an external service. Problems can arise if the external service becomes unavailable or if there is a lot of data to update. Synchronous plug-ins should execute fast and not hold up all logged in users of an organization while a lengthy operation is performed. In addition, if a rollback of the current core operation that invoked the plug-in occurs, any data changes made by the plug-in are undone. This could leave Dataverse and an external service in an un-synchronized state.  
+It isn't recommended that a synchronous plug-in use the Azure Service Bus to update data with an external service. Problems can arise if the external service becomes unavailable or if there's much data to update. Synchronous plug-ins should execute fast and not hold up all logged in users of an organization while a lengthy operation is performed. In addition, if a rollback of the current core operation that invoked the plug-in occurs, any data changes made by the plug-in are undone. This rollback could leave Dataverse and an external service in an unsynchronized state.  
   
-Note that it is possible for synchronous registered plug-ins to post the current transaction's execution context to the Azure Service Bus.  
+It is possible for synchronous registered plug-ins to post the current transaction's execution context to the Azure Service Bus.  
   
 <a name="bkmk_writing"></a>
   
 ## Write the plug-in code
 
-In the following sample plug-in code has been added to obtain the Azure service provider and initiate posting the execution context to the Service Bus by calling <xref:Microsoft.Xrm.Sdk.IServiceEndpointNotificationService.Execute(Microsoft.Xrm.Sdk.EntityReference,Microsoft.Xrm.Sdk.IExecutionContext)>. Tracing code has been added to facilitate debugging of the plug-in because the plug-in must run in the sandbox.  
+In the following sample plug-in, code has been added to obtain the Azure service provider and initiate posting the execution context to the Service Bus by calling <xref:Microsoft.Xrm.Sdk.IServiceEndpointNotificationService.Execute(Microsoft.Xrm.Sdk.EntityReference,Microsoft.Xrm.Sdk.IExecutionContext)>. Tracing code has been added to facilitate debugging of the plug-in because the plug-in must run in the sandbox.  
 
 > [!NOTE]
 > The `serviceEndpointId` passed into the constructor in this code is the one you get from creating a service endpoint as described in [Walkthrough: Configure Azure (SAS) for integration with Dataverse](walkthrough-configure-azure-sas-integration.md)
@@ -115,9 +115,9 @@ In your plug-in code, you can update the writeable data in the context before in
 
 ## Plug-in registration
 
-There are a few restrictions when you register a Azure-aware custom plug-in. The plug-in must be registered to execute in the sandbox. Because of this, the plug-in is limited to calling <xref:Microsoft.Xrm.Sdk.IOrganizationService> methods, Azure solution methods, or accessing a network using a web client. No other external access, such as access to a local file system, is allowed.  
+There are a few restrictions when you register an Azure-aware custom plug-in. The plug-in must be registered to execute in the sandbox. Sandbox registration limits the plug-in to calling <xref:Microsoft.Xrm.Sdk.IOrganizationService> methods, Azure solution methods, or accessing a network using a web client. No other external access, such as access to a local file system, is allowed.  
   
-For a plug-in registered to execute in asynchronous mode, this also means that the order of plug-in execution compared to other asynchronous plug-ins is not guaranteed. In addition, asynchronous plug-ins always execute after the Dataverse core operation.  
+For a plug-in registered to execute in asynchronous mode, the order of plug-in execution compared to other asynchronous plug-ins isn't guaranteed. In addition, asynchronous plug-ins always execute after the Dataverse core operation.  
   
 <a name="bkmk_failure"></a>
 
