Dokumentation

3.1.1. URL

Die URL-Autorisierung erfolgt durch Anhängen eines API-Schlüssels direkt als Parameter an die URL.

Es gibt folgende Felder:

3.1.2. Basic

Die Basic-Authentifizierung nutzt eine Kombination aus Benutzername und Passwort für den Zugriff auf die API.

Es gibt folgende Felder:

3.1.3. Token

Diese Methode verwendet einen Token, der im Header der API-Anfrage gesendet wird.

Token Type: Wähle hier den Datentyp des Tokens aus (String oder JWT).

Es gibt folgende Felder, wenn als Token Type String gewählt wird:

Es gibt folgende Felder, wenn als Token Type JWT gewählt wird:

3.1.4. OAuth 2.0

OAuth 2.0 ist ein komplexeres Verfahren, das sich für APIs mit erhöhtem Sicherheitsbedarf eignet und erweiterte Autorisierungsfunktionen bietet.

Es gibt folgende Felder, wenn als Grant Type “Authorization Code” gewählt wird:

Es gibt folgende Felder, wenn als Grant Type “Client Credentials” gewählt wird:

Es gibt folgende Felder, wenn als Grant Type “JWT” gewählt wird:

Es gibt folgende Felder, wenn als Grant Type “Password” gewählt wird:

Es gibt folgende Felder, wenn als Grant Type “Refresh Token” gewählt wird:

Auf Ebene des Providers kannst du weiterhin “IP Ranges” und “Error Configurations” konfigurieren. Die Konfiguration dieser Elemente ist jedoch optional.

3.1.5. IP Ranges

IP Ranges dienen als IP-Filter, um die Sicherheit bei der Integration von Drittsystemen in Salesforce über integraid zu erhöhen. Du kannst Start- und End-IP-Adressen angeben, um einen bestimmten Bereich von IP-Adressen zu definieren.

X

Versucht ein Server, außerhalb der definierten IP Ranges auf das System zuzugreifen, wird der Zugriff automatisch verweigert. Es können jedoch mehrere IP-Bereiche festgelegt werden, und der Zugriff wird gewährt, sofern die IP-Adresse in mindestens einem dieser Bereiche liegt. Wenn keine IP-Ranges definiert sind, bleibt der Zugriff für alle IP-Adressen standardmäßig erlaubt.

3.1.6. Fehler Konfiguration

Error Configurations dienen dem Error Handling und legen fest, welche HTTP-Response Codes als Fehler gewertet werden sollen.

X

In dem Feld “Response Code” können entweder spezifische Response-Codes definiert werden, oder allgemeine Code-Bereiche, wie alle Codes, die mit “4” beginnen. 400er-Response-Codes können so beispielsweise als Fehler oder auch als zulässige Antwort interpretiert werden, während 500er-Codes immer als Fehler behandelt werden.

