Azure Container App (ACA) — Installation du serveur backend

Support DQE

Mise à jour 17 septembre 2026 11:55

Remarque : Tous les éléments décrits ci-dessous sont des recommandations de DQE, basées sur l'expérience de déploiement auprès de différents clients.

Le client est responsable de l'intégration dans sa propre architecture.

Un architecte familiarisé avec le contexte et l'infrastructure interne doit aligner les recommandations de DQE avec l'infrastructure du client.

Dans le cadre de l'installation, l'approche a été dockerisée et tous les composants sont déployés dans Docker.

Redis pour le stockage et le traitement des données
RabbitMQ – planificateur des actions effectuées par le moteur DQE
La base de données Redis est supprimée après chaque traitement

1. Architecture de déploiement

Les échanges entre le frontend et le backend sont détaillés ci-dessous.

Pour déployer une instance de l'application Unify Server sur votre organisation Azure, DQE-Software fournit un accès dédié au container registry. Il existe différentes façons de déployer ce conteneur, mais nous recommandons d'utiliser une Azure Container App.

La procédure est expliquée dans la section installation.

Cela implique la configuration d'une Azure Gateway, ou d'un autre load balancer, pour exposer cette application avec une adresse IP publique et un DNS. Sinon, l'organisation Salesforce où vous avez installé le package d'interface utilisateur ne pourra pas accéder à l'application.

Pour déployer cette application, vous devez créer un fichier de configuration YAML qui est détaillé dans ce document.

2. Matrice des flux

Voici un diagramme décrivant tous les flux entrants et sortants de l'Azure Application Gateway dans un processus de données Unify standard.

Toutes les adresses IP et tous les ports décrits dans ce diagramme doivent être ouverts dans votre gateway ou votre firewall pour que le traitement se termine. Toutes les connexions entrantes se font via HTTPS.

Diagramme de la matrice des flux ACA

3. Connexions Salesforce

Authentification

Lorsque vous installez le package Unify-UI sur votre organisation Salesforce, vous devrez suivre certaines étapes de configuration. Au cours de ces étapes, l'organisation Salesforce s'enregistrera auprès du Unify Server. À cette étape, le serveur crée un mot de passe unique et des identifiants de clé qui sont stockés dans votre organisation et utilisés pour s'authentifier auprès de votre instance Unify Server.

Diagramme d'authentification Salesforce

Le protocole de sécurité utilisé par Salesforce pour authentifier les utilisateurs et autoriser les différentes opérations effectuées par le package, telles que l'import et l'export en masse, est le JSON Web Token (JWT).

Ce JWT ne peut être validé par Salesforce que pour les utilisateurs activés dans la connected app installée avec le package Unify-UI.

Vous trouverez plus d'informations dans la documentation officielle Salesforce ici.

Processus

Vous trouverez ci-dessous la description des flux entre Salesforce et le ACA Unify Server, et entre le ACA Unify Server et les serveurs DQE.

Étape 1 - Définir un nouveau traitement

Un utilisateur Salesforce définit un nouveau traitement.

Description du traitement

Objet : Person Account
Type de traitement : Validation d'email
Champ traité : Email
Filtres : voir les règles métier

Étape 2 - Démarrer le traitement

Un utilisateur Salesforce démarre le traitement. Cet utilisateur doit faire partie des identifiants autorisés dans la configuration de la connected app.

Étape 3 - Envoyer la demande de traitement

La demande de traitement est envoyée au ACA Unify Server.

Étape 4 - S'authentifier auprès de Salesforce

Le ACA Unify Server s'authentifie auprès de Salesforce via la connected app à l'aide d'un token JWT.

Étape 5 - Exporter les données

Salesforce autorise le serveur à effectuer un export de données.

Flux d'export de données Salesforce

Étape 6 - Enregistrer les données exportées

Le ACA Unify Server exporte les données pertinentes, telles que les champs Id et Email de l'objet Person Account, et les enregistre dans Azure File Storage au format CSV.

Étape 7 - Traiter les données

Si le traitement est un traitement de Data Quality : le ACA Unify Server effectue des appels API unitaires anonymisés sur chaque email du fichier extrait. Cela ne s'applique qu'à la qualification d'email.

