Hinweis: Alle nachfolgend beschriebenen Elemente sind Empfehlungen von DQE, basierend auf Erfahrungen aus der Bereitstellung bei verschiedenen Kunden.
Der Kunde ist dafür verantwortlich, die Lösung in seine eigene Architektur zu integrieren.
Ein Architekt, der mit dem Kundenkontext und der internen Infrastruktur vertraut ist, sollte die Empfehlungen von DQE mit der Infrastruktur des Kunden abstimmen.
Im Rahmen der Installation wurde der Ansatz dockerisiert, und alle Komponenten werden in Docker bereitgestellt:
- Redis: wird zur Datenspeicherung und -verarbeitung verwendet.
- RabbitMQ: plant die vom DQE-Engine ausgeführten Aktionen.
- Die Redis-Datenbank wird nach jedem Prozess gelöscht.
1. Bereitstellungsarchitektur
Der Datenaustausch zwischen Frontend und Backend wird im Folgenden detailliert beschrieben.
Um eine Instanz der Unify Server-Anwendung in Ihrer Azure-Organisation bereitzustellen, stellt DQE-Software einen dedizierten Zugang zur Container Registry bereit. Es gibt mehrere Möglichkeiten, diesen Container bereitzustellen, DQE empfiehlt jedoch die Verwendung einer Azure Container Instance.
Das Vorgehen wird im Abschnitt Installation erläutert.
Hierfür ist die Konfiguration eines Azure Gateway oder eines anderen Load Balancers erforderlich, um diese Anwendung mit einer öffentlichen IP-Adresse und DNS verfügbar zu machen. Andernfalls kann die Salesforce-Organisation, in der das Benutzeroberflächenpaket installiert ist, nicht auf die Anwendung zugreifen.
Um diese Anwendung bereitzustellen, müssen Sie eine YAML-Konfigurationsdatei erstellen, die in diesem Dokument detailliert beschrieben wird.
2. Flussmatrix
Das folgende Diagramm beschreibt alle ein- und ausgehenden Datenflüsse des Azure Application Gateway in einem Standard-Unify-Datenprozess.
Alle in diesem Diagramm beschriebenen IP-Adressen und Ports müssen in Ihrem Gateway oder Ihrer Firewall geöffnet werden, damit der Prozess abgeschlossen werden kann. Alle eingehenden Verbindungen erfolgen über HTTPS.
3. Salesforce-Verbindungen
Authentifizierung
Wenn Sie das Unify-UI-Paket in Ihrer Salesforce-Organisation installieren, müssen Sie mehrere Konfigurationsschritte durchführen. Während dieser Schritte registriert sich die Salesforce-Organisation beim Unify Server. In diesem Schritt erstellt der Server ein eindeutiges Passwort und Schlüsselanmeldedaten, die in Ihrer Organisation gespeichert und zur Authentifizierung bei Ihrer Unify Server-Instanz verwendet werden.
Das von Salesforce verwendete Sicherheitsprotokoll zur Authentifizierung von Benutzern und zur Zulassung der vom Paket durchgeführten Vorgänge, wie z. B. Massenimport und -export, ist JSON Web Token (JWT).
Dieses JWT kann von Salesforce nur für Benutzer validiert werden, die in der mit dem Unify-UI-Paket installierten Connected App aktiviert sind.
Weitere Informationen finden Sie in der offiziellen Salesforce-Dokumentation hier.
Prozess
Der folgende Abschnitt beschreibt die Datenflüsse zwischen Salesforce und dem ACI Unify Server sowie zwischen dem ACI Unify Server und den DQE-Servern.
Schritt 1 – Einen neuen Prozess definieren
Ein Salesforce-Benutzer definiert einen neuen Prozess.
Beispielhafte Prozessbeschreibung:
- Objekt: Person Account
- Verarbeitungstyp: E-Mail-Validierung
- Verarbeitetes Feld: E-Mail
- Filter: siehe Geschäftsregeln.
Schritt 2 – Den Prozess starten
Ein Salesforce-Benutzer startet den Prozess. Dieser Benutzer muss zu den autorisierten Logins in der Connected-App-Konfiguration gehören.
Schritt 3 – Die Verarbeitungsanfrage senden
Die Verarbeitungsanfrage wird an den ACI Unify Server gesendet.
Schritt 4 – Bei Salesforce authentifizieren
Der ACI Unify Server authentifiziert sich über die Connected App mithilfe eines JWT-Tokens bei Salesforce.
Schritt 5 – Daten exportieren
Salesforce erlaubt dem Server, einen Datenexport durchzuführen.
Schritt 6 – Exportierte Daten speichern
Der ACI Unify Server exportiert die relevanten Daten, wie z. B. die Felder Id und Email des Objekts Person Account, und speichert sie im CSV-Format in Azure File Storage.
Schritt 7 – Die Daten verarbeiten
Wenn es sich um eine Data-Quality-Verarbeitung handelt: Der ACI Unify Server führt anonymisierte Einzel-API-Aufrufe für jede E-Mail in der extrahierten Datei durch. Dies gilt nur für die E-Mail-Qualifizierung.
Während des gesamten Prozesses ist dies der einzige Schritt, in dem einige Daten per REST-API über eine sichere Verbindung an den Produktionsserver von DQE-Software gesendet werden können.
Wenn es sich um eine Deduplizierungsverarbeitung handelt: Der ACI Unify Server berechnet Duplikatgruppen und gleicht Datensätze gemäß den während der Workshops definierten Abgleichsregeln ab.
Schritt 8 – Die Ergebnisdatei generieren
Der ACI Unify Server fasst alle Verarbeitungsantworten in einer finalen CSV-Datei zusammen.
Handelt es sich um eine Deduplizierung, berechnet der ACI Unify Server das Ergebnis der Datenzusammenführung innerhalb der identifizierten Duplikatgruppen. Dieses Ergebnis wird im dafür im Lead-Objekt erstellten Feld DQE_Fusion_Json_c gespeichert, bis es verwendet wird, falls der Zusammenführungsprozess am Ende der Verarbeitung automatisch oder manuell ausgelöst wird.
Schritt 9 – Bei Salesforce authentifizieren
Der ACI Unify Server authentifiziert sich bei Salesforce.
Schritt 10 – Import oder Aktualisierung zulassen
Salesforce erlaubt dem Server, einen Datenimport oder eine Aktualisierung durchzuführen.
Schritt 11 – Verarbeitungsergebnisse senden
Der ACI Unify Server sendet die Verarbeitungsergebnisse über die von Salesforce bereitgestellten Bulk-APIs an die relevanten Datensätze, zum Beispiel Person Account. Person Accounts werden mit eigens dafür erstellten Feldern angereichert, wie z. B. der Nummer der Duplikatgruppe, der der Datensatz zugeordnet wurde, und gegebenenfalls dem Feld, das das Zusammenführungsergebnis dieser Gruppe speichert.
Schritt 12 – CSV-Dateien löschen
Der ACI Unify Server löscht die ursprünglich in Schritt 6 beim Export empfangene CSV-Datei sowie die in Schritt 8 generierte CSV-Datei mit den Ergebnissen.
Schritt 13 – Den Verarbeitungsbericht senden
Der ACI Unify Server sendet einen statistischen Verarbeitungsbericht an Salesforce, der die Anzahl der verarbeiteten Datensätze und die Verarbeitungszeit enthält. Dieser Bericht ist in der Unify-Anwendung im Objekt Runs sichtbar.
4. Installation
Dieser Abschnitt beschreibt das Installationsprotokoll zur Erstellung einer Instanz des DQE Unify Server als Azure Container Instance.
Er enthält außerdem ein Beispiel für die Erstellung eines Azure Application Gateway.
Dieser Teil hängt stark von der jeweiligen Organisation des Kunden ab. Das technische Team des Kunden ist dafür verantwortlich, die verschiedenen Empfehlungen umzusetzen.
Weitere Informationen zur Konfiguration eines Azure Application Gateway finden Sie in der Microsoft-Dokumentation hier.
4.1. Ein Application Gateway erstellen
4.1.1. Basics-Tab
Der erste Tab zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.
4.1.1.1. WAF-Richtlinie
Die WAF (Web Application Firewall) wird verwendet, um die IP-Bereiche festzulegen, die zum Aufruf des Application Gateway berechtigt sind, z. B. die Salesforce-IP-Bereiche.
Erstellen Sie eine neue WAF über das Feld WAF policy im 4.1.1. Basics-Tab.
4.1.1.2. VNET
Das VNET (Virtual Network) wird verwendet, um das Application Gateway und die ACI (Azure Container Instance) zu verbinden. Alle Datenflüsse laufen über dieses private Netzwerk.
Erstellen Sie ein neues VNET über das Feld Virtual network im 4.1.1. Basics-Tab.
4.1.2. Frontends
Der Tab Frontends zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.
4.1.2.1. Öffentliche IP-Adresse
Die öffentliche IP-Adresse wird vom Application Gateway bereitgestellt und dient dazu, den Datenverkehr zur ACI weiterzuleiten.
Erstellen Sie eine neue öffentliche IP über das Feld Public IP address unter 4.1.2. Frontends.
4.1.3. Backends
Der Tab Backends zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.
4.1.3.1. Backend Pool
Der Backend Pool ermöglicht es dem Application Gateway, Datenflüsse über das VNET zur ACI weiterzuleiten. Er wird während des Schritts Network bei der ACI-Erstellung automatisch ausgefüllt.
Erstellen Sie einen neuen Backend Pool über Add a backend pool unter 4.1.3. Backends.
4.1.4. Configuration
Der Tab Configuration zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.
4.1.4.1. Routingregeln – Listener
Diese Konfiguration ermöglicht Aufrufe des Application Gateway über HTTPS.
4.1.4.2. Routingregeln – Backend Target
Das Backend Target wird vom Application Gateway verwendet, um zu bestimmen, wohin eingehender Datenverkehr weitergeleitet wird. Es nutzt den zuvor erstellten Backend Pool.
4.1.4.3. Routingregeln – Backend Setting
Das Backend Setting wird vom Application Gateway verwendet, um zu bestimmen, welches Protokoll beim Weiterleiten des Datenverkehrs an die ACI verwendet wird. Dieser Datenverkehr wird über das private VNET gesendet.
Klicken Sie anschließend auf Review + create.
4.2. Eine Container Instance aus einer YAML-Datei erstellen
4.2.1. Ein VNET-Subnetz für die ACI hinzufügen
Erstellen Sie ein neues Subnetz, das Microsoft.ContainerInstance/containerGroups zugeordnet ist, ausgehend von dem in 4.1.1.2. VNET erstellten VNET.
4.2.2. Azure CLI
Die Azure CLI muss auf Ihrem Computer installiert sein.
4.2.2.1. UNIX
sudo curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash4.2.2.2. Windows
Siehe die Microsoft-Dokumentation hier.
4.2.3. Ein Speicherkonto erstellen
4.2.3.1. Basics-Tab
4.2.3.2. Advanced
Nichts zu ändern.
4.2.3.3. Networking
4.2.3.4. Data Protection
Nichts zu ändern.
4.2.3.5. Encryption
Nichts zu ändern.
4.2.3.6. Tags
Nichts zu ändern.
4.2.3.7. Review + Create
Erstellen Sie das Speicherkonto.
4.2.4. Dateifreigaben erstellen
Der Container benötigt drei Dateifreigaben:
rabbitvolnginxconfredisvol
Um HTTPS auf der ACI zu verwenden, wird Nginx bereitgestellt. Damit Nginx über alle erforderlichen Informationen verfügt, fügen Sie der Dateifreigabe nginxconf die folgenden Dateien hinzu:
- Die SSL-Zertifikatsdatei
.pemoder.crt. - Die SSL-Schlüsseldatei
.key. - Falls die
.pem-Datei ein Passwort hat, fügen Sie das Passwort in einer Textdatei hinzu und laden Sie diese in die Dateifreigabe hoch. - Die Datei
default.conf, die in 4.2.8. Nginx konfigurieren definiert ist.
4.2.5. Einen Log Analytics Workspace erstellen
Der Log Analytics Workspace wird verwendet, um alle Logs der ACI zu speichern. Standardmäßig werden die Logs 30 Tage lang aufbewahrt.
4.2.5.1. Basics-Tab
4.2.5.2. Review + Create
Erstellen Sie den Log Analytics Workspace.
4.2.5.3. Workspace-ID und -Schlüssel abrufen
4.2.6. YAML-Konfigurationsdatei der ACI
Erstellen Sie auf Ihrem lokalen Rechner eine YAML-Datei. Die YAML-Konfigurationsdatei finden Sie unten.
Sie müssen die folgenden Schlüssel ausfüllen:
-
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>, verfügbar über 4.2.5.3. Workspace-ID und -Schlüssel abrufen. -
diagnostics.logAnalytics.workspaceKey:<Log Analytics Workspace Key>, verfügbar über 4.2.5.3. Workspace-ID und -Schlüssel abrufen. - Alle Werte für
<file share name>,<storage account name>und<storage account key>.
Beispiel mit dem zuvor erstellten Speicherkonto und der Dateifreigabe:
-
<file share name>=redisvol -
<storage account name>=myaccountstoragename -
<storage account key>= verfügbar über Storage account > Access keys > Show keys. -
id:subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.Network/virtualNetworks/{VNETName}/subnets/{VNETSubnetsName}
Beispiel:
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. Die ACI erstellen
Öffnen Sie auf Ihrem lokalen Rechner eine Eingabeaufforderung und melden Sie sich mit der Azure CLI bei Azure an:
az loginErstellen Sie die ACI aus der YAML-Datei:
az container create -g <your Resource Group Name> -f <.yaml file path>Nach Abschluss des Vorgangs sollten Sie die folgenden Informationen sehen:
4.2.8. Nginx konfigurieren
Erstellen Sie eine Datei default.conf mit folgendem Inhalt. Diese Konfiguration wird für die HTTP-Verbindung zwischen dem Gateway und der ACI über das private Subnetz verwendet.
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;
}
}Laden Sie diese Datei in die zuvor erstellte Dateifreigabe nginxconf hoch.
Warnung: Starten Sie die ACI neu, damit Nginx mit der neuesten Änderung aktualisiert wird.
4.3. Den Backend Pool des Application Gateway einrichten
Nachdem die ACI erstellt wurde, navigieren Sie zu Application Gateway > Backend Pool > your backend pool > Edit backend pool.
Fügen Sie die private IP-Adresse Ihrer erstellten ACI hinzu.
4.4. Den Application Gateway Health Probe einrichten
Der Health Probe wird vom Application Gateway verwendet, um regelmäßig zu überprüfen, ob die API auf der ACI verfügbar ist. Richten Sie den Health Probe ein und klicken Sie anschließend auf Test. Wenn der Status Healthy lautet, ist die ACI korrekt konfiguriert und gestartet.
Fügen Sie über das Application Gateway einen Health Probe hinzu:
Klicken Sie auf Test > Add.
4.4.1. DNS einrichten
Wenden Sie sich an Ihre Administratoren oder an jede Person mit Zugriff auf die DNS-Zone, und bitten Sie diese, einen DNS-Namen hinzuzufügen, der auf die öffentliche IP-Adresse Ihres Application Gateway verweist.
4.4.2. WAF-Konfiguration
Die WAF wird verwendet, um bestimmte IP-Adressen, die versuchen, das Application Gateway aufzurufen, zuzulassen oder zu blockieren. Damit Salesforce-Prozesse funktionieren, muss die WAF die Salesforce-IP-Bereiche zulassen.
Klicken Sie in der WAF auf Switch to prevention mode. Dadurch kann die WAF die unten stehenden benutzerdefinierten Regeln verwenden.
Fügen Sie in den benutzerdefinierten Regeln hinzu:
- Salesforce-IP-Adressbereiche, einschließlich der Basic- und Hyperforce-Bereiche.
- DQE-Lizenzprüfserver: fragen Sie den Support.
- SF Automation 1: fragen Sie den Support.
- SF Automation 2: fragen Sie den Support.
Die vollständige Liste der Salesforce-IP-Adressen finden Sie hier.
Nachdem Sie diese Schritte abgeschlossen haben, überprüfen Sie Ihre Bereitstellung wie in 4.4. Den Application Gateway Health Probe einrichten beschrieben.
Verknüpfung mit