Azure Container App (ACA) — Instalación del servidor backend

Nota: Todos los elementos descritos a continuación son recomendaciones de DQE, basadas en la experiencia de implementación con diferentes clientes.

El cliente es responsable de la integración en su propia arquitectura.

Un arquitecto familiarizado con el contexto y la infraestructura interna debe alinear las recomendaciones de DQE con la infraestructura del cliente.

Como parte de la instalación, el enfoque se ha dockerizado y todos los componentes se despliegan en Docker.

• Redis para el almacenamiento y procesamiento de datos
• RabbitMQ – planificador de las acciones realizadas por el motor DQE
• La base de datos Redis se elimina después de cada proceso

1. Arquitectura de despliegue

A continuación se detallan los intercambios entre el front end y el back end.

Para desplegar una instancia de la aplicación Unify Server en su organización de Azure, DQE-Software proporciona acceso dedicado al container registry. Existen diferentes formas de desplegar este contenedor, pero recomendamos utilizar un Azure Container App.

El procedimiento se explica en la sección de instalación.

Esto implica la configuración de un Azure Gateway, u otro balanceador de carga, para exponer esta aplicación con una dirección IP pública y DNS. De lo contrario, la organización de Salesforce en la que instaló el paquete de interfaz de usuario no podrá acceder a la aplicación.

Para desplegar esta aplicación, debe crear un archivo de configuración YAML que se detalla en este documento.

2. Matriz de flujos

A continuación se muestra un diagrama que describe todos los flujos entrantes y salientes del Azure Application Gateway en un proceso de datos estándar de Unify.

Todas las direcciones IP y puertos descritos en este diagrama deben estar abiertos en su gateway o firewall para que el proceso se complete. Todas las conexiones entrantes se realizan a través de HTTPS.

3. Conexiones de Salesforce

Autenticación

Cuando instala el paquete Unify-UI en su organización de Salesforce, deberá pasar por algunos pasos de configuración. Durante estos pasos, la organización de Salesforce se registrará en el Unify Server. En este paso, el servidor crea una contraseña única y credenciales de clave que se almacenan en su organización y se utilizan para autenticarse en su instancia de Unify Server.

El protocolo de seguridad utilizado por Salesforce para autenticar usuarios y permitir las diversas operaciones realizadas por el paquete, como la importación y exportación masiva, es JSON Web Token (JWT).

Este JWT solo puede ser validado por Salesforce para los usuarios habilitados en la connected app instalada con el paquete Unify-UI.

Puede encontrar más información en la documentación oficial de Salesforce aquí.

Proceso

A continuación se describe los flujos entre Salesforce y el Unify Server en ACA, y entre el Unify Server en ACA y los servidores de DQE.

Paso 1 - Definir un nuevo proceso

Un usuario de Salesforce define un nuevo proceso.

Descripción del proceso

• Object: Person Account
• Type of processing: Email validation
• Processed field: Email
• Filters: ver las reglas de negocio

Paso 2 - Iniciar el proceso

Un usuario de Salesforce inicia el proceso. Este usuario debe formar parte de los logins autorizados en la configuración de la connected app.

Paso 3 - Enviar la solicitud de procesamiento

La solicitud de procesamiento se envía al Unify Server en ACA.

Paso 4 - Autenticarse con Salesforce

El Unify Server en ACA se autentica con Salesforce a través de la connected app utilizando un token JWT.

Paso 5 - Exportar datos

Salesforce permite al servidor realizar una exportación de datos.

Paso 6 - Guardar los datos exportados

El Unify Server en ACA exporta los datos relevantes, como los campos Id y Email del objeto Person Account, y los guarda en Azure File Storage en formato CSV.

Paso 7 - Procesar los datos

Si el proceso es de calidad de datos: el Unify Server en ACA realiza llamadas API unitarias y anonimizadas sobre cada email del archivo extraído. Esto se aplica únicamente a la cualificación de email.

Durante todo el proceso, este es el único paso en el que se pueden enviar algunos datos mediante API REST, a través de una conexión segura, al servidor de producción de DQE-Software.

Si el proceso es de deduplicación: el Unify Server en ACA calcula los grupos de duplicados y concilia los registros según las reglas de coincidencia definidas durante los talleres.

Paso 8 - Generar el archivo de resultados

El Unify Server en ACA agrega todas las respuestas del procesamiento en un archivo CSV final.

Si el proceso es de deduplicación, el Unify Server en ACA calcula el resultado de la fusión de datos dentro de los grupos de duplicados identificados. Este resultado se almacena en el campo DQE_Fusion_Json_c creado para este fin en el objeto Lead, a la espera de utilizarse si el proceso de fusión se activa automáticamente o manualmente al final del procesamiento.