Pendant l'ensemble du traitement, il s'agit de la seule étape où certaines données peuvent être envoyées par API REST via une connexion sécurisée vers le serveur de production DQE-Software.

Si le traitement est un traitement de déduplication : le ACA Unify Server calcule les groupes de doublons et réconcilie les enregistrements selon les règles de rapprochement définies lors des ateliers.

Étape 8 - Générer le fichier de résultats

Le ACA Unify Server agrège toutes les réponses de traitement dans un fichier CSV final.

Si le traitement est une déduplication, le ACA Unify Server calcule le résultat de fusion des données au sein des groupes de doublons identifiés. Ce résultat est stocké dans le champ DQE_Fusion_Json_c créé à cet effet dans l'objet Lead, en attendant d'être utilisé si le processus de fusion est déclenché automatiquement ou manuellement à la fin du traitement.

Flux de génération du fichier de résultats

Étape 9 - S'authentifier auprès de Salesforce

Le ACA Unify Server s'authentifie auprès de Salesforce.

Étape 10 - Autoriser l'import ou la mise à jour

Salesforce autorise le serveur à effectuer un import ou une mise à jour de données.

Étape 11 - Envoyer les résultats du traitement

Le ACA Unify Server envoie les résultats du traitement aux enregistrements concernés, ici Person Account, via les Bulk APIs exposées par Salesforce. Les Person Accounts sont enrichis avec des champs créés à cet effet, tels que le numéro du groupe de doublons et, le cas échéant, le champ stockant le résultat de fusion de ce groupe.

Étape 12 - Supprimer les fichiers CSV

Le ACA Unify Server supprime le fichier CSV initialement reçu lors de l'export à l'étape 6 ainsi que le fichier CSV généré contenant les résultats de l'étape 8.

Étape 13 - Envoyer le rapport de traitement

Le ACA Unify Server envoie un rapport statistique de traitement à Salesforce, incluant le nombre d'enregistrements traités et le temps de traitement. Ce rapport est visible dans l'application Unify dans l'objet Runs.

Flux du rapport de traitement

3.1. Composition et services

La stack est composée d'images Docker orchestrées via Azure Container Apps. Pour chaque service, nous décrivons ci-dessous les attributs et leurs fonctions.

Application web (one-server)

Un conteneur backend qui contient une application de microservices. Cette application expose toutes les API appelées pour lancer les traitements, gérer les files de traitement et instancier les workers de traitement. Elle dépend de Redis et RabbitMQ pour fonctionner correctement. Ce service est exposé sur le web via le reverse proxy Nginx.

Paramètres Docker Compose

image : le nom de l'image hébergée sur le DQE Azure Container Registry :
```
<Name of the registry container>.azurecr.io/<name of the image>
```
depends_on : redis, rabbitmq
environment : SFAPIVERSION, PORT, REDIS_URL, CLOUDAMQP_URL, CUSTOMUI, UNIFYSERVERURL
command : bash ./entrypoint.sh

Worker (queue-worker)

Un conteneur backend qui traite les tâches en file d'attente de manière asynchrone. Il consomme les tâches de la file RabbitMQ et les exécute. Utilise la même image Docker que l'application web.

Paramètres à définir dans Docker Compose

image : même image que le service d'application web
depends_on : redis, rabbitmq
environment : SFAPIVERSION, WORKDIRPATH, REDIS_URL, CLOUDAMQP_URL
command : python -u ./unify/queue_worker.pyc

CustomUI

Ce service est une application web exposant un front utilisé pour configurer les règles de déduplication. Il doit donc également être exposé sur le web. Ce service consomme aussi certaines API du backend, par exemple pour récupérer des métadonnées du CRM.

image : <imageURL>
command : npm start
environment : PORT=8001, SESSION_SECRET

Nginx

Un reverse proxy qui transmet les requêtes HTTP/HTTPS entrantes de l'Application Gateway vers l'application web et CustomUI. Son fichier de configuration est stocké dans le partage Azure File nginxconf et monté dans le conteneur au démarrage.

image : <imageURL>
ports : 80
volume : nginxconf:/etc/nginx/conf.d

Redis

Ce service est une base de données clé/valeur utilisée pour stocker les clés de fonctionnement internes telles que les configurations d'organisation Salesforce, les sessions, etc.

