Merge remote-tracking branch 'origin/main' into matp-3233112

Author: Mattp123

.openpublishing.redirection.json

@@ -930,7 +930,7 @@ Follow these steps to create and import a [solution](../../maker/data-platform/s
    Project reference successfully added to Dataverse solution project.
    ```
 
-1. To generate a zip file from your solution project, when inside the the `cdsproj` solution project directory, using the following command:
+1. To generate a zip file from your solution project, when inside the `cdsproj` solution project directory, using the following command:
 
    ```CLI
    msbuild /t:restore

powerapps-docs/developer/component-framework/implementing-controls-using-typescript.md

@@ -35,7 +35,7 @@ You can find the code for sample here: [PowerApps-Samples/component-framework/Po
 
 The key change is to [PAGridCustomizer/customizers/CellRendererOverrides.tsx ](https://github.com/microsoft/PowerApps-Samples/blob/master/component-framework/PowerAppsGridCustomizerControl/PAGridCustomizer/customizers/CellRendererOverrides.tsx).
 
-This sample uses the following override for the cell renderer to change the the text color for text fields to green, and the color of the `creditlimit` column depends on the value.
+This sample uses the following override for the cell renderer to change the text color for text fields to green, and the color of the `creditlimit` column depends on the value.
 
 
 ```typescript

powerapps-docs/developer/component-framework/sample-controls/customized-editable-grid-control.md

@@ -53,6 +53,8 @@
               href: org-service/samples/issystemadmin-customapi-sample-plugin.md
         - name: Use Custom Process Actions with code
           href: workflow-custom-actions.md
+    - name: Use optional parameters
+      href: optional-parameters.md
     - name: Use FetchXML to query data
       href: use-fetchxml-construct-query.md
       items:
@@ -160,7 +162,7 @@
         - name: Analyze performance
           href: analyze-performance.md
         - name: Troubleshoot plug-ins
-          href: troubleshoot-plug-in.md
+          href: /troubleshoot/power-platform/power-apps/dataverse/dataverse-plug-ins-errors
         - name: Access external web resources
           href: access-web-services.md
         - name: Dependent Assemblies (Preview)

powerapps-docs/developer/data-platform/TOC.yml

@@ -1,7 +1,7 @@
 ---
 title: "Write Telemetry to your Application Insights resource using ILogger (Microsoft Dataverse) | Microsoft Docs"
-description: "When you enable Application Insights for your organization, any plug-ins written using the ILogger Interface provided in the SDK will write telemetry to your Application Insights resource."
-ms.date: 10/06/2022
+description: "When you enable Application Insights for your organization, any plug-ins written using the ILogger Interface provided in the SDK writes telemetry to your Application Insights resource."
+ms.date: 03/10/2023
 author: divkamath
 ms.author: dikamath
 ms.reviewer: pehecke
@@ -23,36 +23,36 @@ contributors:
 > To use this capability you must first enable the Application Insights integration feature. More information: [Analyze model-driven apps and Microsoft Dataverse telemetry with Application Insights](/power-platform/admin/analyze-telemetry)<p/>
 > There is presently no support of `ILogger` within a plug-in profiling/debug session of the Plug-in Registration tool or the Power Platform Tools extension for Visual Studio.
 
-When you enable Application Insights for your organization, any plug-ins written using the [ILogger Interface](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger) provided in the Organization Service SDK assemblies will write telemetry to your Application Insights resource.
+When you enable Application Insights for your organization, any plug-ins written using the [ILogger Interface](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger) provided in the Organization Service SDK assemblies write telemetry to your Application Insights resource.
 
-The Dataverse and model-driven app telemetry data you receive when using the Application Insights integration is captured by the Dataverse platform and exported to your Application Insights resource. This means there will be some latency between the time it was captured and when it becomes available to you in Application Insights.  Because this telemetry is gathered by Microsoft, you do not need to write any code to enable it.
+The Dataverse platform captures the Dataverse and model-driven app telemetry data and exports it to your Application Insights resource. There's some latency between the time it was captured and when it becomes available to you in Application Insights.  Because Microsoft gathers this telemetry, you don't need to write any code to enable it.
 
 Telemetry data that comes from plug-ins using the ILogger interface is different in two ways:
 
 - This telemetry is written directly to your Application Insights resource and is never sent to Microsoft.
-    - This means there will be less latency in viewing this data.
+    - There's less latency in viewing this data.
 - You must update your plug-in code to use the ILogger interface.
 
-Using ILogger will provide true telemetry data and is intended to work together with the existing Plug-in Trace Logs written using the [ITracingService Interface](/dotnet/api/microsoft.xrm.sdk.itracingservice). The following table compares the capabilities:
+Using ILogger provides true telemetry data and is intended to work together with the existing Plug-in Trace Logs written using the [ITracingService Interface](xref:Microsoft.Xrm.Sdk.ITracingService). The following table compares the capabilities:
 
 
 |Criteria |ILogger for Application Insights  |ITracingService Trace for Plug-in Trace Logs  |
 |---------|---------|---------|
 |Intended use|Capture telemetry over time for analysis and debugging.|While developing and debugging plug-ins|
 |How long data is stored|According to your Application Insights data retention period, which is 90 days by default|24 hours|
-|Available|Only for organizations that have subscribed to Application Insights integration.|For any organization when Plug-in tracing is enabled.|
-|Amount of data|Each log message can pass a String value.|Only 10kb of text can be written for each plug-in execution. Any more will be truncated.|
-|Available in runtime errors|No|Available in model-driven app client errors and as annotations in Web API. More information: [Include additional details with errors](webapi/compose-http-requests-handle-errors.md#include-additional-details-with-errors)|
+|Available|Only for organizations that have subscribed to Application Insights integration.|Available for any organization when Plug-in tracing is enabled.|
+|Amount of data|Each log message can pass a String value.|Only 10 kb of text can be written for each plug-in execution. Any more is truncated.|
+|Available in runtime errors|No|Available in model-driven app client errors and as annotations in Web API. More information: [Include more details with errors](webapi/compose-http-requests-handle-errors.md#include-more-details-with-errors)|
 
-You should continue to use the [ITracingService.Trace](/dotnet/api/microsoft.xrm.sdk.itracingservice.trace) to write to the Plug-in Trace Log table when needed. Not every organization will enable Application Insights. If your plug-in code uses the ILogger interface and the organization does not have Application Insights integration enabled, nothing will be written. So, it is important to continue to use the ITracingService Trace method in your plug-ins. Plug-in trace logs continue to be an important way to capture data while developing and debugging plug-ins, but they were never intended to provide telemetry data. More information: [Plug-ins: Tracing and logging](logging-tracing.md)
+You should continue to use the [ITracingService.Trace](xref:Microsoft.Xrm.Sdk.ITracingService.Trace%2A) to write to the Plug-in Trace Log table when needed. Not every organization enables Application Insights. If your plug-in code uses the ILogger interface and the organization doesn't have Application Insights integration enabled, nothing is written. So, it's important to continue to use the ITracingService Trace method in your plug-ins. Plug-in trace logs continue to be an important way to capture data while developing and debugging plug-ins, but they were never intended to provide telemetry data. More information: [Plug-ins: Tracing and logging](logging-tracing.md)
 
-You should use [ILogger](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger) because it will allow for telemetry about what happens within a plug-in to be integrated with the larger scope of data captured with the Application Insights integration. The Application Insights integration will tell you when a plug-in executes, how long it takes to run and whether it makes any external http requests, but Microsoft cannot add any telemetry code within the plug-ins that people write to extend the behavior of the platform.
+You should use [ILogger](xref:Microsoft.Xrm.Sdk.PluginTelemetry.ILogger) because it provides telemetry about what happens within a plug-in. This telemetry is integrated with the larger scope of data captured with the Application Insights integration. The Application Insights integration tells you when a plug-in executes, how long it takes to run and whether it makes any external http requests, but Microsoft can't add any telemetry code within the plug-ins that you write to extend the behavior of the platform.
 
-If you are an ISV with a product that includes plug-ins, your customers who enable Application Insights will appreciate being able to see what is going on within your plug-ins and this data may help you support them if there are issues. But data captured using ILogger will only be sent to the subscribing customer's resource. You will only be able to see data captured for your own environments when you have Application Insights enabled.
+If you're an ISV with a product that includes plug-ins, your customers who enable Application Insights appreciate being able to see what is going on within your plug-ins and this data may help you support them if there are issues. But data captured using ILogger is only sent to the subscribing customer's resource. You'll only be able to see data captured for your own environments when you have Application Insights enabled.
 
 ## Use ILogger
 
-ILogger is a common interface for capturing log information. The implementation provided with the Organization Service SDK assemblies provides common methods to support establishing a scope and different levels of logging.  There is currently no setting to control what level of logs are written. The levels can be used within Application Insights to filter which logs to view.
+ILogger is a common interface for capturing log information. The implementation provided with the Organization Service SDK assemblies provides common methods to support establishing a scope and different levels of logging.  There's currently no setting to control what level of logs are written. The levels can be used within Application Insights to filter which logs to view.
 
 The following is an example of a plug-in using both ILogger and ITracingService.Trace.
 
@@ -207,7 +207,7 @@ namespace ILoggerExample
 
 When this plug-in is registered on a synchronous `PostOperation` step for the `Create` of an `account` entity, you can use Application Insights Logs to view the output within a few minutes. You can use [Kusto Query Language (KQL)](/azure/data-explorer/kql-quick-reference) to query the results.
 
-You can filter items for a single operation using the `operation_ParentId` that represents the request id of the response header.
+You can filter items for a single operation using the `operation_ParentId` that represents the request ID of the response header.
 
 :::image type="content" source="media/application-insights-ilogger-trace-operation_parentid.png" alt-text="Filter items for a single operation using the operation_ParentId .":::
 
@@ -223,19 +223,19 @@ Outbound call started
 Outbound call ended successfully 
 ```
 
-Note that the information set with the [BeginScope Method](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger.beginscope) is not visible in the rows returned in Application Insights. This data is set within the `customDimensions` of logs added within that scope. You can use this query to show the logs within the scope.
+The information set with the [BeginScope Method](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger.beginscope) isn't visible in the rows returned in Application Insights. This data is set within the `customDimensions` of logs added within that scope. You can use this query to show the logs within the scope.
 
-This query will limit the results to the logs added during the `Callback` scope
+This query limits the results to the logs added during the `Callback` scope
 
-:::image type="content" source="media/application-insights-ilogger-trace-callback-scope.png" alt-text="Query will limit the results to the logs added during the Callback scope.":::
+:::image type="content" source="media/application-insights-ilogger-trace-callback-scope.png" alt-text="Query limits the results to the logs added during the Callback scope.":::
 
-And this query will limit the results to the logs added during the `OutboundCall` scope:
+And this query limits the results to the logs added during the `OutboundCall` scope:
 
-:::image type="content" source="media/application-insights-ilogger-trace-outboundcall-scope.png" alt-text="query will limit the results to the logs added during the OutboundCall scope.":::
+:::image type="content" source="media/application-insights-ilogger-trace-outboundcall-scope.png" alt-text="query limits the results to the logs added during the OutboundCall scope.":::
 
 ## Logging Exceptions
 
-At the bottom of the the plug-in code example above, the following code uses [LogError](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger.logerror) to log a caught exception and throws an [InvalidPluginExecutionException](/dotnet/api/microsoft.xrm.sdk.invalidpluginexecutionexception):
+At the bottom of the plug-in code example above, the following code uses [LogError](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger.logerror) to log a caught exception and throws an [InvalidPluginExecutionException](/dotnet/api/microsoft.xrm.sdk.invalidpluginexecutionexception):
 
 ```csharp
 catch (Exception e)
@@ -251,9 +251,9 @@ Using the plug-in code above, you can cause an exception by passing an invalid v
 
 :::image type="content" source="media/application-insights-ilogger-cause-error.png" alt-text="Causing an error by entering invalid configuration value in plug-in step registration.":::
 
-This will override the default value (`https://www.bing.com`) and cause the outbound call to fail. 
+This value overrides the default value (`https://www.bing.com`) and cause the outbound call to fail.
 
-There is nothing wrong with the request that a client may send:
+There's nothing wrong with the request that a client may send:
 
 ```http
 POST [Organization URI]/api/data/v9.1/accounts HTTP/1.1
@@ -266,7 +266,7 @@ Content-Type: application/json
 }
 ```
 
-But due to the incorrect plug-in step registration the response will return the following error with all the details when the `Prefer: odata.include-annotations="*"` header is used:
+But due to the incorrect plug-in step registration the response returns the following error with all the details when the `Prefer: odata.include-annotations="*"` header is used:
 
 ```http
 HTTP/1.1 400 Bad Request
@@ -289,7 +289,7 @@ Date: Sat, 24 Apr 2021 18:24:46 GMT
 }
 ```
 
-The Plug-in Trace Log will contain this exception data, which includes the `ExceptionDetails` data.
+The Plug-in Trace Log contains this exception data, which includes the `ExceptionDetails` data.
 
 ```
 Exception type: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]
@@ -329,11 +329,11 @@ Within Application Insights, if you view traces scoped to this request and with
 
 :::image type="content" source="media/application-insights-ilogger-trace-error.png" alt-text="View traces scoped to this request and with the scope set to OutboundCall.":::
 
-Within Application Insights, when you switch your query to use `exceptions` rather than `traces`, you will see three exceptions logged: 
+Within Application Insights, when you switch your query to use `exceptions` rather than `traces`, you'll see three exceptions logged: 
 
 :::image type="content" source="media/application-insights-ilogger-cause-error-exceptions.png" alt-text="Switch your query to use exceptions rather than traces.":::
 
-The one where `cloud_RoleInstance` equals `SandboxRoleInstance` is the one which was written because of the [ILogger LogError method](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger.logerror). The other two represent different locations where the error was logged on the server. 
+The one where `cloud_RoleInstance` equals `SandboxRoleInstance` is the one that was written because of the [ILogger LogError method](/dotnet/api/microsoft.xrm.sdk.plugintelemetry.ilogger.logerror). The other two represent different locations where the error was logged on the server. 
 
 > [!NOTE]
 > The SandboxRoleInstance `client_Type` is `PC`. This is because the plug-in runs in an isolated sandbox as a client rather than on the server.

powerapps-docs/developer/data-platform/application-insights-ilogger.md

@@ -45,7 +45,7 @@ If a plug-in makes external web requests that fail to respond quickly, the plug-
 
 The default timeout value for .Net Http clients is 100 seconds, just 20 seconds short of the time available for the plug-in to complete. It is best to establish an expected baseline time that a calling service will respond. The longer it exceeds this normal response time, the higher the probability it will ultimately fail. As a performance best practice, it is best to fail quickly rather than allow the default timeout period to expire. You should control the period that your call to the external service will wait.
 
-The timeout value you should set will depend on the service. For example, if you can monitor the performance of the service you may determine a duration where 99.999% of requests succeed and set your timeout period to that duration with a few seconds buffer. This will prevent the the occasional outliers from having an inordinate impact on the performance of your plug-in.
+The timeout value you should set will depend on the service. For example, if you can monitor the performance of the service you may determine a duration where 99.999% of requests succeed and set your timeout period to that duration with a few seconds buffer. This will prevent the occasional outliers from having an inordinate impact on the performance of your plug-in.
 
 If you are using [System.Net.Http.HttpClient Class](/dotnet/api/system.net.http.httpclient), you can set the `Timeout` value explicitly, as shown in this example setting the timeout to 15 seconds.