Paso 9 - Autenticarse en Salesforce

El Unify Server en ACA se autentica en Salesforce.

Paso 10 - Permitir la importación o actualización

Salesforce permite al servidor realizar una importación o actualización de datos.

Paso 11 - Enviar los resultados del procesamiento

El Unify Server en ACA envía los resultados del procesamiento a los registros correspondientes, en este caso Person Account, mediante las Bulk APIs expuestas por Salesforce. Las Person Accounts se enriquecen con campos creados para este fin, como el número de grupo de duplicados y, en su caso, el campo que almacena el resultado de la fusión de ese grupo.

Paso 12 - Eliminar los archivos CSV

El Unify Server en ACA elimina el archivo CSV recibido inicialmente durante la exportación en el paso 6, así como el archivo CSV generado que contiene los resultados del paso 8.

Paso 13 - Enviar el informe de procesamiento

El Unify Server en ACA envía un informe estadístico de procesamiento a Salesforce, que incluye el número de registros procesados y el tiempo de procesamiento. Este informe es visible en la aplicación Unify, en el objeto Runs.

3.1. Composición y servicios

El stack está compuesto por imágenes Docker orquestadas mediante Azure Container Apps. A continuación se describen los atributos de cada servicio y sus funciones.

Web Application (one-server)

Un contenedor backend que contiene una aplicación de microservicios. Esta aplicación expone todas las API llamadas para lanzar procesos, gestionar las colas de procesamiento e instanciar los workers de procesamiento. Depende de Redis y RabbitMQ para funcionar correctamente. Este servicio se expone en la web a través del reverse proxy Nginx.

Configuración de Docker Compose

• image: el nombre de la imagen alojada en el Azure Container Registry de DQE:

  <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 contenedor backend que procesa las tareas en cola de forma asíncrona. Consume tareas de la cola de RabbitMQ y las ejecuta. Utiliza la misma imagen Docker que la web application.

Parámetros a configurar en Docker Compose

• image: la misma imagen que el servicio web application
• depends_on: redis, rabbitmq
• environment: SFAPIVERSION, WORKDIRPATH, REDIS_URL, CLOUDAMQP_URL
• command: python -u ./unify/queue_worker.pyc

CustomUI

Este servicio es una aplicación web que expone un front utilizado para configurar las reglas de deduplicación. Por lo tanto, también debe exponerse en la web. Este servicio también consume algunas API del backend, por ejemplo para recuperar metadatos del CRM.

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

Nginx

Un reverse proxy que reenvía las solicitudes HTTP/HTTPS entrantes desde el Application Gateway hacia la web application y CustomUI. Su archivo de configuración se almacena en el Azure File Share nginxconf y se monta en el contenedor en tiempo de ejecución.

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

Redis

Este servicio es una base de datos clave/valor utilizada para almacenar claves de funcionamiento interno, como las configuraciones de la organización de Salesforce, las sesiones, etc.

Es posible utilizar la imagen oficial redis:alpine, pero como medida de seguridad, algunos proveedores cloud bloquean la obtención de imágenes públicas y solo permiten imágenes de registries privados. Para superar esta restricción, DQE también publica una imagen de Redis compatible en su registry privado.

Parámetros

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

RabbitMQ

Este servicio es un potente gestor de colas que permite la recepción y planificación de las solicitudes de procesamiento. Hasta que un proceso se asigne a un worker y se complete, permanecerá en la cola. Esto también permite la resiliencia ante fallos: si se reinicia el servidor, se retoma el último procesamiento de la cola donde se dejó.

Al igual que con la imagen del servicio Redis, tiene la opción de utilizar una versión pública o la del registry privado de DQE.

Parámetros

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

4. Instalación

En esta sección, describimos el protocolo de instalación para crear una instancia de DQE Unify Server como Azure Container App.

También ofrecemos un ejemplo de cómo crear un Azure Application Gateway.

Sin embargo, esta parte dependerá en gran medida de su propia organización. El equipo técnico del cliente es responsable de aplicar las diferentes recomendaciones.

Para más información sobre la configuración de su Azure Application Gateway, consulte la documentación de Microsoft aquí.

4.1. Crear un Application Gateway

4.1.1. Pestaña Basics

La primera pestaña debería mostrar un formulario como el siguiente. Complete las diferentes partes tal como se muestra a continuación.

4.1.1.1. WAF Policy

El WAF (Web Application Firewall) se utiliza para definir los rangos de IP autorizados a llamar al Application Gateway, como los rangos de IP de Salesforce.

Cree un nuevo WAF desde el campo WAF policy en 4.1.1. Pestaña Basics.