Il est possible d'utiliser l'image officielle redis:alpine, mais par mesure de sécurité, certains fournisseurs cloud bloquent la récupération d'images publiques et n'autorisent que les images provenant de registries privés. Pour contourner cette restriction, DQE publie également une image Redis compatible sur son registry privé.

Paramètres

image : <imageURL>
volumes : redisvol:/data (Azure File Share)

RabbitMQ

Ce service est un puissant gestionnaire de file d'attente permettant la réception et la planification des demandes de traitement. Tant qu'un traitement n'a pas été attribué à un worker et terminé, il reste en attente dans la file. Cela permet également une résilience aux pannes — si le serveur est redémarré, il reprend le dernier traitement de la file là où il s'était arrêté.

Comme pour l'image du service Redis, vous avez la possibilité d'utiliser une version publique ou celle du registry privé DQE.

Paramètres

image : <imageURL>
volumes : rabbitvol:/var/lib/rabbitmq (Azure File Share)
environment : RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS, RABBITMQ_DEFAULT_VHOST

4. Installation

Dans cette section, nous décrivons le protocole d'installation permettant de créer une instance de DQE Unify Server en tant qu'Azure Container App.

Nous fournissons également un exemple de création d'une Azure Application Gateway.

Cependant, cette partie dépendra fortement de votre propre organisation. L'équipe technique du client est responsable de l'application des différentes recommandations.

Pour plus d'informations sur la configuration de votre Azure Application Gateway, reportez-vous à la documentation Microsoft ici.

4.1. Créer une Application Gateway

4.1.1. Onglet Basics

Le premier onglet doit présenter un formulaire comme suit. Renseignez les différentes parties comme indiqué ci-dessous.

Onglet Basics de l'Application Gateway

4.1.1.1. WAF Policy

Le WAF (Web Application Firewall) permet de définir les plages d'adresses IP autorisées à appeler l'Application Gateway, telles que les plages IP de Salesforce.

Créez un nouveau WAF depuis le champ WAF policy dans 4.1.1. Onglet Basics.

Configuration de la WAF policy

4.1.1.2. VNET

Le VNET (Virtual Network) permet de connecter l'Application Gateway et l'ACA (Azure Container App). Tous les flux passent par ce réseau privé.

Créez un nouveau VNET depuis le champ Virtual network dans 4.1.1. Onglet Basics.

Configuration du VNET

4.1.2. Frontends

Le premier onglet doit présenter un formulaire comme suit. Renseignez les différentes parties comme indiqué ci-dessous.

Frontends de l'Application Gateway

4.1.2.1. Public IP Address

L'IP publique est exposée par l'Application Gateway. Elle permet d'acheminer le trafic vers l'ACA.

Créez une nouvelle IP publique depuis le champ Public IP address dans 4.1.2. Frontends.

Configuration de l'IP publique

4.1.3. Backends

Le premier onglet doit présenter un formulaire comme suit. Renseignez les différentes parties comme indiqué ci-dessous.

Backends de l'Application Gateway

4.1.3.1. Backend Pool

Le backend pool permet à l'Application Gateway d'acheminer les flux via le VNET vers l'ACA. Il est automatiquement renseigné lors de l'étape Network de la création de l'ACA.

Créez un nouveau backend pool depuis Add a backend pool dans 4.1.3. Backends.

Configuration du backend pool

4.1.4. Configuration

Le premier onglet doit présenter un formulaire comme suit. Renseignez les différentes parties comme indiqué ci-dessous.

Configuration de l'Application Gateway

4.1.4.1. Routing Rules - Listener

Cette configuration permet les appels vers l'Application Gateway via le protocole HTTPS.

Listener des règles de routage

4.1.4.2. Routing Rules - Backend Target

Le backend target est utilisé par l'Application Gateway pour déterminer où acheminer le trafic entrant. Il utilise le backend pool créé précédemment.

Backend target des règles de routage

4.1.4.3. Routing Rules - Backend Setting

Le backend setting est utilisé par l'Application Gateway pour déterminer quel protocole utiliser lors de l'acheminement du trafic vers l'ACA. Ce trafic est envoyé via le VNET privé.

Avertissement : Le protocole doit être HTTP (et non HTTPS). L'ingress interne de l'ACA communique en HTTP au sein du VNET privé. Le protocole du backend setting doit être défini sur HTTP, et non HTTPS. S'il est défini sur HTTPS, l'Application Gateway ne parviendra pas à se connecter au backend de l'ACA.

