Skip to content

Commit fc670ed

Browse files
committed
fixed merge conflict
2 parents 46d3a64 + f411c96 commit fc670ed

File tree

42 files changed

+129
-161
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

42 files changed

+129
-161
lines changed

articles/azure-app-configuration/faq.yml

Lines changed: 36 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ metadata:
66
author: zhenlan
77
ms.service: azure-app-configuration
88
ms.topic: faq
9-
ms.date: 02/16/2024
9+
ms.date: 09/11/2024
1010
ms.author: zhenlwa
1111
ms.custom: references_regions
1212
title: Azure App Configuration FAQ
@@ -84,8 +84,13 @@ sections:
8484
8585
Standard tier stores are limited to 30,000 requests per hour. Once the hourly quota is exhausted, additional requests may return an HTTP status code 429, indicating too many requests, until the end of the hour. As more requests are sent which are above quota, a higher percentage of them may return status code 429.
8686
87-
Premium tier stores have no quota limit on requests.
88-
87+
Premium tier stores have no quota limit on requests, ensuring that access to the store is never blocked.
88+
- **Throughput**: App Configuration stores in all tiers have a throughput allowance. Requests exceeding this allowance will receive an HTTP status code 429 response.
89+
Stores in the Free tier have no guaranteed throughput.
90+
91+
Stores in the Standard tier allow up to 300 requests per second (RPS) for read requests and up to 60 RPS for write requests.
92+
93+
Stores in the Premium tier allow up to 450 RPS for read requests and up to 100 RPS for write requests.
8994
- **Service level agreement**: The Free tier doesn't have an SLA. The Standard tier has an SLA of 99.9% availability and 99.95% availability with geo-replication enabled. The Premium tier has an SLA of 99.9% availability and 99.99% availability with geo-replication enabled.
9095
- **Features**: All tiers include functionalities, including encryption with Microsoft-managed keys, authentication via access key or Microsoft Entra ID, Azure role-based access control (RBAC), managed identity, service tags, and availability zone redundancy. The Standard and Premium tiers offer more functionalities, including Private Link support, encryption with customer-managed keys, soft delete protection, and geo-replication capability.
9196
- **Cost**: There's no cost to use a Free tier store.
@@ -98,7 +103,7 @@ sections:
98103
answer: |
99104
You can upgrade an App Configuration store at any time, for example, from the Free tier to the Standard or Premium tier, or from the Standard tier to the Premium tier.
100105
101-
You cant downgrade an App Configuration store, for example, from the Premium tier to the Standard tier, or from the Standard tier to the Free tier. However, you can create a new store in the desired tier and then [import configuration data into that store](howto-import-export-data.md).
106+
You can't downgrade an App Configuration store, for example, from the Premium tier to the Standard tier, or from the Standard tier to the Free tier. However, you can create a new store in the desired tier and then [import configuration data into that store](howto-import-export-data.md).
102107
103108
- question: Where does data stored in App Configuration reside?
104109
answer: |
@@ -113,26 +118,10 @@ sections:
113118
[!INCLUDE [Azure App Configuration availability zones table](../../includes/azure-app-configuration-availability-zones.md)]
114119
115120
- question: Are there any limits on the number of requests made to App Configuration?
116-
answer: |
117-
Configuration stores in the Free tier are limited to 1,000 requests per day. Configuration stores in the Standard tier may experience temporary throttling when the request rate exceeds 30,000 requests per hour. Configuration stores in the Premium tier have no quota limit on requests.
118-
119-
When a store reaches its limit in the Standard tier, it may return HTTP status code 429 for some requests made until the end of the hour. The `retry-after-ms` header in the response gives a suggested wait time (in milliseconds) before retrying the request.
120-
121-
If your application regularly experiences HTTP status code 429 responses, consider redesigning it to reduce the number of requests made. For more information, see [how to reduce requests made to App Configuration](./howto-best-practices.md#reduce-requests-made-to-app-configuration).
122-
123-
- question: My application receives HTTP status code 429 responses. Why?
124-
answer: |
125-
You'll receive an HTTP status code 429 response under these circumstances:
126-
127-
* Exceeding the daily request limit for a store in the Free tier.
128-
* Exceeding the hourly request limit for a store in the standard tier.
129-
* Momentary throttling due to a large burst of requests†.
130-
* Momentary throttling due to excessive bandwidth usage†.
131-
* Attempting to create or modify a key when the storage quota is exceeded.
132-
133-
Check the body of the 429 response for the specific reason why the request failed.
134-
135-
†A configuration store may experience momentary throttling if it receives a large burst of requests or transfers an excessive volume of data. App Configuration clients, such as the Azure SDK, configuration provider libraries, and Azure Pipelines tasks, automatically retry on throttled requests. For any applications using one of these clients, or a custom client that retries on throttled requests, this momentary throttling should go unnoticed, should it occur.
121+
answer: |
122+
App Configuration stores have different request quotas based on their tier. Free tier stores are limited to 1,000 requests per day, Standard tier stores to 30,000 requests per hour, and Premium tier stores have no request limits, ensuring uninterrupted access.
123+
124+
App Configuration stores have throughput allowances based on their tier. Free tier stores do not have guaranteed throughput. Standard tier stores support up to 300 requests per second (RPS) for read operations and up to 60 RPS for write operations. Premium tier stores support up to 450 RPS for read operations and up to 100 RPS for write operations.
136125
137126
- question: How do I estimate the number of requests my application may send to App Configuration?
138127
answer: |
@@ -142,10 +131,32 @@ sections:
142131
143132
Secondly, let's estimate the requests for configuration loading/reloading. Your application loads all settings at the startup or whenever a sentinel key change is detected. Each request to App Configuration can retrieve up to 100 key-values, so it will take 10 (=1000/100) requests to load all settings. Given you have 50 application instances, you send 500 (=10x50) total requests when your application restarts or reloads its configuration.
144133
145-
Finally, let's put it together. Assuming you updated the sentinel key twice within an hour, your App Configuration store will thus receive 7,000 (=6,000+500x2) total requests for that hour. Note that out of these requests, only about 1,000 (=500x2) requests will use the available hourly quota. Update the numbers in this example to match your specific setup and design accordingly so you have a sufficient buffer against the hourly throttling limit. For more information, see [how to reduce requests made to App Configuration](./howto-best-practices.md#reduce-requests-made-to-app-configuration).
134+
Finally, let's put it together. Assuming you updated the sentinel key twice within an hour, your App Configuration store will thus receive 7,000 (=6,000+500x2) total requests for that hour. Note that out of these requests, only about 1,000 (=500x2) requests will use the available hourly quota. Update the numbers in this example to match your specific setup and design accordingly so you have a sufficient buffer against the hourly throttling limit.
146135
147136
†Free tier stores do not have frequent, repeated requests excluded from their daily limit.
148137
138+
- question: My application receives HTTP status code 429 responses. Why?
139+
answer: |
140+
Your application may receive an HTTP status code 429 response under the following circumstances:
141+
142+
- Exceeding the daily request quota for a store in the Free tier.
143+
- Exceeding the hourly request quota for a store in the Standard tier.
144+
- Exceeding the throughput allowance for a store in any tier.
145+
- Exceeding the bandwidth allowance for a store in any tier.
146+
- Attempting to create or modify a key-value when the storage quota is exceeded.
147+
148+
Check the body of the 429 response for the specific reason why the request failed. You can also collect logs for your [App Configuration store in Azure Monitor](./monitor-app-configuration.md) and set up alerts for the *Request Quota Usage* metric.
149+
150+
Receiving momentary HTTP status code 429 responses usually causes no harm, as App Configuration clients handle them gracefully. However, if your application regularly experiences HTTP status code 429 responses, consider the following options:
151+
152+
- **Upgrade your store to the Premium tier**: This tier has no quota limit on requests and has significantly increased storage quota.
153+
- **Use App Configuration Providers**: The providers have built-in retry and caching capabilities along with many other resiliency features.
154+
- **Use App Configuration SDKs** if your application needs to send write requests. Although the SDKs may not be as feature-rich as providers, they automatically retry on HTTP status code 429 responses.
155+
- **Include retry logic in custom clients** if you can't use App Configuration Providers or SDKs. The `retry-after-ms` header in the response provides a suggested wait time (in milliseconds) before retrying the request.
156+
- **Distribute requests across multiple client instances**: This helps achieve the maximum throughput from your App Configuration store.
157+
- **Reduce requests made to App Configuration**: Follow the guidance to [minimize the number of requests](./howto-best-practices.md#reduce-requests-made-to-app-configuration).
158+
- **Improve your application resiliency**: Consider integrating geo-replication to allow failover and load balancing. Check the best practices for [building highly resilient applications](./howto-best-practices.md#building-applications-with-high-resiliency).
159+
149160
- question: Why can't I create an App Configuration store with the same name as one that I just deleted?
150161
answer: |
151162
All App Configuration stores in the Standard and Premium tiers have automatically enabled the [soft-delete](concept-soft-delete.md) feature. When a Standard or Premium tier App Configuration store is deleted, its name is reserved for the retention period. To recreate a store with the same name before the retention period expires, you need to [purge the soft-deleted store](howto-recover-deleted-stores-in-azure-app-configuration.md#list-recover-or-purge-a-soft-deleted-app-configuration-store) first, provided the store doesn't have purge protection enabled. If the purge protection is enabled, you must wait for the retention period to elapse. Use the purge function or set a shorter retention period if you often need to recreate a store with the same name. Workflows that require recreating a store with the same name should allow for one hour between purging a configuration store and performing the subsequent create. This recommendation is in place because once a purge is requested the actual cleanup of configuration store resources is performed asynchronously, requiring a bit of extra time to finalize. To avoid any need to wait, workflows that create ephemeral configuration stores are recommended to use unique names.

articles/azure-app-configuration/howto-best-practices.md

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ services: azure-app-configuration
55
author: zhenlan
66
ms.service: azure-app-configuration
77
ms.topic: conceptual
8-
ms.date: 02/20/2024
8+
ms.date: 09/11/2024
99
ms.author: zhenlwa
1010
ms.custom: "devx-track-csharp, mvc"
1111
---
@@ -89,12 +89,10 @@ You can also make your App Configuration data accessible to your application as
8989

9090
Excessive requests to App Configuration can result in throttling or overage charges. To reduce the number of requests made:
9191

92-
* Increase the refresh timeout, especially if your configuration values do not change frequently. Specify a new refresh timeout using the [`SetCacheExpiration` method](/dotnet/api/microsoft.extensions.configuration.azureappconfiguration.azureappconfigurationrefreshoptions.setcacheexpiration).
92+
* Increase the refresh interval, especially if your configuration values do not change frequently. Specify a new refresh interval using the [`SetCacheExpiration` method](/dotnet/api/microsoft.extensions.configuration.azureappconfiguration.azureappconfigurationrefreshoptions.setcacheexpiration).
9393

9494
* Watch a single *sentinel key*, rather than watching individual keys. Refresh all configuration only if the sentinel key changes. See [Use dynamic configuration in an ASP.NET Core app](enable-dynamic-configuration-aspnet-core.md) for an example.
9595

96-
* Use Azure Event Grid to receive notifications when configuration changes, rather than constantly polling for any changes. For more information, see [Use Event Grid for App Configuration data change notifications](./howto-app-configuration-event.md).
97-
9896
* [Enable geo-replication](./howto-geo-replication.md) of your App Configuration store and spread your requests across multiple replicas. For example, use a different replica from each geographic region for a globally deployed application. Each App Configuration replica has its separate request quota. This setup gives you a model for scalability and enhanced resiliency against transient and regional outages.
9997

10098
## Importing configuration data into App Configuration

articles/data-factory/connector-salesforce-service-cloud.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ author: jianleishen
77
ms.subservice: data-movement
88
ms.topic: conceptual
99
ms.custom: synapse
10-
ms.date: 04/01/2024
10+
ms.date: 08/21/2024
1111
---
1212

1313
# Copy data from and to Salesforce Service Cloud using Azure Data Factory or Azure Synapse Analytics
@@ -165,8 +165,8 @@ To copy data from and to Salesforce Service Cloud, set the type property of the
165165
| Property | Description | Required |
166166
|:--- |:--- |:--- |
167167
| type | The type property must be set to **SalesforceServiceCloudV2Object**. | Yes |
168-
| objectApiName | The Salesforce Service Cloud object name to retrieve data from. | No for source (if "SOQLQuery" in source is specified), Yes for sink |
169-
| reportId | The ID of the Salesforce Service Cloud report to retrieve data from. It is not supported in sink. Note that there are [limitations](https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_limits_limitations.htm) when you use reports. | No for source (if "SOQLQuery" in source is specified), not support sink |
168+
| objectApiName | The Salesforce Service Cloud object name to retrieve data from. The applicable self-hosted integration runtime version is 5.44.8984.1 or above. | No for source (if "query" in source is specified), Yes for sink |
169+
| reportId | The ID of the Salesforce Service Cloud report to retrieve data from. It is not supported in sink. Note that there are [limitations](https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_limits_limitations.htm) when you use reports. The applicable self-hosted integration runtime version is 5.44.8984.1 or above. | No for source (if "query" in source is specified), not support sink |
170170

171171
> [!IMPORTANT]
172172
> The "__c" part of **API Name** is needed for any custom object.
@@ -203,7 +203,7 @@ To copy data from Salesforce Service Cloud, set the source type in the copy acti
203203
| Property | Description | Required |
204204
|:--- |:--- |:--- |
205205
| type | The type property of the copy activity source must be set to **SalesforceServiceCloudV2Source**. | Yes |
206-
| SOQLQuery | Use the custom query to read data. You can only use [Salesforce Object Query Language (SOQL)](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) query with limitations. For SOQL limitations, see this [article](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). If query is not specified, all the data of the Salesforce object specified in "ObjectApiName/reportId" in dataset will be retrieved. | No (if "ObjectApiName/reportId" in the dataset is specified) |
206+
| query | Use the custom query to read data. You can only use [Salesforce Object Query Language (SOQL)](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) query with limitations. For SOQL limitations, see this [article](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). If query is not specified, all the data of the Salesforce object specified in "objectApiName/reportId" in dataset will be retrieved. | No (if "objectApiName/reportId" in the dataset is specified) |
207207
| includeDeletedObjects | Indicates whether to query the existing records, or query all records including the deleted ones. If not specified, the default behavior is false. <br>Allowed values: **false** (default), **true**. | No |
208208

209209
> [!IMPORTANT]
@@ -233,7 +233,7 @@ To copy data from Salesforce Service Cloud, set the source type in the copy acti
233233
"typeProperties": {
234234
"source": {
235235
"type": "SalesforceServiceCloudV2Source",
236-
"SOQLQuery": "SELECT Col_Currency__c, Col_Date__c, Col_Email__c FROM AllDataType__c",
236+
"query": "SELECT Col_Currency__c, Col_Date__c, Col_Email__c FROM AllDataType__c",
237237
"includeDeletedObjects": false
238238
},
239239
"sink": {
@@ -343,9 +343,9 @@ The Salesforce Service Cloud connector offers new functionalities and is compati
343343

344344
|Salesforce Service Cloud |Salesforce Service Cloud (legacy)|
345345
|:---|:---|
346-
|Support SOQL within [Salesforce Bulk API 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). <br>For SOQL queries: <br>• GROUP BY, LIMIT, ORDER BY, OFFSET, or TYPEOF clauses are not supported. <br>• Aggregate Functions such as COUNT() are not supported, you can use Salesforce reports to implement them. <br>• Date functions in GROUP BY clauses are not supported, but they are supported in the WHERE clause. <br>• Compound address fields or compound geolocation fields are not supported. As an alternative, query the individual components of compound fields. <br>• Parent-to-child relationship queries are not supported, whereas child-to-parent relationship queries are supported. |Support both SQL and SOQL syntax. |
347-
|Objects that contain binary fields are not supported.| Objects that contain binary fields are supported, like Attachment object.|
348-
|Support objects within Bulk API. For more information, see this [article](https://help.salesforce.com/s/articleView?id=000383508&type=1).|Support objects that are not supported by Bulk API, like CaseStatus.|
346+
|Support SOQL within [Salesforce Bulk API 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). <br>For SOQL queries: <br>• GROUP BY, LIMIT, ORDER BY, OFFSET, or TYPEOF clauses aren't supported. <br>• Aggregate Functions such as COUNT() aren't supported, you can use Salesforce reports to implement them. <br>• Date functions in GROUP BY clauses aren't supported, but they're supported in the WHERE clause. <br>• Compound address fields or compound geolocation fields aren't supported. As an alternative, query the individual components of compound fields. <br>• Parent-to-child relationship queries aren't supported, whereas child-to-parent relationship queries are supported. |Support both SQL and SOQL syntax. |
347+
| Objects that contain binary fields aren't supported when specifying query. | Objects that contain binary fields are supported when specifying query.|
348+
| Support objects within Bulk API when specifying query. | Support objects that are unsupported with Bulk API when specifying query.|
349349
|Support report by selecting a report ID.|Support report query syntax, like `{call "<report name>"}`.|
350350

351351
## Related content

0 commit comments

Comments
 (0)