Live publish

buck1ey · web-flow · commit f389ce6387b4 · 2021-03-21T18:00:02.000-07:00
diff --git a/powerapps-docs/developer/data-platform/event-framework.md b/powerapps-docs/developer/data-platform/event-framework.md
@@ -2,7 +2,7 @@
 title: " Event Framework (Microsoft Dataverse) | Microsoft Docs" # Intent and product brand in a unique string of 43-59 chars including spaces
 description: "Describes the event framework and information developers should know when working with it." # 115-145 characters including spaces. This abstract displays in the search result.
 ms.custom: ""
-ms.date: 06/18/2019
+ms.date: 03/21/2021
 ms.reviewer: "pehecke"
 ms.service: powerapps
 ms.topic: "article"
@@ -17,13 +17,11 @@ search.app:
 ---
 # Event Framework
 
-[!INCLUDE[cc-data-platform-banner](../../includes/cc-data-platform-banner.md)]
-
 The capability to extend the default behavior of Microsoft Dataverse depends on detecting when events occur on the server. The *Event Framework* provides the capability to register custom code to be run in response to specific events. 
 
 All capabilities to extend the default behavior of the platform depend on the event framework. When you configure a workflow to respond to an event using the workflow designer without writing code, that event is provided by the event framework. 
 
-As a developer, you will use the *Plug-in registration tool* to configure plug-ins, Azure integrations, virtual entity data providers, and Web Hooks to respond to events that are provided by the event framework. When events occur and an extension is registered to respond to them, contextual information about the data involved in the operation is passed to the extension. Depending on how the registration for the event is configured, the extension can modify the data passed into it, intiate some automated process to be applied immediately, or define that an action is added to a queue to be performed later.
+As a developer, you will use the *Plug-in registration tool* to configure plug-ins, Azure integrations, virtual table data providers, and Web Hooks to respond to events that are provided by the event framework. When events occur and an extension is registered to respond to them, contextual information about the data involved in the operation is passed to the extension. Depending on how the registration for the event is configured, the extension can modify the data passed into it, intiate some automated process to be applied immediately, or define that an action is added to a queue to be performed later.
 
 To leverage the event framework for your custom extensions you must understand:
 
@@ -43,11 +41,11 @@ When you use the Plug-in registration tool to associate an extension with a part
 
 A step provides the information about which message the extensions should respond to as well as a number of other configuration choices. Use the **Message** field to choose the message your extension will respond to.
 
-Generally, you can expect to find a message for most of the **Request* classes in the <xref:Microsoft.Crm.Sdk.Messages> or <xref:Microsoft.Xrm.Sdk.Messages> namespaces, but you will also find messages for any custom actions that have been created in the organization. Any operations involving entity metadata are not available.
+Generally, you can expect to find a message for most of the **Request* classes in the <xref:Microsoft.Crm.Sdk.Messages> or <xref:Microsoft.Xrm.Sdk.Messages> namespaces, but you will also find messages for any custom actions that have been created in the organization. Any operations involving table definitions (entity metadata) are not available.
 
-Data about messages is stored in the [SdkMessage](reference/entities/sdkmessage.md) and [SdkMessageFilter](reference/entities/sdkmessagefilter.md) entities. The Plug-in registration tool will filter this information to only show valid messages.
+Data about messages is stored in the [SdkMessage](reference/entities/sdkmessage.md) and [SdkMessageFilter](reference/entities/sdkmessagefilter.md) tables. The Plug-in registration tool will filter this information to only show valid messages.
 