Backend setting des règles de routage

Cliquez ensuite sur Review + create.

4.2. Créer un Container Apps Environment (ACAE)

4.2.1. Ajouter un sous-réseau VNET pour l'ACAE

Créez un nouveau sous-réseau délégué à Microsoft.App/environments à partir du VNET créé dans 4.1.1.2. VNET.

4.2.2. Installer Azure CLI

Azure CLI est requis sur votre ordinateur.

4.2.2.1. UNIX

$ sudo curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

4.2.2.2. Windows

Reportez-vous à la documentation Microsoft ici.

4.2.3. Créer l'ACAE

Remarque : La stack DQE Unify nécessite un Dedicated plan car le queue-worker a besoin de 5 Gi de mémoire, ce qui dépasse la limite de 2 Gi par conteneur du Consumption plan. Le flag --enable-workload-profiles active la prise en charge du Dedicated plan sur l'environnement.

4.2.3.1. UNIX

az containerapp env create \
 --name <container apps environments name> \
 --resource-group <resource group> \
 --location <location> \
 --internal-only true \
 --enable-workload-profiles \
 --infrastructure-subnet-resource-id $(az network vnet subnet show \
    --resource-group <vnet resource group> \
    --vnet-name <vnet name (created on 4.1.1.1)> \
    --name <subnet name (created on 4.2.1)> \
    --query id -o tsv)

4.2.3.2. Windows

az containerapp env create `
 --name <container apps environments name> `
 --resource-group <resource group> `
 --location <location> `
 --internal-only true `
 --enable-workload-profiles `
 --infrastructure-subnet-resource-id $(az network vnet subnet show `
    --resource-group <vnet resource group> `
    --vnet-name <vnet name (created on 4.1.1.1)> `
    --name <subnet name (created on 4.2.1)> `
    --query id -o tsv)

4.2.3.3. Ajouter un profil de charge de travail Dedicated (D8)

Ajoutez un profil de charge de travail Dedicated D8 (8 vCPU / 32 Gi) à l'environnement. Ce nœud fournit une capacité suffisante pour l'ensemble de la stack (5 vCPU / 10 Gi au total).

UNIX

az containerapp env workload-profile add \
  --name <container apps environments name> \
  --resource-group <resource group> \
  --workload-profile-name "Dedicated-D8" \
  --workload-profile-type D8 \
  --min-nodes 1 \
  --max-nodes 1

Windows

az containerapp env workload-profile add `
  --name <container apps environments name> `
  --resource-group <resource group> `
  --workload-profile-name "Dedicated-D8" `
  --workload-profile-type D8 `
  --min-nodes 1 `
  --max-nodes 1

4.3. Créer une Container App à partir du YAML

4.3.1. Créer un compte de stockage

4.3.1.1. Basics

Renseignez toutes les informations nécessaires.

4.3.1.2. Advanced

Rien à modifier.

4.3.1.3. Onglet Networking

4.3.1.4. Data protection

Rien à modifier.

4.3.1.5. Encryption

Rien à modifier.

4.3.1.6. Tags

Rien à modifier.

4.3.1.7. Review + Create

Créez le compte de stockage.

4.3.2. Créer les partages de fichiers

Le conteneur nécessite trois partages de fichiers : rabbitvol, nginxconf et redisvol.

Création du partage de fichiers

Pour utiliser HTTPS sur l'ACA, Nginx est provisionné. Pour vous assurer qu'il dispose de toutes les informations requises, ajoutez les fichiers suivants au partage de fichiers nginxconf :

Le fichier de certificat SSL .pem ou .crt
Le fichier de clé SSL .key
Si le fichier .pem possède un mot de passe, ajoutez-le dans un fichier texte et ajoutez ce fichier texte au partage de fichiers
Le fichier default.conf défini dans 4.3.6. Configurer Nginx

4.3.3. Créer un environnement de stockage

La procédure ci-dessous doit être exécutée pour chaque nom de partage de fichiers créé précédemment :

redisvol
rabbitvol
nginxconf

4.3.3.1. UNIX

