You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-app-configuration/faq.yml
+36-25Lines changed: 36 additions & 25 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ metadata:
6
6
author: zhenlan
7
7
ms.service: azure-app-configuration
8
8
ms.topic: faq
9
-
ms.date: 02/16/2024
9
+
ms.date: 09/11/2024
10
10
ms.author: zhenlwa
11
11
ms.custom: references_regions
12
12
title: Azure App Configuration FAQ
@@ -84,8 +84,13 @@ sections:
84
84
85
85
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.
86
86
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.
89
94
- **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.
90
95
- **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.
91
96
- **Cost**: There's no cost to use a Free tier store.
@@ -98,7 +103,7 @@ sections:
98
103
answer: |
99
104
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.
100
105
101
-
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).
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).
102
107
103
108
- question: Where does data stored in App Configuration reside?
104
109
answer: |
@@ -113,26 +118,10 @@ sections:
113
118
[!INCLUDE [Azure App Configuration availability zones table](../../includes/azure-app-configuration-availability-zones.md)]
114
119
115
120
- 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.
136
125
137
126
- question: How do I estimate the number of requests my application may send to App Configuration?
138
127
answer: |
@@ -142,10 +131,32 @@ sections:
142
131
143
132
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.
144
133
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.
146
135
147
136
†Free tier stores do not have frequent, repeated requests excluded from their daily limit.
148
137
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
+
149
160
- question: Why can't I create an App Configuration store with the same name as one that I just deleted?
150
161
answer: |
151
162
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.
Copy file name to clipboardExpand all lines: articles/azure-app-configuration/howto-best-practices.md
+2-4Lines changed: 2 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ services: azure-app-configuration
5
5
author: zhenlan
6
6
ms.service: azure-app-configuration
7
7
ms.topic: conceptual
8
-
ms.date: 02/20/2024
8
+
ms.date: 09/11/2024
9
9
ms.author: zhenlwa
10
10
ms.custom: "devx-track-csharp, mvc"
11
11
---
@@ -89,12 +89,10 @@ You can also make your App Configuration data accessible to your application as
89
89
90
90
Excessive requests to App Configuration can result in throttling or overage charges. To reduce the number of requests made:
91
91
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).
93
93
94
94
* 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.
95
95
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
-
98
96
*[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.
99
97
100
98
## Importing configuration data into App Configuration
Copy file name to clipboardExpand all lines: articles/data-factory/connector-salesforce-service-cloud.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ author: jianleishen
7
7
ms.subservice: data-movement
8
8
ms.topic: conceptual
9
9
ms.custom: synapse
10
-
ms.date: 04/01/2024
10
+
ms.date: 08/21/2024
11
11
---
12
12
13
13
# 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
165
165
| Property | Description | Required |
166
166
|:--- |:--- |:--- |
167
167
| 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 |
170
170
171
171
> [!IMPORTANT]
172
172
> 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
203
203
| Property | Description | Required |
204
204
|:--- |:--- |:--- |
205
205
| 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) |
207
207
| 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 |
208
208
209
209
> [!IMPORTANT]
@@ -233,7 +233,7 @@ To copy data from Salesforce Service Cloud, set the source type in the copy acti
233
233
"typeProperties": {
234
234
"source": {
235
235
"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",
237
237
"includeDeletedObjects": false
238
238
},
239
239
"sink": {
@@ -343,9 +343,9 @@ The Salesforce Service Cloud connector offers new functionalities and is compati
343
343
344
344
|Salesforce Service Cloud |Salesforce Service Cloud (legacy)|
345
345
|:---|:---|
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.|
349
349
|Support report by selecting a report ID.|Support report query syntax, like `{call "<report name>"}`.|
0 commit comments