Merge pull request #102574 from kromerm/dataflow-1

Update data flow transform activities in concepts-integration-runtime.md

Author: GitHubber17

articles/data-factory/concepts-integration-runtime.md

@@ -12,7 +12,7 @@ ms.workload: data-services
 
 ms.topic: conceptual
 ms.custom: seo-lt-2019
-ms.date: 05/31/2019
+ms.date: 01/28/2020
 ---
 
 # Integration runtime in Azure Data Factory
@@ -137,9 +137,9 @@ When used to perform data movement, the self-hosted IR extracts data from the so
 ### Azure-SSIS IR location
 Selecting the right location for your Azure-SSIS IR is essential to achieve high performance in your extract-transform-load (ETL) workflows.
 
-- The location of your Azure-SSIS IR does not need be the same as the location of your data factory, but it should be the same as the location of your own Azure SQL Database/Managed Instance server where SSISDB is to be hosted. This way, your Azure-SSIS Integration Runtime can easily access SSISDB without incurring excessive traffics between different locations.
-- If you do not have an existing Azure SQL Database/Managed Instance server to host SSISDB, but you have on-premises data sources/destinations, you should create a new Azure SQL Database/Managed Instance server in the same location of a virtual network connected to your on-premises network.  This way, you can create your Azure-SSIS IR using the new Azure SQL Database/Managed Instance server and joining that virtual network, all in the same location, effectively minimizing data movements across different locations.
-- If the location of your existing Azure SQL Database/Managed Instance server where SSISDB is hosted is not the same as the location of a virtual network connected to your on-premises network, first create your Azure-SSIS IR using an existing Azure SQL Database/Managed Instance server and joining another virtual network in the same location, and then configure a virtual network to virtual network connection between different locations.
+- The location of your Azure-SSIS IR does not need be the same as the location of your data factory, but it should be the same as the location of your own Azure SQL Database or Managed Instance server where SSISDB is to be hosted. This way, your Azure-SSIS Integration Runtime can easily access SSISDB without incurring excessive traffics between different locations.
+- If you do not have an existing Azure SQL Database or Managed Instance server to host SSISDB, but you have on-premises data sources/destinations, you should create a new Azure SQL Database or Managed Instance server in the same location of a virtual network connected to your on-premises network.  This way, you can create your Azure-SSIS IR using the new Azure SQL Database or Managed Instance server and joining that virtual network, all in the same location, effectively minimizing data movements across different locations.
+- If the location of your existing Azure SQL Database or Managed Instance server where SSISDB is hosted is not the same as the location of a virtual network connected to your on-premises network, first create your Azure-SSIS IR using an existing Azure SQL Database or Managed Instance server and joining another virtual network in the same location, and then configure a virtual network to virtual network connection between different locations.
 
 The following diagram shows location settings of Data Factory and its integration run times:
 
@@ -159,13 +159,13 @@ For Copy activity, it requires source and sink linked services to define the dir
 
 The Lookup and GetMetadata activity is executed on the integration runtime associated to the data store linked service.
 
-### Transformation activity
+### External transformation activity
 
-Each transformation activity has a target compute Linked Service, which points to an integration runtime. This integration runtime instance is where the transformation activity is dispatched from.
+Each external transformation activity that utilizes an external compute engine has a target compute Linked Service, which points to an integration runtime. This integration runtime instance determines the location where that external hand-coded transformation activity is dispatched from.
 
 ### Data Flow activity
 
-Data Flow activity is executed on the integration runtime associated to it. 
+Data Flow activities are executed on the Azure integration runtime associated to it. The Spark compute utilized by Data Flows are determined by the data flow properties in your Azure Integration Runtime and are fully managed by ADF.
 
 ## Next steps
 See the following articles:

articles/data-factory/connector-azure-sql-database.md

@@ -10,7 +10,7 @@ ms.service: data-factory
 ms.workload: data-services
 ms.topic: conceptual
 ms.custom: seo-lt-2019
-ms.date: 12/13/2019
+ms.date: 01/28/2020
 ---
 
 # Copy and transform data in Azure SQL Database by using Azure Data Factory
@@ -585,6 +585,10 @@ Settings specific to Azure SQL Database are available in the **Settings** tab of
 
 **Update method:** Determines what operations are allowed on your database destination. The default is to only allow inserts. To update, upsert, or delete rows, an alter-row transformation is required to tag rows for those actions. For updates, upserts and deletes, a key column or columns must be set to determine which row to alter.
 
+![Key Columns](media/data-flow/keycolumn.png "Key Columns")
+
+The column name that you pick as the key here will be used by ADF as part of the subsequent update, upsert, delete. Therefore, you must pick a column that exists in the Sink mapping. If you wish to not write the value to this key column, then click "Skip writing key columns".
+
 **Table action:** Determines whether to recreate or remove all rows from the destination table prior to writing.
 * None: No action will be done to the table.
 * Recreate: The table will get dropped and recreated. Required if creating a new table dynamically.