4.1.1.2. VNET

La VNET (Virtual Network) se utiliza para conectar el Application Gateway y el ACA (Azure Container App). Todos los flujos pasan por esa red privada.

Cree una nueva VNET desde el campo Virtual network en 4.1.1. Pestaña Basics.

4.1.2. Frontends

La primera pestaña debería mostrar un formulario como el siguiente. Complete las diferentes partes tal como se muestra a continuación.

4.1.2.1. Dirección IP pública

La IP pública es expuesta por el Application Gateway. Se utiliza para enrutar el tráfico hacia el ACA.

Cree una nueva IP pública desde el campo Public IP address en 4.1.2. Frontends.

4.1.3. Backends

La primera pestaña debería mostrar un formulario como el siguiente. Complete las diferentes partes tal como se muestra a continuación.

4.1.3.1. Backend Pool

El backend pool permite al Application Gateway enrutar los flujos a través de la VNET hacia el ACA. Se completa automáticamente durante el paso Network de la creación del ACA.

Cree un nuevo backend pool desde Add a backend pool en 4.1.3. Backends.

4.1.4. Configuration

La primera pestaña debería mostrar un formulario como el siguiente. Complete las diferentes partes tal como se muestra a continuación.

4.1.4.1. Routing Rules - Listener

Esta configuración permite las llamadas al Application Gateway a través del protocolo HTTPS.

4.1.4.2. Routing Rules - Backend Target

El backend target es utilizado por el Application Gateway para determinar hacia dónde enrutar el tráfico entrante. Utiliza el backend pool creado anteriormente.

4.1.4.3. Routing Rules - Backend Setting

El backend setting es utilizado por el Application Gateway para determinar qué protocolo usar al enrutar el tráfico hacia el ACA. Este tráfico se envía a través de la VNET privada.

Advertencia: El protocolo debe ser HTTP (no HTTPS). El ingress interno de ACA se comunica mediante HTTP dentro de la VNET privada. El protocolo del backend setting debe configurarse como HTTP, no HTTPS. Si se configura como HTTPS, el Application Gateway no podrá conectarse al backend de ACA.

A continuación, haga clic en Review + create.

4.2. Crear un Container Apps Environment (ACAE)

4.2.1. Añadir una subred VNET para el ACAE

Cree una nueva subred delegada a Microsoft.App/environments a partir de la VNET creada en 4.1.1.2. VNET.

4.2.2. Instalar Azure CLI

Se requiere Azure CLI en su ordenador.

4.2.2.1. UNIX

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

4.2.2.2. Windows

Consulte la documentación de Microsoft aquí.

4.2.3. Crear el ACAE

Nota: El stack DQE Unify requiere un plan Dedicated porque el queue-worker necesita 5 Gi de memoria, lo que supera el límite de 2 Gi por contenedor del plan Consumption. El flag --enable-workload-profiles activa el soporte del plan Dedicated en el entorno.

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. Añadir un workload profile Dedicated (D8)