az containerapp env storage set \
　　--access-mode ReadWrite \
　　--azure-file-account-name <account storage name> \
　　--azure-file-account-key <account storage key> \
　　--azure-file-share-name <fileshare name (redisvol, rabbitvol, nginxconf)> \
　　--storage-name <storage environment name (redisvol, rabbitvol, nginxconf)> \
　　--name <container app name> \
　　--resource-group <resource group> \
　　--output table

4.3.3.2. Windows

az containerapp env storage set `
　　--access-mode ReadWrite `
　　--azure-file-account-name <account storage name> `
　　--azure-file-account-key <account storage key> `
　　--azure-file-share-name <fileshare name (redisvol, rabbitvol, nginxconf)> `
　　--storage-name <storage environment name (redisvol, rabbitvol, nginxconf)> `
　　--name <container app name> `
　　--resource-group <resource group> `
　　--output table

4.3.4. Fichier de configuration YAML de la Container App

Sur votre machine locale, créez un fichier YAML pour l'Azure Container App. Le format ACA est différent du format ACI : les volumes utilisent storageType: AzureFile en référençant les noms d'environnement de stockage créés dans 4.3.3, et les identifiants du registry sont déclarés dans configuration.registries. Tous les conteneurs partagent le même espace de noms réseau au sein d'une seule container app, donc la communication inter-conteneurs utilise localhost.

Vous devez compléter les clés suivantes :

environmentId : l'ID de ressource complet de l'ACAE créé dans 4.2.3. Format : subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.App/managedEnvironments/{container apps environments name}
location : <Location>
configuration.registries : server, username et passwordSecretRef référençant le mot de passe du registry fourni par DQE
volumes.storageName : doit correspondre aux noms d'environnement de stockage créés dans 4.3.3 : redisvol, rabbitvol et nginxconf.

