Azure Container Instance (ACI) — Installation Salesforce

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 de la solution dans sa propre architecture.

Un architecte familier du contexte client et de 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 : utilisé pour le stockage et le traitement des données.
• RabbitMQ : planifie les 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 front-end et le back-end 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 registre de conteneurs. Il existe plusieurs façons de déployer ce conteneur, mais DQE recommande d'utiliser une Azure Container Instance.

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

Cela nécessite la configuration d'une Azure Gateway, ou d'un autre équilibreur de charge, pour exposer cette application avec une adresse IP publique et un DNS. Sinon, l'organisation Salesforce sur laquelle le package d'interface utilisateur est installé ne pourra pas accéder à l'application.

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

2. Matrice des flux

Le diagramme ci-dessous décrit tous les flux entrants et sortants de l'Azure Application Gateway dans un traitement de données Unify standard.

Toutes les adresses IP et tous les ports décrits dans ce diagramme doivent être ouverts sur votre passerelle ou votre pare-feu pour que le traitement puisse se terminer. Toutes les connexions entrantes utilisent HTTPS.

3. Connexions Salesforce

Authentification

Lorsque vous installez le package Unify-UI sur votre organisation Salesforce, vous devez effectuer plusieurs étapes de configuration. Au cours de ces étapes, l'organisation Salesforce s'enregistre auprès du Unify Server. À ce stade, 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.

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

Ce JWT ne peut être validé par Salesforce que pour les utilisateurs activés dans l'application connectée installée avec le package Unify-UI.

Plus d'informations sont disponibles dans la documentation officielle Salesforce ici.

Processus

La section suivante décrit les flux entre Salesforce et l'ACI Unify Server, ainsi qu'entre l'ACI Unify Server et les serveurs DQE.

Étape 1 - Définir un nouveau traitement

Un utilisateur Salesforce définit un nouveau traitement.

Exemple de description de 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 connexions autorisées dans la configuration de l'application connectée.

Étape 3 - Envoyer la demande de traitement

La demande de traitement est envoyée à l'ACI Unify Server.

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

L'ACI Unify Server s'authentifie auprès de Salesforce via l'application connectée à l'aide d'un jeton JWT.

Étape 5 - Exporter les données

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

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

L'ACI 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 qualité des données : l'ACI Unify Server effectue des appels API unitaires anonymisés pour chaque email du fichier extrait. Cela s'applique uniquement à la qualification des emails.

Durant 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 au serveur de production DQE-Software.

Si le traitement est un traitement de dédoublonnage : l'ACI 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

L'ACI Unify Server agrège toutes les réponses de traitement dans un fichier CSV final.

Si le traitement est un dédoublonnage, l'ACI Unify Server calcule le résultat de la 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.

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

L'ACI 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

L'ACI Unify Server envoie les résultats du traitement aux enregistrements concernés, par exemple Person Account, via les API Bulk 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 auquel l'enregistrement a été rattaché et, le cas échéant, le champ stockant le résultat de la fusion pour ce groupe.

Étape 12 - Supprimer les fichiers CSV

L'ACI Unify Server supprime le fichier CSV initialement reçu lors de l'export à l'étape 6 et le fichier CSV généré contenant les résultats de l'étape 8.

Étape 13 - Envoyer le rapport de traitement

L'ACI 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.

4. Installation

Cette section décrit le protocole d'installation utilisé pour créer une instance de DQE Unify Server en tant qu'Azure Container Instance.

Elle fournit également un exemple de création d'une Azure Application Gateway.

Cette partie dépend fortement de l'organisation propre du client. L'équipe technique du client est responsable de l'application des différentes recommandations.

Pour plus d'informations sur la configuration d'une Azure Application Gateway, consultez la documentation Microsoft ici.

4.1. Créer une Application Gateway

4.1.1. Onglet Basique

Le premier onglet affiche un formulaire similaire à celui ci-dessous. Renseignez les différentes parties comme indiqué.

4.1.1.1. Stratégie WAF

Le WAF (Web Application Firewall) est utilisé pour 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 l'4.1.1. Onglet Basique.

4.1.1.2. VNET

Le VNET (Virtual Network) est utilisé pour connecter l'Application Gateway et l'ACI (Azure Container Instance). Tous les flux transitent par ce réseau privé.

Créez un nouveau VNET depuis le champ Virtual network dans l'4.1.1. Onglet Basique.