Hinweis: Wenn die Fehlermeldung "Zugriff verweigert" oder etwas Ähnliches mit einem 500er-Fehler auftritt, kann dies an der URL liegen. Stelle sicher, dass "https://" oder "http://" in der URL enthalten ist. Eventuell muss auch das Protokoll (http:// oder https://) in den Provider aufgenommen werden bzw. in den Endpunkt, falls die Basis-URL des Providers leer ist.

Über das Feld “Identifier” kann außerdem der Identifier des Knotens in der Antwort definiert werden, der die Fehlermeldung enthält, z. B. „Message“ oder „Error“. Dieser Identifier wird verwendet, um Fehler in den Ergebnissen und für den User eindeutig zurückzuspielen.

Außerdem lässt sich über die Checkbox “Deactivate Mapping” festlegen, ob der in der Konfiguration definierter Fehler dazu führen soll, dass bei wiederholtem Auftreten das Mapping deaktiviert wird.

3.2.1. Typen von Endpunkten

Zuerst muss der Typ des Endpunkts festgelegt werden. Der Type bestimmt die Art und Weise, wie die Kommunikation zwischen Salesforce und Drittsystemen abläuft. Er definiert, ob eine Anfrage synchron oder asynchron erfolgt, und wie die Antwort behandelt wird. Hierbei wird zwischen 4 Types unterschieden:

• Callout: Der Callout ist ein synchroner Prozess, bei dem integraid eine Anfrage an ein Drittsystem sendet und sofort eine Antwort erhält. Die Transaktion gilt mit dem Empfang der Antwort als abgeschlossen.
• Async Callout: Der Async Callout ermöglicht eine asynchrone Kommunikation, bei der eine Anfrage gesendet und eine Callback-URL für die spätere Übermittlung der Antwort angegeben wird. Die Antwort erfolgt zu einem späteren, unbestimmten Zeitpunkt.
• Callin: Der Callin ermöglicht es einem Drittsystem, integraid bei bestimmten Ereignissen zu benachrichtigen, ähnlich einem Webhook. Die Benachrichtigungen können mehrfach und zu unterschiedlichen Zeitpunkten ohne vorherige Anfrage erfolgen. Zudem können HTML-Formulare Daten an Endpunkte dieses Typs senden.
• Forced Async Callout: Der Forced Async Callout führt einen gegenüber der Schnittstelle synchronen Callout Salesforce-seitig asynchron aus. Dies umgeht Salesforce-Limits und ermöglicht somit längere Callouts in Salesforce. Wir empfehlen die Verwendung dieses Typs ausschließlich beim Auftreten von Salesforce-Fehlern auf Grund erreichter Salesforce-Limits.

3.2.2. HTTP Methoden

HTTP Methoden werden verwendet, um Anfragen an einen Server zu stellen. Jede Methode hat eine spezifische Funktion, die beschreibt, welche Art von Operation auf einer Ressource durchgeführt werden soll. Hier eine Übersicht:

• Die GET-Methode wird genutzt, um Daten der Schnittstelle abzufragen, ohne diese zu verändern. Diese Methode liefert bei wiederholten Anfragen stets dieselben Ergebnisse, solange die Daten auf Seiten der Schnittstelle unverändert bleiben.
• Die POST-Methode dient dazu, neue Datensätze in Salesforce zu erstellen oder Aktionen wie Trigger auszuführen. Wiederholte Anfragen können zu mehrfacher Erstellung von Datensätzen oder mehrfacher Ausführung von Prozessen führen.
• Die PUT-Methode wird verwendet, um Datensätze in Salesforce zu erstellen oder vollständig zu aktualisieren. Bei jeder Anfrage wird der Datensatz in Salesforce durch die übermittelten Daten ersetzt, sodass das Ergebnis konsistent bleibt.
• Die PATCH-Methode wird eingesetzt, um vorhandene Datensätze in Salesforce gezielt zu aktualisieren. Nur die angegebenen Felder werden geändert, was diese Methode besonders effizient für inkrementelle Updates macht.
• Die DELETE-Methode ermöglicht das Löschen von Datensätzen in Salesforce. Ein erneutes Senden der Anfrage hat keine zusätzlichen Auswirkungen, da der Datensatz nach der ersten Anfrage bereits entfernt ist.

Welche HTTP-Methode für deinen Anwendungsfall benötigt wird, siehst du in der Schnittstellendokumentation des Providers.

Anschließend musst du den Endpunkt per Klick auf den “Configure”-Button konfigurieren. Hierbei konfigurierst du die Struktur ausgehender und eingehender Daten (outbound, inbound).

3.2.3. Outbound

Zuerst legst du fest, wo die Information enthalten ist, welche du aus deinem Salesforce System an die Schnittstelle übermitteln willst. Hierbei hast du die Optionen “Body”, “Header” und “URL”. Das sind die Orte, an denen die Daten übermittelt werden können.

X

Body

Wenn du „Body“ als Attribut auswählst, werden die zu sendenden Daten im Nachrichtenkörper der HTTP-Anfrage übertragen.

• Content Type: Du kannst das Format der Nachricht bestimmen, z. B. application/json, application/xml oder andere Formate, je nach Anforderung der Schnittstelle.
• Quantity: Hier wird festgelegt, ob ein einzelnes Datenelement (Single) oder mehrere Elemente (Array) übertragen werden sollen.
• Type: Es wird zwischen Node und Value unterschieden:
  • Node: eine Struktur mit Unterelementen.
  • Value: ein einzelner Wert.

Unterhalb des Bodys kannst du einzelne Felder oder verschachtelte Strukturen anlegen, die aus Salesforce-Daten befüllt werden.
Über die Funktion „Import“ kannst du außerdem eine Beispielstruktur (z. B. JSON) hochladen, wodurch die Felder automatisch erstellt werden.

Typische Anwendungsfälle für Body sind:

• Senden von Datensätzen an REST-APIs (z. B. POST neuer Leads oder Opportunities).
• Übertragen von komplexen JSON-Objekten.

Header

Wenn du „Header“ auswählst, werden die Salesforce-Daten in die HTTP-Header der Anfrage eingefügt.

• Quantity: Auch hier definierst du, ob Einzelwerte oder Arrays gesendet werden.
• Type: Auch Header können in einfache Schlüssel-Wert-Paare (Value) oder in strukturierte Nodes unterteilt werden.

Header werden genutzt, um:

• Authentifizierungsinformationen zu senden (z. B. API-Keys, Bearer Tokens).
• Spezielle Steuerinformationen an die API zu übermitteln (z. B. Content-Type Header).

Wie bei Body kannst du auch hier Child-Elemente (Felder) hinzufügen, um dynamische Headerfelder aufzubauen.

URL

Bei Auswahl von „URL“ werden Daten als Parameter an die URL der API angehängt (Query-Parameter).

• Quantity: Einzelwerte (Single) oder Listen (Array) sind möglich.
• Type: Definiert, ob der Parameter als Node oder Value behandelt wird.

Bei URL-Parametern kannst du:

• Statische Werte definieren.
• Felder aus Salesforce dynamisch in die URL übernehmen (z. B. Domain, ID, Status).
• Arrays als kommaseparierte Parameter aufbauen.

Die URL-Parameter werden automatisch korrekt formatiert (?key1=value1&key2=value2) und an die Endpunkt-URL angehängt.

Typische Anwendungsfälle für URL-Parameter sind:

• GET-Requests mit Filter- oder Suchkriterien.
• Identifizierung einer Ressource über die URL.

3.2.4. Inbound

Als nächstes legst du fest, welche Information du von der Schnittstelle erhalten wirst. Die Inbound-Konfiguration befasst sich damit, in welcher Struktur das System Daten von einer Schnittstelle empfängt. Hierbei hast du ebenfalls die Optionen “Body”, “Header” und “URL”.

X

Body

Wenn du „Body“ auswählst, verarbeitet integraid die Inhalte aus dem Nachrichtenkörper der API-Antwort.

• Content Type: Du gibst das erwartete Format an, z. B. application/json, application/xml, etc. Dadurch weiß integraid, wie die Antwortstruktur gelesen werden soll.
• Type: Es wird festgelegt, ob die Daten als Node (komplexe Struktur) oder Value (einzelner Wert) interpretiert werden.

Im Body kannst du beliebig viele Attribute (Datenfelder) anlegen:

• Jedes Attribut erhält einen Identifier (Name aus der API).
• Du legst den Datentyp fest, z. B. String, Number, Boolean oder Date.
• Du kannst die Struktur selbst definieren oder automatisch über die Importfunktion aus einer Beispielantwort erzeugen.

Typische Nutzung:

• Übernahme komplexer JSON- oder XML-Responses mit verschachtelten Elementen.
• Extrahieren mehrerer Datenfelder (z. B. Firmenname, Umsatz, Standort).

Header

Bei Auswahl von „Header“ liest integraid die Informationen direkt aus den HTTP-Headern der Antwort.

• Type: Auch hier kannst du Node oder Value verwenden, je nachdem, ob einfache oder strukturierte Daten verarbeitet werden.

In der Konfiguration gibst du an:

• Welche Header-Felder ausgewertet werden sollen.
• Welche Typen die Header-Daten haben (z. B. String, Boolean).

Typische Nutzung:

• Verarbeitung von Authentifizierungsdaten oder Systeminformationen, die im Header transportiert werden.
• Auslesen von Statusinformationen (z. B. Tokens, Session-IDs).

URL

Wenn „URL“ gewählt wird, verarbeitet integraid Parameter oder Informationen, die in der URL der Antwort enthalten sind.

• Type: Auch URL-Parameter können als einfache Werte (Value) oder komplexe Strukturen (Node) aufgebaut sein.

Hier definierst du:

• Welche URL-Parameter ausgewertet werden sollen (z. B. ID, Status).
• Wie die Daten ausgelesen und weiterverarbeitet werden.

Typische Nutzung:

• APIs, die Zustände oder IDs über die URL zurückgeben.
• Abruf von Ergebnissen über Redirects oder Query-Strings.

Button “Add Body”

Der Button “Add Body” ermöglicht es, alternative Antwort-Bodies zu definieren. Dies ist besonders wichtig, wenn Schnittstellen im Erfolgsfall und im Fehlerfall unterschiedliche Content Types zurückliefern. So kann es beispielsweise sein, dass im Erfolgsfall eine Datei als Binärdaten (Octet-Stream) zurückgegeben wird, während im Fehlerfall JSON-Daten geliefert werden. 

X

Durch Klicken auf "Add Body" kann man einen der verbleibenden Content Types auswählen und eine individuelle Antwortstruktur definieren. integraid verwendet den von der Schnittstelle mitgelieferten Content Type, um die richtige Richtung für die Antwortverarbeitung einzuschlagen.

3.3.1. Scopes

Die Grundlage des Mappings bildet der Datenkontext, der durch sogenannte “Scopes” definiert wird. Scopes sind die Datenquellen oder "Datenwahrheiten", die für das Mapping verwendet werden. Sie können verschiedene Ebenen haben, wie z.B. Field Scopes, List Scopes und Free Scopes und erlauben den Zugriff auf die gesamte Datenstruktur in Salesforce.

Zuerst wird eine Primary Scope angelegt. Dies geschieht über den Button “Add Scope” oben rechts im Mapping-Datensatz. Sie definiert, unter welchem Objekt die für den Endpunkt relevante Information liegt.

X

Hier wählst du dein gewünschtes Objekt aus. Wenn du z.B. Daten aus einem Account-Objekt für einen Callout benötigst, wählst du den Account als Primary Scope aus. Wir haben beispielsweise die Primary Scope als Lead definiert. Die Primary Scope wird im “Scope”- Datensatz sichtbar. Von der Primary Scope aus können nun weitere Scopes definiert werden. Dafür klickst du in den Scope Datensatz.

X

Zusätzlich zu der Primary Scope kannst du hier per Klick auf den Button “Create Child Scope” innerhalb der Primary Scope sogenannte Field Scopes und List Scopes erstellen. Diese sind sogenannte “Children” der Primary Scope, d.h. dass sie sich auf Daten innerhalb des Objektes der Primary Scope beziehen. Per Klick auf den Button “New” im Scope Datensatz kannst du außerdem eine Free Scope erstellen.

X

• Field Scopes beziehen sich auf Lookup Felder des Objektes und die Daten der Objekte, auf die das Lookup zeigt (Bsp. Ein Account).
• List Scopes beziehen sich auf Daten aus den Listen des Objekts (Bsp. Alle Kontakte unterhalb des im Field Scope definierten Accounts).
• Free Scopes beziehen sich auf alle Datensätze in Salesforce und müssen keine Verbindung zu einer Field- oder List Scope haben (Bsp. Alle Produkte in Salesforce).

Das Prinzip der Scopes kann am Anfang verwirrend sein, weshalb wir es später noch einmal anhand eines Beispiels erklären.

3.3.2. Target Objects

Eingehend können zusätzlich zu den Scopes Target Objects angelegt werden. Diese sind speziell für Inbound-Mappings konzipiert und dienen dazu, spezifische Aktionen auf Salesforce-Objekten durchzuführen. Um ein neues Target Object zu erstellen, klicke auf den Button “New” neben “Target Objects”.

X

Eine Oberfläche zur Erstellung eines „Target Object“-Datensatzes öffnet sich. Gebe dem Target Object einen Namen, trage den Objektnamen ein und wähle eine Aktion.

X

Folgende Aktionen stehen zur Auswahl:

• Insert: Hierbei werden neue Datensätze erstellt.
• Read: Die Daten werden lediglich gelesen, es werden aber keine Änderungen an Datensätzen vorgenommen.
• Update: Hierbei werden bestehende Datensätze aktualisiert.
• Upsert: Hierbei werden neue Datensätze eingefügt oder bestehende aktualisiert, falls ein passender Datensatz bereits existiert.

3.3.3. Outbound Mapping

Nachdem du deine Scopes erstellt hast, geht es an die Konfiguration des Mappings. Über das Outbound Mapping legst du fest, wo die Informationen hergenommen werden, die an die Schnittstelle geschickt werden. Die Konfiguration startest du über den “Configure” Button innerhalb des Mapping-Datensatzes.

X

Als Richtung wählst du hierbei “Outbound” aus.

X

Es wurde bereits der Datenort ausgewählt, der im Endpunkt für Outbound festgelegt wurde.

X

Nun wählst du deine Scope aus, welche die relevante Information beinhaltet. Per klick auf den Button “Add” fügst du das Attribut hinzu. Bei “Source” kannst du nun auf alle relevanten Felder zugreifen, die die ausgehende Information beinhalten.

X

Für das Handling von Arrays gibt es zusätzlich die Checkbox “Map Multiple Values”, wobei die Werte durch ein im Feld “Seperator” angegebenes Zeichen getrennt werden.

Du hast jedoch ebenfalls die Option, das Attribut statisch zu befüllen, indem du das Feld “Scope” weglässt. Bei “Source” kannst du dann deinen Wert eingeben.

X

Per Klick auf den Button “Pick Variable” hast du außerdem die Möglichkeit, auf bestimmte Variablen zuzugreifen, die häufig dynamisch verwendet werden. 

X

Sie können genutzt werden, um dynamische Werte zu generieren, die später in dem Feld daneben auch angepasst werden können (z.B. Timestamp minus eine Woche). Es ist möglich, eine Abweichung in Minuten einzutragen, um dynamische Datums- und Zeitwerte zu definieren.

3.3.4. Inbound Mapping

Über das Inbound Mapping legst du fest, wo die von der Schnittstelle erhaltenen Daten in deiner Salesforce Architektur gespeichert werden sollen. Die Konfiguration startest du ebenfalls über den “Configure” Button innerhalb des Mapping-Datensatzes, wählst als Richtung diesmal jedoch “Inbound” aus.

X

Hier wählst du nun bei “Target” dein Zielobjekt aus, auf welches die von der Schnittstelle erhaltenen Werte übertragen werden sollen. Bei “Attribute” hast du Zugriff auf alle Attribute, die im Endpunkt festgelegt wurden.

X

Per Klick auf den Button “Add” kannst du die Konfiguration hinzufügen und im nächsten Schritt bei “Field” das Feld auswählen, auf welchem das jeweilige Attribut abgebildet werden soll.

X

Auch hier ermöglicht die Checkbox "Map multiple values" die Verarbeitung von Arrays oder kommaseparierten Werten. Wenn ein Attribut mehrere Werte enthält, kann also mit der Checkbox gesteuert werden, wie diese Werte in Salesforce geschrieben werden (z.B. alle Werte kommasepariert in ein Textfeld oder in eine Mehrfachauswahlliste).

Wird kein Attribut angegeben, hast du auch hier die Möglichkeit, statische Werte anzugeben oder auf die Variablen “Response Code” und “Timestamp” zuzugreifen.

X

Im Abschnitt “Configure Children” kannst du Datensätze in Bezug auf ein Parent Object erstellen. Als “Target” legst du hier dein vorher angelegtes Target Object fest und klickst auf “Add”.

X

Nun kannst du auf “Configure” klicken und gehst in der Konfiguration eine Ebene tiefer. Hier funktioniert die Konfiguration genau wie auf Ebene des Parent Objects. Möchtest du dein Child Object mit einem in der Hierarchie höher gelegenen verlinken, kannst du das Attribut frei lassen. Das übergeordnete Objekt taucht dann in den dynamischen Variablen auf:

X

So ist es möglich, auf Objekte zuzugreifen, die mehrere Ebenen über deiner Position liegen. Die Nummerierung bezieht sich dabei auf deine aktuelle Position (#1=eine Position über dir).

Mit dem Button “Back to Parent Object” kommst du wieder auf die höhere Ebene.

X

Hinweis: Du kannst sowohl Merge-Felder* als auch Merge-Attribute* verwenden, um Daten aus dem Parent Object oder der Antwort der Schnittstelle zu referenzieren und in die Felder des Child Objekts zu schreiben. Das System validiert automatisch, ob die Merge-Felder korrekt eingegeben wurden.

3.3.5. Field Updates

Field Updates sind in integraid eine Funktion, die es ermöglicht, Felder in Salesforce zu aktualisieren, nachdem ein Callout oder ein Callin stattgefunden hat. Im Gegensatz zu Data Configurations, die abhängig von der Antwort der Schnittstelle aktualisiert werden, werden Field Updates immer ausgeführt, unabhängig davon, ob die Schnittstelle erfolgreich war, einen Fehler zurückgegeben hat oder gar keine Antwort gegeben hat. Ein neues Field Update kannst du erstellen, indem du auf den Button “New” neben Field Updates innerhalb deines Mapping-Datensatzes klickst.

X

Eine Oberfläche zur Erstellung eines „Field-Update“-Datensatzes öffnet sich.

X

Hier kannst du dem Record einen Namen geben, die Scope festlegen und bei “Field Name” den Namen des Feldes angeben, welches aktualisiert werden soll. Bei “Operator” kannst du den Vergleichsoperator angeben, der abgeglichen werden soll, bei “Condition Value” den aktuellen Wert des Zielfelds und bei “New Value” den Zielwert für das aktualisierte Feld. Der Wert in “New Value” wird hier also nur geschrieben, wenn die in “Operator” angegebene Bedingung zutrifft (z.B. ein Feld nur dann beschreiben, wenn es davor leer ist). Zudem wählst du bei “Event” die Ereignisse aus, welche das Field Update auslösen sollen.

Wenn das Mapping fertig Konfiguriert ist, kannst du es per Klick auf den Button “Validate” validieren und per Klick auf den Button “Activate” aktivieren. Um es zu testen, kannst du auf den Button “Test” klicken.

X

Hier kannst du einen Record innerhalb deiner Scopes auswählen und auf “Create” klicken, um einen Job zu erstellen.

X

3.3.6. Jobs

Jobs sind in integraid eine zentrale Komponente, die jeden Callout und jeden Callin handhabt. Sie dienen als eine Art Protokoll oder Aufzeichnung für jede Interaktion mit einer Schnittstelle und ermöglichen die asynchrone Verarbeitung von Daten. Alle deine Jobs findest du im gleichnamigen Reiter auf der integraid Oberfläche.

X

• Wenn ein Test-Job aus einem Mapping heraus erstellt wird, wird der Callout ausgeführt, aber es werden keine Daten in die Datenbank geschrieben. Dies verhindert, dass Live-Daten durch Testläufe beeinflusst werden.
• Wenn ein Fehler bei der Datenanwendung auftritt, kann der zugrunde liegende Fehler behoben und die Datenanwendung über den Button "Retry" im Job wiederholt werden.
• Der Button "Apply" dient dazu, die Anwendung eines Jobs manuell anzustoßen. Das bedeutet, dass die Ergebnisse eines Callouts in die Datenbank geschrieben werden. Es gibt anschließend eine "Evaluate" Option, mit der man sich die Auswirkung der Anwendung anzeigen lassen kann, bevor die Anwendung ausgeführt wird.

X

Jeder Job hat außerdem einen Status, der anzeigt, ob der Job noch offen ist oder erfolgreich abgeschlossen wurde. Bei einem Fehler bleibt der Job offen, was es dir ermöglicht, auf die offenen Jobs zu reagieren und diese gegebenenfalls neu auszuführen.

3.4.1. Vorbereitung in Salesforce

• Felder anlegen: Im Standard Leadobjekt von Salesforce legen wir zuerst fünf Felder an, um die von Abstract API zurückgelieferten Daten zu speichern. Diese Felder sind:
  • Location (Ort)
  • Founded (Gründungsjahr)
  • Employees (Anzahl der Mitarbeiter)
  • Revenue (Jahresumsatz)
  • Technologies (Liste der eingesetzten Technologien)
• Formelfeld anlegen: Wir legen zudem ein Formelfeld an, das aus dem Webseitenfeld die Domain extrahiert. Abstract API benötigt die Domain als Erkennungsmerkmal für die Firma.

X

3.4.2. Konfiguration in integraid

• Provider anlegen:
  • Als erstes legen wir einen neuen Provider Datensatz in integraid an, der den Schnittstellenanbieter definiert. In diesem Fall nennen wir ihn "Abstract API". Die Base URL lassen wir leer.

X

• Autorisierung konfigurieren: Als zweiten Schritt konfigurieren wir die Autorisierung. Den Typ der Autorisierung setzen wir auf "URL" und den API-Schlüssel von Abstract API übergeben wir als URL-Parameter mit dem Namen "api_key".

X

• Endpunkt definieren: Der dritte Schritt ist die Konfiguration des Endpunkts. Dieser beinhaltet die Art der Daten, die die Schnittstelle erwartet, und die Struktur der zurückgegebenen Daten. Wir legen einen Endpunkt mit folgenden Informationen an:
  • Name: Company Enrichment
  • Provider: Abstract API
  • Type: Callout
  • Method: GET
  • URL: https://companyenrichment.abstractapi.com/v2

Die HTTP-Methode (GET) und die URL der Abstract API haben wir aus der Schnittstellendokumentation kopiert.

X

Outbound konfigurieren: In der Schnittstellendoku können wir sehen, dass die Schnittstelle einen URL-Parameter namens "Domain" erwartet.

X

Wir klicken also auf den “Configure”-Button innerhalb des Endpunkts, wählen “Outbound” und anschließend “URL”. In den Identifier tragen wir “domain” ein und wählen “Value” als Type.

X

Inbound konfigurieren: Hier wird die Struktur der Antwort von Abstract API definiert. In der Schnittstellendokumentation sehen wir eine Beispielantwort im JSON-Format, welche wir kopieren und in integraid importieren können.

X

Wir klicken erneut auf den “Configure”-Button innerhalb des Endpunkts, wählen “Inbound” und anschließend “Body”. Den Content Type setzen wir auf "Application JSON" und bei Type wählen wir “Node”. Nun klicken wir auf “Import” und kopieren anschließend unsere Beispielantwort in das Feld “Input”. Per Klick auf den Button “Import” wird nun die Attribut-Struktur automatisch angelegt.

X

Als letztes klicken wir auf den Button “Save”, die Attribute werden gespeichert und der Endpunkt ist fertig konfiguriert.

• Mapping konfigurieren: Der vierte Schritt ist die Konfiguration des Mappings. Wir legen ein neues Mapping an, das die Verbindung zwischen der Struktur im Endpunkt und den Salesforce-Daten herstellt. Wir benennen das Mapping und verknüpfen es mit dem Endpunkt “Company Enrichment”.

X

Als erstes definieren wir nun die Scope, indem wir auf “Add Scope” klicken. Hierbei wählen wir Lead als unsere Primary Scope.

X

Outbound konfigurieren: Das Attribut "Domain" wird hierbei dem Formelfeld zugeordnet, das die Domain aus dem Webseitenfeld extrahiert. Dafür klicken wir auf “Add” und wählen bei Source anschließend das vorher angelegte Formelfeld “Domain__c”.

X

Inbound konfigurieren: Hier werden die Felder im Leadobjekt den Attributen der Abstract API-Antwort zugeordnet. Wir befüllen unsere zuvor angelegten Felder:

• "Annual Revenue" wird dem Feld "Revenue" zugeordnet.
• "Country" wird dem Feld "Location" zugeordnet.
• "Employee Count" wird dem Feld "Employees" zugeordnet.
• "Founded" wird dem Feld "Founded" zugeordnet.
• "Technologies" wird dem Feld "Technologies" zugeordnet. Dabei wird konfiguriert, dass die Werte des Arrays als kommaseparierte Liste in das Textfeld geschrieben werden, indem wir “Map Multiple Values” anhaken und bei “Seperator” ein Komma eintragen.

X

Als letztes Aktivieren wir noch das Mapping, indem wir auf den Button “Activate” klicken und schließen damit die Konfiguration in integraid ab.

X

3.4.3. Konfiguration in Salesforce Flow

Als erstes erstellen wir einen neuen Record-Triggered Flow in unserem Salesforce System. Der Flow soll dann ausgelöst werden, wenn das Webseitenfeld im Leadobjekt erstmalig befüllt wird.

X

Anschließend fügen wir einen asynchronen Pfad hinzu, da nach einer Datenänderung (Update/Insert) in Salesforce kein direkter Callout erlaubt ist.

X

Nun müssen wir eine Variable erstellen, indem wir die Toolbox* oben links im Flow Builder öffnen und auf “New Resource” klicken. Hier erstellen wir folgende Variable:

• Resource Type: Variable
• API Name: Ids
• Data Type: Text
• Allow multiple values: checked

X

Als nächstes fügen wir ein Assignment- Element hinzu, in dem die Ressource namens "IDs" mit der ID des Leads befüllt wird, der die Logik auslöst.

X

Jetzt fügen wir einen integraid Callout hinzu. Die zuvor erstellte Mapping-ID wird als Parameter übergeben, und die "IDs"-Variable wird als Parent-ID übergeben.

X

Abschließend speichern und aktivieren wir den Flow und schließen somit die Konfiguration ab.

3.4.4. Ergebnis

Wir tragen eine Website in das Feld “Website” auf Lead-Ebene ein und laden die Seite neu. Wir sehen, dass alle Felder korrekt befüllt wurden.

X

Ablauf im Detail:

1. Webseite eingeben: Ein Benutzer gibt eine Webseite in das Webseitenfeld eines Leads in Salesforce ein und speichert den Datensatz.

2. Flow wird ausgelöst: Der konfigurierte Flow wird durch die Speicherung des Leads ausgelöst.

3. Callout an Abstract API: Der Flow führt einen Callout über integraid an Abstract API aus.

4. Daten werden abgerufen: Abstract API liefert Daten zur eingegebenen Webseite zurück.

5. Felder werden befüllt: Die zurückgelieferten Daten werden in die entsprechenden Felder des Leadobjekts in Salesforce geschrieben.

6. Lead wird neu geladen: Wenn der Lead neu geladen wird, sind die Felder mit den von Abstract API abgerufenen Daten befüllt.

Diese Schritte ermöglichen es, die Informationen von Abstract API direkt in Salesforce zu integrieren und den Lead-Datensatz anzureichern.