Avertissement : Chemin de montage du volume RabbitMQ : le YAML monte le volume RabbitMQ sur /bitnami (chemin de l'image Bitnami). Si vous utilisez plutôt l'image officielle rabbitmq, remplacez le mountPath par /var/lib/rabbitmq. L'utilisation d'un chemin incorrect entraînera le démarrage de RabbitMQ sans persistance et pourra provoquer des échecs d'écriture des données.

location: <Location>
name: dqe-unify
type: Microsoft.App/containerApps
properties:
  # Reference the Dedicated D8 workload profile created on 4.2.3.3
  workloadProfileName: "Dedicated-D8"
  environmentId: /subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.App/managedEnvironments/{container apps environments name (created on 4.2.3)}
  configuration:
    activeRevisionsMode: Single
    ingress:
      external: false   # Traffic comes from the Application Gateway via private VNET
      targetPort: 80
    registries:
      - server: <registry URL>
        username: <Username provided by DQE>
        passwordSecretRef: registry-password
    secrets:
      - name: registry-password
        value: <Password provided by DQE>
  template:
    containers:

      # Redis — 0.5 vCPU / 1 Gi (ratio 1:2)
      - name: redis
        image: <ImageURL>
        resources:
          cpu: 0.5
          memory: 1Gi
        volumeMounts:
          - volumeName: redisvol
            mountPath: /data

      # RabbitMQ — 1 vCPU / 2 Gi (ratio 1:2)
      - name: rabbitmq
        image: <ImageURL>
        resources:
          cpu: 1
          memory: 2Gi
        env:
          - name: RABBITMQ_DEFAULT_PASS
            value: guest
          - name: RABBITMQ_DEFAULT_USER
            value: guest
          - name: RABBITMQ_DEFAULT_VHOST
            value: admin
        volumeMounts:
          - volumeName: rabbitvol
            mountPath: /bitnami

      # Nginx — 0.25 vCPU / 0.5 Gi (ratio 1:2)
      - name: nginx
        image: <ImageURL>
        resources:
          cpu: 0.25
          memory: 0.5Gi
        volumeMounts:
          - volumeName: nginxconf
            mountPath: /etc/nginx/conf.d

      # Unify UI — 0.25 vCPU / 0.5 Gi (ratio 1:2)
      - name: unify-ui
        image: <ImageURL>
        command: ["npm", "start"]
        resources:
          cpu: 0.25
          memory: 0.5Gi
        env:
          - name: SESSION_SECRET
            value: myveryimportantSecret
          - name: PORT
            value: "8001"

      # Unify web server — 0.5 vCPU / 1 Gi (ratio 1:2)
      - name: one-server
        image: <ImageURL>
        command: ["bash", "./entrypoint.sh"]
        resources:
          cpu: 0.5
          memory: 1Gi
        env:
          - name: SFAPIVERSION
            value: v59.0
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@localhost:5672/admin
          - name: CUSTOMUI
            value: http://localhost:8001
          - name: UNIFYSERVERURL
            value: http://localhost:8000
          - name: PORT
            value: "8000"

      # Queue Worker — 2.5 vCPU / 5 Gi (ratio 1:2) — requires Dedicated plan
      - name: queue-worker
        image: <ImageURL>
        command: ["python", "-u", "./unify/queue_worker.pyc"]
        resources:
          cpu: 2.5
          memory: 5Gi
        env:
          - name: SFAPIVERSION
            value: v59.0
          - name: WORKDIRPATH
            value: /app/unify
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@localhost:5672/admin

    # Azure File Share volumes — storageName must match names created on 4.3.3
    volumes:
      - name: redisvol
        storageType: AzureFile
        storageName: redisvol
      - name: rabbitvol
        storageType: AzureFile
        storageName: rabbitvol
      - name: nginxconf
        storageType: AzureFile
        storageName: nginxconf

    scale:
      minReplicas: 1   # Always keep 1 replica running
      maxReplicas: 1   # Single replica — no horizontal scaling for stateful services

4.3.5. Déployer la Container App

Sur votre machine locale, ouvrez une invite de commande et connectez-vous à Azure avec Azure CLI :

az login

Créez l'Azure Container App à partir du fichier YAML créé précédemment :

az containerapp create \
  --resource-group <your Resource Group Name> \
  --name dqe-unify \
  --environment <container apps environments name (created on 4.2.3)> \
  --yaml <yaml file path>

Une fois l'opération terminée, vous devriez obtenir les informations suivantes :

Résultat du déploiement de la container app

Avertissement : Ordre de démarrage : l'ACA démarre tous les conteneurs simultanément — il n'existe pas d'équivalent à dependsOn. RabbitMQ et Redis peuvent ne pas être prêts lorsque one-server et queue-worker démarrent. Si l'application n'inclut pas de logique de nouvelle tentative, les conteneurs planteront et redémarreront en boucle jusqu'à ce que les services soient disponibles. Ceci est géré automatiquement par restartPolicy: Always, mais peut entraîner un délai de 1 à 2 minutes avant que l'application soit pleinement opérationnelle.

4.3.6. Configurer Nginx

Créez un fichier default.conf avec le contenu suivant. Cette configuration gère la connexion HTTP entre l'Application Gateway et l'ACA via le VNET privé. Tous les conteneurs partagent le même espace de noms réseau au sein de la container app, donc le routage inter-conteneurs utilise localhost.

server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8001;
}

location /unify/ {
rewrite /unify/(.*) /$1 break;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8000;
}
}

Téléversez ce fichier dans le partage de fichiers nginxconf créé précédemment.

Avertissement : Redémarrez l'ACA pour que Nginx soit mis à jour avec la dernière modification.

4.4. Configuration du Backend Pool de l'Application Gateway

Une fois l'ACA créée, récupérez son FQDN interne. Contrairement à l'ACI, l'ACA avec ingress interne expose un nom d'hôte, et non une IP directe :

az containerapp show \
  --name dqe-unify \
  --resource-group <resource group> \
  --query "properties.configuration.ingress.fqdn" -o tsv

Le FQDN a le format suivant : dqe-unify.internal.<environment-id>.<region>.azurecontainerapps.io.

Accédez à Application Gateway > Backend Pool > {Your Backend Pool} > Edit the backend pool. Ajoutez le FQDN de l'ACA comme backend target et sélectionnez le type FQDN, et non l'adresse IP.

Configuration du backend pool de l'Application Gateway

4.5. Configuration de la Health Probe de l'Application Gateway

La health probe est utilisée par l'Application Gateway pour vérifier fréquemment si l'API sur l'ACA est active. Configurez la health probe, puis cliquez sur Test. Si le statut est Healthy, l'ACA est correctement configurée et démarrée.