4.1.2. Frontends

L'onglet Frontends affiche un formulaire similaire à celui ci-dessous. Renseignez les différentes parties comme indiqué.

4.1.2.1. Adresse IP publique

L'adresse IP publique est exposée par l'Application Gateway et sert à router le trafic vers l'ACI.

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

4.1.3. Backends

L'onglet Backends affiche un formulaire similaire à celui ci-dessous. Renseignez les différentes parties comme indiqué.

4.1.3.1. Backend Pool

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

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

4.1.4. Configuration

L'onglet Configuration affiche un formulaire similaire à celui ci-dessous. Renseignez les différentes parties comme indiqué.

4.1.4.1. Règles de routage - Listener

Cette configuration autorise les appels à l'Application Gateway via HTTPS.

4.1.4.2. Règles de routage - Backend Target

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

4.1.4.3. Règles de routage - Backend Setting

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

Cliquez ensuite sur Review + create.

4.2. Créer une Container Instance à partir d'un fichier YAML

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

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

4.2.2. 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

Consultez la documentation Microsoft ici.

4.2.3. Créer un compte de stockage

4.2.3.1. Onglet Basics

4.2.3.2. Advanced

Rien à modifier.

4.2.3.3. Networking

4.2.3.4. Data Protection

Rien à modifier.

4.2.3.5. Encryption

Rien à modifier.

4.2.3.6. Tags

Rien à modifier.

4.2.3.7. Review + Create

Créez le compte de stockage.

4.2.4. Créer les partages de fichiers

Le conteneur nécessite trois partages de fichiers :

• rabbitvol
• nginxconf
• redisvol

Pour utiliser HTTPS sur l'ACI, Nginx est provisionné. Pour vous assurer que Nginx dispose de toutes les informations nécessaires, 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 mot de passe dans un fichier texte et téléversez-le dans le partage de fichiers.
• Le fichier default.conf défini dans 4.2.8. Configurer Nginx.

4.2.5. Créer un Log Analytics Workspace

Le Log Analytics Workspace est utilisé pour stocker tous les logs de l'ACI. Par défaut, les logs sont conservés pendant 30 jours.

4.2.5.1. Onglet Basics

4.2.5.2. Review + Create

Créez le Log Analytics Workspace.

4.2.5.3. Récupérer l'ID et la clé du Workspace

4.2.6. Fichier de configuration YAML de l'ACI

Sur votre machine locale, créez un fichier YAML. Le fichier de configuration YAML est fourni ci-dessous.

Vous devez renseigner les clés suivantes :

• name : <Container Group Name>
• location : <Location>
• imageRegistryCredentials.username : <Username provided by DQE>
• imageRegistryCredentials.password : <Password provided by DQE>
• diagnostics.logAnalytics.workspaceId : <Log Analytics Workspace ID>, disponible depuis 4.2.5.3. Récupérer l'ID et la clé du Workspace.
• diagnostics.logAnalytics.workspaceKey : <Log Analytics Workspace Key>, disponible depuis 4.2.5.3. Récupérer l'ID et la clé du Workspace.
• Toutes les valeurs <file share name>, <storage account name> et <storage account key>.

Exemple avec le compte de stockage et le partage de fichiers créés précédemment :

• <file share name> = redisvol
• <storage account name> = myaccountstoragename
• <storage account key> = disponible depuis Storage account > Access keys > Show keys.
• id : subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.Network/virtualNetworks/{VNETName}/subnets/{VNETSubnetsName}

Exemple :

