Ресурс, который напрямую связан с приложением Logi c, функцией или другим внутренним Azure ресурсом, является бэкэндами (примечание во множественном числе):
{
"name": "string",
"type": "Microsoft.ApiManagement/service/backends",
"apiVersion": "2019-01-01",
"properties": {
"title": "string",
"description": "string",
"resourceId": "string",
"properties": {
"serviceFabricCluster": {
"clientCertificatethumbprint": "string",
"maxPartitionResolutionRetries": "integer",
"managementEndpoints": [
"string"
],
"serverCertificateThumbprints": [
"string"
],
"serverX509Names": [
{
"name": "string",
"issuerCertificateThumbprint": "string"
}
]
}
},
"credentials": {
"certificate": [
"string"
],
"query": {},
"header": {},
"authorization": {
"scheme": "string",
"parameter": "string"
}
},
"proxy": {
"url": "string",
"username": "string",
"password": "string"
},
"tls": {
"validateCertificateChain": "boolean",
"validateCertificateName": "boolean"
},
"url": "string",
"protocol": "string"
}
}
Я считаю , что если вы укажете свойство resourceId
, инфраструктура Azure автоматически подключит другие свойства к вашей функции (или приложению Logi c). Формат "id" неочевиден, он ожидает URI управления , формат которого , упомянутый в этой документации
Затем вы связываете эти созданные бэкэнды для операции, использующей политику операции - это боль для express в шаблонах ARM, но она должна содержать выражение политики:
<set-backend-service backend-id=\"[name of your backend]\"/>
Пример того, как они связаны друг с другом, можно найти в этот связанный образец . Он поддерживает Service Fabri c, но в целом он также должен применяться к функциям.