Añada un workload profile Dedicated D8 (8 vCPU / 32 Gi) al entorno. Este nodo proporciona capacidad suficiente para el stack completo (5 vCPU / 10 Gi en 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. Crear un Container App a partir de YAML

4.3.1. Crear una cuenta de almacenamiento (Storage Account)

4.3.1.1. Basics

Complete toda la información necesaria.

4.3.1.2. Advanced

Nada que cambiar.

4.3.1.3. Pestaña Networking

4.3.1.4. Data protection

Nada que cambiar.

4.3.1.5. Encryption

Nada que cambiar.

4.3.1.6. Tags

Nada que cambiar.

4.3.1.7. Review + Create

Cree la cuenta de almacenamiento.

4.3.2. Crear los File Shares

El contenedor requiere tres file shares: rabbitvol, nginxconf y redisvol.

Para utilizar HTTPS en el ACA, se provisiona Nginx. Para asegurarse de que dispone de toda la información necesaria, añada los siguientes archivos al file share nginxconf:

• El archivo del certificado SSL .pem o .crt
• El archivo de la clave SSL .key
• Si el archivo .pem tiene una contraseña, añádala en un archivo de texto y agregue ese archivo al file share
• El archivo default.conf definido en 4.3.6. Configurar Nginx

4.3.3. Crear un Storage Environment

El siguiente procedimiento debe ejecutarse para cada nombre de file share creado previamente:

• 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. Archivo de configuración YAML del Container App

En su equipo local, cree un archivo YAML para el Azure Container App. El formato de ACA es diferente del formato de ACI: los volúmenes utilizan storageType: AzureFile haciendo referencia a los nombres de storage environment creados en 4.3.3, y las credenciales del registry se declaran en configuration.registries. Todos los contenedores comparten el mismo espacio de nombres de red dentro de una única container app, por lo que la comunicación entre contenedores utiliza localhost.

Debe completar las siguientes claves:

• environmentId: el ID de recurso completo del ACAE creado en 4.2.3. Formato: subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.App/managedEnvironments/{container apps environments name}
• location: <Location>
• configuration.registries: server, username y passwordSecretRef, haciendo referencia a la contraseña del registry proporcionada por DQE
• volumes.storageName: debe coincidir con los nombres de storage environment creados en 4.3.3: redisvol, rabbitvol y nginxconf.

Advertencia: ruta de montaje del volumen de RabbitMQ: el YAML monta el volumen de RabbitMQ en /bitnami (ruta de la imagen Bitnami). Si utiliza en su lugar la imagen oficial rabbitmq, cambie el mountPath a /var/lib/rabbitmq. Usar la ruta incorrecta hará que RabbitMQ se inicie sin persistencia y potencialmente falle al escribir datos.

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. Desplegar el Container App

En su equipo local, abra una línea de comandos e inicie sesión en Azure con Azure CLI:

az login

Cree el Azure Container App a partir del archivo YAML creado previamente:

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>

Una vez finalizada la operación, debería obtener la siguiente información:

Advertencia: orden de inicio: ACA inicia todos los contenedores simultáneamente; no existe un equivalente a dependsOn. Es posible que RabbitMQ y Redis no estén listos cuando se inicien one-server y queue-worker. Si la aplicación no incluye lógica de reintento, los contenedores fallarán y se reiniciarán en bucle hasta que los servicios estén disponibles. Esto se gestiona automáticamente mediante restartPolicy: Always, pero puede causar un retraso de 1 a 2 minutos antes de que la aplicación esté completamente operativa.

4.3.6. Configurar Nginx

Cree un archivo default.conf con el siguiente contenido. Esta configuración gestiona la conexión HTTP entre el Application Gateway y el ACA a través de la VNET privada. Todos los contenedores comparten el mismo espacio de nombres de red dentro del container app, por lo que el enrutamiento entre contenedores utiliza 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;
}
}

Cargue este archivo en el file share nginxconf creado previamente.

Advertencia: reinicie el ACA para que Nginx se actualice con el último cambio.

4.4. Configurar el Backend Pool del Application Gateway

Después de crear el ACA, obtenga su FQDN interno. A diferencia de ACI, ACA con ingress interno expone un nombre de host, no una IP directa:

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

El FQDN tiene el siguiente formato: dqe-unify.internal.<environment-id>.<region>.azurecontainerapps.io.

Vaya a Application Gateway > Backend Pool > {Your Backend Pool} > Edit the backend pool. Añada el FQDN de ACA como backend target y seleccione el tipo FQDN, no dirección IP.

4.5. Configurar el Health Probe del Application Gateway

El health probe es utilizado por el Application Gateway para comprobar frecuentemente si la API en el ACA está activa. Configure el health probe y, a continuación, haga clic en Test. Si el estado es Healthy, el ACA está correctamente configurado e iniciado.

Advertencia: ruta del health probe: configure la ruta del probe como / (raíz) y el protocolo como HTTP en el puerto 80. El Unify Server devuelve una respuesta 200 en la ruta raíz cuando está activo. No utilice HTTPS para el probe: el ingress interno de ACA no termina TLS en la VNET privada.

Añada un health probe desde el Application Gateway:

Haga clic en Test > Add.

4.5.1. Configurar el DNS

Debe contactar con sus administradores, o con cualquier persona con acceso a la zona DNS, y pedirles que añadan un nombre DNS que apunte a la IP pública de su Application Gateway.

4.5.2. Configuración del WAF

El WAF se utiliza para autorizar o bloquear direcciones IP específicas que intenten llamar al Application Gateway. Para que los procesos de Salesforce funcionen, el WAF debe autorizar los rangos de IP de Salesforce.

En el WAF, haga clic en Switch to prevention mode. Esto permite al WAF utilizar las reglas personalizadas siguientes.

En las reglas personalizadas, añada:

• Los rangos de direcciones IP de Salesforce, incluidos los rangos básicos y los de Hyperforce
• DQE check license server: consulte con el soporte
• SF Automation 1: consulte con el soporte
• SF Automation 2: consulte con el soporte

Puede encontrar la lista exhaustiva de direcciones IP de Salesforce aquí.

Tras completar estos pasos, compruebe su despliegue tal como se describe en 4.5. Configurar el Health Probe del Application Gateway.