name: <Container Group Name>  # Name of the container group
apiVersion: '2021-10-01'
location: <Location>
tags: {"docker-compose-application": "docker-compose-application"}
properties: # Properties of container group
  containers: # Array of container instances in the group
    # Redis Image configuration
    - name: redis
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.5
        volumeMounts: # Array of volume mounts for the instance
          -   name: redisvol
              mountPath: /data

    # RabbitMQ Image configuration
    - name: rabbitmq # Name of an instance
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 5672
        environmentVariables:
          -   name: RABBITMQ_DEFAULT_PASS
              value: guest
          -   name: RABBITMQ_DEFAULT_USER
              value: guest
          -   name: RABBITMQ_DEFAULT_VHOST
              value: admin

        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 1
        volumeMounts: # Array of volume mounts for the instance
          -   name: "rabbitvol"
              mountPath: /bitnami
              readOnly: false

    # Nginx Image configuration
    - name: nginx
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 80
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.25
        volumeMounts: # Array of volume mounts for the instance
          -   name: nginxconf
              mountPath: /etc/nginx/conf.d

    # Unify UI web server Image configuration
    - name: unify-ui
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        command:
          - "npm"
          - "start"
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 8001
        environmentVariables:
          -   name: SESSION_SECRET
              value: myveryimportantSecret
          -   name: PORT
              value: 8001
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.25

    # Unify web server Image configuration
    - name: one-server
      properties: # Properties of an instance
        image: <ImageURL>  # Container image used to create the instance
        command:
          - "bash"
          - "./entrypoint.sh"
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 8000
        environmentVariables:
          -   name: SFAPIVERSION 
              value: v59.0
          -   name: REDIS_URL
              value: redis://127.0.0.1:6379
          -   name: CLOUDAMQP_URL
              value: amqp://guest:guest@127.0.0.1:5672/admin
          -   name: CUSTOMUI
              value: http://127.0.0.1:8001
          -   name: UNIFYSERVERURL
              value: http://127.0.0.1:8000
          -   name: PORT
              value: 8000
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.25

    # Unify Worker Image configuration
    - name: queue-worker
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        command:
          - "python"
          - "-u"
          - "./unify/queue_worker.pyc"
        environmentVariables:
          -   name: SFAPIVERSION 
              value: v59.0
          -   name: WORKDIRPATH 
              value: /app/unify
          -   name: REDIS_URL
              value: redis://127.0.0.1:6379
          -   name: CLOUDAMQP_URL
              value: amqp://guest:guest@127.0.0.1:5672/admin
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 5
            cpu: 1

  # Credential to pull the Unify image from private container
  imageRegistryCredentials:
    - server: <ImageURL>
      username: <Username provide by DQE>
      password: <Password provide by DQE>

  diagnostics:
    logAnalytics:
      workspaceId: <Log Analytics Workspace Id>
      workspaceKey: <Log Analytics Workspace Key>

  restartPolicy: Always
  ipAddress: # IP address configuration of container group
    ports:
      - protocol: TCP
        port: 80
    type: Private
  osType: Linux

  # Volumes parametre (azure fileshared)
  volumes: # Array of volumes available to the instances
    - name: rabbitvol
      azureFile:
        shareName: <file share name>
        readOnly: false
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>

    - name: nginxconf
      azureFile:
        shareName: <file share name>
        readOnly: false
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>

    - name: redisvol
      azureFile:
        shareName: <file share name>
        readOnly: false
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>


  subnetIds: # Subnet to deploy the container group into
    - id: subscriptions/{subscriptions Id}/resourceGroups/{resourceGroupsName}/providers/Microsoft.Network/virtualNetworks/{VNETName}/subnets/{VNETSubnetsName}

4.2.7. Créer l'ACI

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

az login

Créez l'ACI à partir du fichier YAML :

az container create -g <your Resource Group Name> -f <.yaml file path>

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

4.2.8. Configurer Nginx

Créez un fichier default.conf contenant le contenu suivant. Cette configuration est utilisée pour la connexion HTTP entre la gateway et l'ACI via le sous-réseau privé.

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'ACI pour que Nginx soit mis à jour avec la dernière modification.

4.3. Configurer le backend pool de l'Application Gateway

Une fois l'ACI créée, accédez à Application Gateway > Backend Pool > your backend pool > Edit backend pool.

Ajoutez l'adresse IP privée de l'ACI que vous avez créée.

4.4. Configurer 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'ACI est active. Configurez la health probe, puis cliquez sur Test. Si le statut est Healthy, l'ACI est correctement configurée et démarrée.

Ajoutez une health probe depuis l'Application Gateway :

Cliquez sur Test > Add.

4.4.1. Configurer le DNS

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

4.4.2. Configuration du WAF

Le WAF est utilisé pour autoriser ou 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.

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

Dans les règles personnalisées, ajoutez :

• Les plages d'adresses IP Salesforce, incluant les plages basic et Hyperforce.
• Serveur de licence DQE check : demander au support.
• SF Automation 1 : demander au support.
• SF Automation 2 : demander au support.

Vous pouvez trouver la liste exhaustive des adresses IP Salesforce ici.

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