-To verify if a message and entity combination supports execution of plug-ins using a database query, you can use the following Web API query:
+To verify if a message and table combination supports execution of plug-ins using a database query, you can use the following Web API query:
 
 ```
 {{webapiurl}}sdkmessages?$select=name
@@ -108,23 +106,25 @@ When you register a step using the Plug-in registration tool you must also choos
 |--|--|
 |**PreValidation**|[!INCLUDE [cc-prevalidation-description](../../includes/cc-prevalidation-description.md)]|
 |**PreOperation**|[!INCLUDE [cc-preoperation-description](../../includes/cc-preoperation-description.md)]|
-|**MainOperation**|For internal use only.|
+|**MainOperation**|[!INCLUDE [cc-mainoperation-description](../../includes/cc-mainoperation-description.md)]|
 |**PostOperation**|[!INCLUDE [cc-postoperation-description](../../includes/cc-postoperation-description.md)]|
 
+
+
 The stage you should choose depends on the purpose of the extension. You don't need to apply all your business logic within a single step. You can apply multiple steps so that your logic about whether to allow a operation to proceed can be in the **PreValidation** stage and your logic to make modifications to the message properties can occur in the **PostOperation** stage.
 
 > [!IMPORTANT]
-> An exception thrown by your code at any stage will cause the entire transaction to be rolled back. You should be careful to ensure that any possible exception cases are handled by your code. If you want to cancel the operation, you should detect this in the **PreValidation** stage and only throw a <xref:Microsoft.Xrm.Sdk.InvalidPluginExecutionException> containing an appropriate message describing why the operation was cancelled.
+> An exception thrown by your code at any stage within the database transaction will cause the entire transaction to be rolled back. You should be careful to ensure that any possible exception cases are handled by your code. If you want to cancel the operation, you should detect this in the **PreValidation** stage and only throw a <xref:Microsoft.Xrm.Sdk.InvalidPluginExecutionException> containing an appropriate message describing why the operation was cancelled.
 
 Multiple extensions can be registered for the same message and stage. Within the step registration the **Execution Order** value determines the order in which multiple extensions should be processed for a given stage.
 
-Information about registered steps is stored in the [SdkMessageProcessingStep Entity](reference/entities/sdkmessageprocessingstep.md).
+Information about registered steps is stored in the [SdkMessageProcessingStep Table/Entity](reference/entities/sdkmessageprocessingstep.md).
 
 ## Event context
 
 If your extension is a Plug-in, it will receive a parameter that implements the <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext> interface. This class provides some information about the <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext.Stage> that the plugin is registered for as well as information about the <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext.ParentContext> which provides information about any operation within another Plug-in that triggered the current operation.
 
-If your extension is an a Web hook or an Azure Service bus endpoint, the data that will be posted to the registered endpoint will be in form of a <xref:Microsoft.Xrm.Sdk.RemoteExecutionContext> which implements both <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext> and <xref:Microsoft.Xrm.Sdk.IExecutionContext>
+If your extension is an an Azure Service bus endpoint, Azure EventHub topic, or a Web hook, the data that will be posted to the registered endpoint will be in form of a <xref:Microsoft.Xrm.Sdk.RemoteExecutionContext> which implements both <xref:Microsoft.Xrm.Sdk.IPluginExecutionContext> and <xref:Microsoft.Xrm.Sdk.IExecutionContext>
 
 For more information about the execution context, read [Understand the execution context](understand-the-data-context.md).
 
diff --git a/powerapps-docs/includes/cc-mainoperation-description.md b/powerapps-docs/includes/cc-mainoperation-description.md
@@ -0,0 +1 @@
+For internal use only except for Custom API and Custom virtual table data providers.<br/>More information: <br />[Create and use Custom APIs](/powerapps/developer/data-platform/custom-api)<br />[Custom Virtual table data providers](/powerapps/developer/data-platform/virtual-entities/custom-ve-data-providers)
diff --git a/powerapps-docs/includes/cc-postoperation-description.md b/powerapps-docs/includes/cc-postoperation-description.md
@@ -1 +1 @@
-Occurs after the main system operation and within the database transaction.<br /><br />Use this stage to modify any properties of the message before it is returned to the caller.<br /><br />Avoid applying changes to an entity included in the message because this will trigger a new Update event.
+Occurs after the main system operation and within the database transaction.<br /><br />Use this stage to modify any properties of the message before it is returned to the caller.<br /><br />Avoid applying changes to an entity included in the message because this will trigger a new Update event.<br /><br />Within the PostOperation stage you can register steps to use the asynchrous execution mode. These steps will run outside of the database transaction using the asynchronous service. <br />More information [Asynchronous service](/powerapps/developer/data-platform/asynchronous-service).

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1 @@`
	`1`	`+For internal use only except for Custom API and Custom virtual table data providers.<br/>More information: <br />[Create and use Custom APIs](/powerapps/developer/data-platform/custom-api)<br />[Custom Virtual table data providers](/powerapps/developer/data-platform/virtual-entities/custom-ve-data-providers)`
Original file line number	Diff line number	Diff line change
`@@ -1 +1 @@`
`1`		`-Occurs after the main system operation and within the database transaction.<br /><br />Use this stage to modify any properties of the message before it is returned to the caller.<br /><br />Avoid applying changes to an entity included in the message because this will trigger a new Update event.`
	`1`	+Occurs after the main system operation and within the database transaction.<br /><br />Use this stage to modify any properties of the message before it is returned to the caller.<br /><br />Avoid applying changes to an entity included in the message because this will trigger a new Update event.<br /><br />Within the PostOperation stage you can register steps to use the asynchrous execution mode. These steps will run outside of the database transaction using the asynchronous service. <br />More information [Asynchronous service](/powerapps/developer/data-platform/asynchronous-service).