Avertissement : Chemin de la health probe : définissez le chemin de la probe sur / (racine) et le protocole sur HTTP sur le port 80. Le Unify Server renvoie une réponse 200 sur le chemin racine lorsqu'il est actif. N'utilisez pas HTTPS pour la probe — l'ingress interne de l'ACA n'effectue pas de terminaison TLS sur le VNET privé.

Ajoutez une health probe depuis l'Application Gateway :

Configuration de la health probe de l'Application Gateway

Cliquez sur Test > Add.

4.5.1. Configurer le DNS

Vous devez contacter vos administrateurs, ou toute personne ayant accès à la zone DNS, et leur demander d'ajouter un nom DNS pointant vers l'adresse IP publique de votre Application Gateway.

4.5.2. Configuration du WAF

Le WAF permet d'autoriser ou de bloquer des adresses IP spécifiques tentant d'appeler l'Application Gateway. Pour que les traitements Salesforce fonctionnent, le WAF doit autoriser les plages IP de Salesforce.

Configuration du WAF

Dans le WAF, cliquez sur Switch to prevention mode. Cela permet au WAF d'utiliser les règles personnalisées ci-dessous.

Mode prévention du WAF

Dans les règles personnalisées, ajoutez :

Les plages d'adresses IP Salesforce, y compris les plages basic et Hyperforce
DQE check license server : demandez au support
SF Automation 1 : demandez au support
SF Automation 2 : demandez au support

Règles personnalisées du WAF

Vous trouverez la liste exhaustive des adresses IP Salesforce ici.

Une fois ces étapes terminées, vérifiez votre déploiement comme décrit dans 4.5. Configuration de la Health Probe de l'Application Gateway.

Associé à

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0

1. Architecture de déploiement

2. Matrice des flux

3. Connexions Salesforce

Authentification

Processus

Étape 1 - Définir un nouveau traitement

Étape 2 - Démarrer le traitement

Étape 3 - Envoyer la demande de traitement

Étape 4 - S'authentifier auprès de Salesforce

Étape 5 - Exporter les données

Étape 6 - Enregistrer les données exportées

Étape 7 - Traiter les données

Étape 8 - Générer le fichier de résultats

Étape 9 - S'authentifier auprès de Salesforce

Étape 10 - Autoriser l'import ou la mise à jour

Étape 11 - Envoyer les résultats du traitement

Étape 12 - Supprimer les fichiers CSV

Étape 13 - Envoyer le rapport de traitement

3.1. Composition et services

Application web (one-server)

Worker (queue-worker)

CustomUI

Nginx

Redis

RabbitMQ

4. Installation

4.1. Créer une Application Gateway

4.1.1. Onglet Basics

4.1.1.1. WAF Policy

4.1.1.2. VNET

4.1.2. Frontends

4.1.2.1. Public IP Address

4.1.3. Backends

4.1.3.1. Backend Pool

4.1.4. Configuration

4.1.4.1. Routing Rules - Listener

4.1.4.2. Routing Rules - Backend Target

4.1.4.3. Routing Rules - Backend Setting

4.2. Créer un Container Apps Environment (ACAE)

4.2.1. Ajouter un sous-réseau VNET pour l'ACAE

4.2.2. Installer Azure CLI

4.2.2.1. UNIX

4.2.2.2. Windows

4.2.3. Créer l'ACAE

4.2.3.1. UNIX

4.2.3.2. Windows

4.2.3.3. Ajouter un profil de charge de travail Dedicated (D8)

UNIX

Windows

4.3. Créer une Container App à partir du YAML

4.3.1. Créer un compte de stockage

4.3.1.1. Basics

4.3.1.2. Advanced

4.3.1.3. Onglet Networking

4.3.1.4. Data protection

4.3.1.5. Encryption

4.3.1.6. Tags

4.3.1.7. Review + Create

4.3.2. Créer les partages de fichiers

4.3.3. Créer un environnement de stockage

4.3.3.1. UNIX

4.3.3.2. Windows

4.3.4. Fichier de configuration YAML de la Container App

4.3.5. Déployer la Container App

4.3.6. Configurer Nginx

4.4. Configuration du Backend Pool de l'Application Gateway

4.5. Configuration de la Health Probe de l'Application Gateway

4.5.1. Configurer le DNS

4.5.2. Configuration du WAF

Cet article vous a-t-il été utile ?

Previous article

Next article