Praktische Salesforce Architektur

Kapitel 4. Daten und Architekturbeschränkungen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In diesem Kapitel werden wir uns näher mit der Unternehmenstauglichkeit der Salesforce-Architekturkomponenten befassen. Einige der Akteure in diesem Bereich sind Open-Source-Angebote, einige sind von Drittanbietern und einige gehören jetzt zu Salesforce. Die hier besprochenen Produkte und Unternehmen sollten als Beispiele für die Archetypen und nicht als Empfehlungen verstanden werden. In jeder dieser Produktbranchen gibt es viele gute Optionen. Wichtig ist, dass du dir darüber im Klaren bist, wann dich Skalierungsfaktoren dazu veranlassen könnten, zusätzliche Produkte außerhalb der Salesforce-Plattform zu wählen. Sieh dir noch einmal Abbildung 2-3 an, um dir die grundlegenden Definitionen der Ressourcentypen anzusehen, die in einem Cloud-Service-Angebot verkauft, bereitgestellt und genutzt werden. Die Verwaltung dieser Ressourcen wird deine Architektur stark beeinflussen. Abbildung 4-1 zeigt einige der Bereiche, in die Salesforce-Architekten expandieren. In diesem Kapitel werden wir einige der Gründe für solche Erweiterungen untersuchen.

Abbildung 4-1. Großflächige Datenmuster

Grenzen der Komplexität

Die Arbeit in Salesforce erfordert eine Begrenzung der Komplexität deiner Datenstrukturen. Komplexe Strukturen können sich in jedem System stark auf die Leistung auswirken. Salesforce hat viele Einschränkungen und Begrenzungen eingeführt, um ungesunde Muster zu verhindern. Wenn du zum Beispiel schon einmal daran gearbeitet hast, die Abfrageleistung zu optimieren, indem du vollständige Tabellenscans und Tabellensperren vermieden hast, werden dir die bewährten Methoden bekannt vorkommen. Du wirst nur neue Tools verwenden, um Joins, Sperren, Indizierungen und andere Abfrageoptimierungen zu verwalten. Mit diesen Einschränkungen bedeutet die Arbeit in Salesforce, dass du nicht immer den Luxus hast, mit lockeren Disziplinen zu beginnen und später leistungsfähigere Strategien zu implementieren.

Datenschieflage ist ein Problem, das durch die automatische Durchsetzung der referentiellen Integrität bestimmter Salesforce-Datenkonzepte entsteht. Ganz allgemein ausgedrückt: Wenn ein Datensatz eine Beziehung zu mehreren tausend anderen Datensätzen hat, können Änderungen an diesem Datensatz zu Sperren führen. Das ist eine Ein-Satz-Definition für ein sehr tiefgreifendes Datenbankmanagement-Konzept. Die Zahlen variieren, und die tatsächlichen Auswirkungen können je nach Anwendung klein oder groß sein. Der Punkt ist, dass eine falsche Einschätzung und Planung der Skalierung deiner Datenbeziehungen zu einer Menge Nacharbeit führen kann. Die Größenordnungen sollten dir bewusst sein, damit du sie bei der Planung berücksichtigen kannst.

Die Salesforce Object Query Language (SOQL), die Datenabfragesprache der Plattform, hat eine Menge zeitsparender Abkürzungen eingebaut. Wenn du dich erst einmal daran gewöhnt hast, ist das ziemlich praktisch. Wenn du dich bereits mit anderen SQL-Varianten auskennst, ist dies eine gute Möglichkeit, dein vorhandenes Wissen aufzufrischen. SOQL (oder genauer gesagt die Salesforce Datenzugriffs-APIs) hat allerdings ein paar Einschränkungen, die man kennen muss, um damit umzugehen. Du kannst zum Beispiel Abfragen erstellen, die sich auf Beziehungen bis zu fünf Ebenen tief beziehen, aber nicht weiter. Auch die eingebauten Berichtsfunktionen haben ihre Grenzen in Bezug auf die Komplexität der Daten .

Warnung

Es ist eine weit verbreitete, wenn auch unangenehme Praxis, Codelets zu schreiben, die Daten verflachen (denormalisieren), um Komplexitätsgrenzen zu umgehen. Kleine und mittlere Unternehmen haben in der Regel kein Problem mit der E/A-Belastung durch solche Hacks, aber eine größere Implementierung sollte die Speicherung größerer Hierarchien in geeigneteren Systemen einplanen.

Größenbegrenzungen

Die Speicherung ist eine weitere begehrte Ressource, die innerhalb des Salesforce-Ökosystems stark reglementiert wird. Es soll eine flexible Benutzeroberfläche und Datenverarbeitungsschicht sein, und eine umfangreiche Speicherung fordert einen Tribut an Ressourcen, die Salesforce lieber in Schach halten möchte. Anhänge oder Dateien sind in der Regel besser in einer besser abgestimmten Ebene aufgehoben. Auch der Umgang mit BLOB-Datentypen (binary large object), die bei der Verarbeitung viel Speicherplatz beanspruchen, kann für Salesforce eine Herausforderung darstellen.

Salesforce bietet einige Optionen für die Speicherung und den Zugriff auf Dateien, die relativ einfach zu implementieren sind. Amazon S3 ist eine gängige Wahl für die Speicherung von Dateien, die entweder groß sind oder langfristig verfügbar sein müssen. Andere gängige Kandidaten sind Google Drive, OneDrive und SharePoint. Viele von ihnen bieten nahtlose Plug-ins an, um deine Datenanforderungen und Prozesse mit deinen extern gespeicherten Dateien zu verbinden.

Begrenzungen berechnen

Eine Transaktion in Salesforce ist die kumulative Menge an Prozessen und CPU-Zeit, die mit einem bestimmten Benutzer oder automatisierten Startpunkt verbunden ist. Wenn ein Benutzer auf eine Schaltfläche klickt, die einen Workflow startet, der einen Datensatz erstellt, der einen Auslöser hat, der einen Webservice aufruft, und die Daten aus der Antwort dieses Webservices in ein anderes Objekt geschrieben werden, das einen anderen Auslöser hat, der noch andere Dinge tut, ist das alles eine einzige Transaktion. Hinter den Kulissen nimmt jedes dieser Ereignisse an einem Benachrichtigungs- und Timing-Framework teil, das dem Governor-System Bericht erstattet. Wenn eine Transaktion länger als ein bestimmter Schwellenwert läuft, kann der Governor sie stoppen und zum Fehlschlagen zwingen. Zu diesem Zeitpunkt können viele der abgeschlossenen Ereignisse aus den vorangegangenen Teilen der Transaktion rückgängig gemacht werden. Das Zeitlimit für eine synchrone Transaktion beträgt 10 Sekunden. Wenn du asynchrone Techniken hinzufügst, kann die Zeit bis zu 60 Sekunden betragen.

E/A-Grenzen

In diesem Zusammenhang verwende ich den Begriff Input/Output (I/O) für eingehende und ausgehende Anrufe zum und vom Salesforce-System. Im Allgemeinen werden ausgehende Anrufe von Salesforce nicht nach der Anzahl der Anrufe oder den zurückgegebenen Daten berechnet. Eingehende Anrufe, bei denen Daten in Salesforce gelesen oder gepusht werden, sind kostenpflichtig. Die auferlegten Grenzen hängen von deiner Lizenzierung ab. Wenn du für zusätzliche Funktionen oder mehr lizenzierte Benutzer bezahlst, kannst du dir mehr Spielraum verschaffen. Die Limits sind Soft Limits und liegen im Millionenbereich pro 24-Stunden-Zeitraum. Du wirst nicht bei deinem ersten eingehenden Anruf in Millionenhöhe abgeschaltet, aber dein Kundenbetreuer kann dich anrufen, um mit dir über eine Erhöhung deiner Ausgaben zu sprechen, wenn das regelmäßig vorkommt, und große Überschreitungen können zu einer hohen Rechnung führen. Das ist wahrscheinlich die geringste Grenze, über die du dir Sorgen machen musst, aber sie ist da.

Objekt-Polymorphismus (Wiederverwendung von Objekten)

Bewährte Methoden in Salesforce (aus Gründen der Einfachheit und des Leistungsmanagements im Backend) fördern die Polymorphie von Objekten. Das bedeutet, dass Datenbanktabellen (Objekte) wiederverwendet werden, wenn ihr Zweck ähnlich ist (d.h. wenn die Objekte eine Reihe von Feldern wie Name, E-Mail und Adresse gemeinsam haben). Du würdest z. B. nicht eine Datenbanktabelle für Einzelhandelskunden und eine weitere für Online-Kunden erstellen, sondern eine Tabelle verwenden und ein Markierungsfeld anlegen, das festhält, welche Art von Kunde jeder Datensatz darstellt. Der Mechanismus, der in Salesforce hierfür verwendet wird, heißt RecordTypes (siehe Kapitel 3). Die Einrichtung eines neuen RecordType als zusätzliche Verwendungsart einer Datenbanktabelle bringt eine Reihe von Funktionen mit sich, um diese Typen gegen andere Typen abzusichern. Es gibt auch Optionen für die Datenanzeige und andere damit verbundene Variationen, die bereitgestellt werden können, um diese neuen Typen zu ergänzen, sobald sie erstellt wurden.

RecordTypes und Polymorphism-Patterns bieten viele Möglichkeiten der Wiederverwendbarkeit, aber das hat den Preis von Abhängigkeiten. RecordTypes ermöglichen die Partitionierung einiger der mit einem Objekt verbundenen Datenmerkmale, aber nicht aller. Feldvalidierungsregeln werden auf der Objektebene erstellt. Sie können so eingestellt werden, dass sie nur Einträge auf der Grundlage eines bestimmten RecordTyps einschränken, aber sie werden trotzdem bei jeder Interaktion des Objekts ausgeführt. Das kann eine Herausforderung für die Verwaltung von Funktionen in verschiedenen Teams von Erstellern darstellen . Wir werden dies in Kapitel 12 näher erläutern.

Eingebaute erweiterte Datenbankfunktionalität

Datenbanktabellen, die erstellt werden oder standardmäßig vorhanden sind, haben bestimmte erweiterte Datenbankfunktionen, die automatisch für sie erstellt werden. Erfahrene DBAs oder Datenarchitekten sind mit den Konzepten von Primärschlüsseln, Indizes, zusammengesetzten Schlüsseln und global eindeutigen Bezeichnern (GUIDs) vertraut.

Jeder Datensatz in Salesforce ist mit einem eindeutigen Bezeichner versehen, der in einem ID-Feld gespeichert wird. Dieses Feld wird automatisch für jedes Objekt erstellt, das standardmäßig verfügbar ist oder das du erstellst, und es kann weder bearbeitet noch gelöscht werden. Das ID-Feld wird bei der Datensatzerstellung automatisch ausgefüllt. Die IDs sind jedoch nicht völlig zufällig wie Standard-GUIDs. Auch wenn sie zufällig aussieht, enthält die ID eines Datensatzes eine Menge Informationen. Die ID enthält verschlüsselte (aber nicht verschlüsselte) Verweise auf das Objekt, zu dem der Datensatz gehört, und auf den Org/Client, zu dem der Datensatz gehört, sowie ein Base64-kodiertes Zählerelement. Die ersten drei Zeichen sind ein Verweis auf das Objekt, zu dem der Datensatz gehört. Zum Beispiel hat jeder Datensatz im Account-Objekt eine ID, die mit 005 beginnt. Im Internet gibt es viele Blogbeiträge, die sich ausführlich mit diesem Thema befassen. Das Wichtigste ist, dass die IDs nicht zufällig sind und dass sie wichtige Informationen enthalten können, wenn du weißt, wie man sie liest.

Warnung

Es gibt zwei Varianten von IDs, die in Salesforce-Datensätzen verwendet oder referenziert werden können. Die erste ist die klassische 15-Zeichen-ID, die sowohl Groß- als auch Kleinbuchstaben enthalten kann und bei der Groß- und Kleinschreibung beachtet wird. Bei der neueren Version mit 18 Zeichen wird nicht zwischen Groß- und Kleinschreibung unterschieden, was durch die zusätzlichen Zeichen berücksichtigt wird.

Indizes sind in Salesforce viel wichtiger als in vielen anderen Systemen. In anderen Systemen tragen Indizes dazu bei, dass Abfragen schneller ausgeführt werden. In Salesforce kann das Fehlen eines Indexes darüber entscheiden, ob eine Abfrage überhaupt ausgeführt werden kann. Abfragen, die für große Tabellen ohne einen geeigneten Index geschrieben werden, geben eine von mehreren "zu viele Datensätze"-Meldungen zurück.

Alle Fremdschlüsselfelder (Lookup), einschließlich der Felder Creator und Owner, werden automatisch indiziert. Die Felder RecordTypeID und Systemzeitstempel sind ebenfalls standardmäßig indiziert. Es gibt zwei Möglichkeiten, Indizes für deine eigenen (benutzerdefinierten) Felder zu erstellen: Du kannst sie beim Kundensupport anfordern oder dem Feld das Attribut Externe ID hinzufügen. Da indizierte Felder die Fähigkeit bestimmen, Objekte mit sehr vielen Datensätzen abzufragen, kann die Verwaltung und richtige Planung von Indizes für den Betrieb deines Systems entscheidend sein.

Wenn ein Objekt erstellt wird, passieren im Hintergrund mehrere Dinge, die damit zusammenhängen, ob oder wie das Objekt für die Endnutzer/innen sichtbar wird. In vielen anderen Systemen ist es keine Selbstverständlichkeit, dass ein neues Objekt zu sehen ist. In Salesforce werden viele dieser Unterscheidungen zwischen Model, View und Controller gleichzeitig vorgenommen. Klassischere Systeme trennen die Datenstruktur vollständig von der Datenanzeige. Neue Seiten werden automatisch erstellt, die sowohl individuelle Seitenlayouts als auch Listenansichten für mehrere Datensätze enthalten. Anschließend ist es möglich, dem Objekt und diesen Seiten Berechtigungen zuzuweisen. Je nach deinen Sicherheitseinstellungen kann die Erstellung des Objekts den Nutzern automatisch Zugriff auf die neuen Seiten oder Ansichten gewähren, auch wenn es keine Datensätze gibt. Sei dir bewusst, dass es bei der Erstellung dieser zusätzlichen Objekte und Verweise zu einer Überschneidung der Daten kommen kann.

Geographie

Mit den Herausforderungen bei der Datenverarbeitung und E/A ist die Tatsache verbunden, dass Salesforce-Instanzen bis vor Kurzem in regionsspezifischen Rechenzentren gehostet wurden. Wenn du stark angepasste Erlebnisse bereitstellst (z. B. Grafiken, mehrseitige Arbeitsprozesse, responsive Erlebnisse), solltest du deine geografische Lage berücksichtigen. Wenn deine Nutzer/innen hohe Anforderungen an ihre Verbindung zu Salesforce stellen, müssen Content Delivery Networks (CDNs) bei deinen Entwürfen möglicherweise eine Rolle spielen. CDNs können die Belastung deiner Salesforce-Quelle verringern und Nutzern in weit entfernten Regionen zu einem besseren Erlebnis verhelfen.

Auch die Geografie kann bei der Planung der Geschäftskontinuität eine Rolle spielen. Mit der Einführung von Hyperforce, wie in Kapitel 2 erwähnt, hast du jetzt die Möglichkeit, deine Daten im Falle einer regionalen Katastrophe in der Cloud zu redundieren. Hyperforce wurde ursprünglich als Option vermarktet, mit der du deine Salesforce-Instanz auf einer der großen Cloud-Plattformen wie Googles GCP, Microsofts Azure oder Amazons AWS hosten lassen kannst. Das gefiel vielen Unternehmen, die mit diesen Firmen konkurrierten, denn es bedeutete, dass du dir aussuchen konntest, wo du dein Geld für das Hosting ausgeben wolltest. Leider wurde diese Wahlmöglichkeit nicht realisiert (oder zumindest noch nicht). Mit Hyperforce werden derzeit alle neuen Salesforce-Instanzen nicht mehr bei Salesforce, sondern bei AWS gehostet. Das bietet zwar nicht so viel Auswahl wie ursprünglich angekündigt, bringt aber dennoch einige großartige Optionen mit sich. Zum Beispiel kannst du jetzt bei der Konfiguration deiner Bereitstellung Verfügbarkeitszonen für die Fehlertoleranz auswählen - wenn dein Unternehmen diese zusätzliche Risikominderung benötigt, ist sie jetzt verfügbar.

Es besteht die Hoffnung, dass die Umstellung auf ein AWS-Containermodell zu mehr persönlicher Kontrolle über all die anderen in diesem Kapitel besprochenen Einschränkungen führen könnte. Das ist zum jetzigen Zeitpunkt noch Spekulation, aber es ist ein schöner Gedanke, dass diese Art der Anpassung und Verwaltung irgendwann möglich sein könnte.

Iterativer Entwurf

Agile Entwicklungspraktiken können zu Problemen bei der Anpassung von Salesforce führen. Alle Grenzen und Funktionsweisen, für die Salesforce entwickelt wurde, sowie Änderungen und Ergänzungen des Produkts sollten ständig überprüft werden. Salesforce ist eine Plattform mit vielen bestehenden Funktionsgerüsten, innerhalb derer du arbeiten solltest. Iteratives Design kann zu Problemen führen, wenn bei den neuen Iterationen die kumulative Komplexität und der Ressourcenverbrauch des endgültigen Designs nicht berücksichtigt werden. Ressourcenkonflikte und Engpässe sind eine ständige Herausforderung, und in einer gehosteten Plattformumgebung kannst du nicht einfach "mit Hardware um dich werfen". Die Beschäftigung von kampferprobten und #AlwaysLearning-Architekten ist die einzige Möglichkeit, nicht-triviale Anwendungen zu entwickeln, ohne auf nicht-triviale, selbstverschuldete Probleme zu stoßen. Es ist viel einfacher, frühzeitig und vorausschauend umzugestalten, als ein Redesign zu versuchen, wenn sich eine Katastrophe anbahnt. Angesichts der aktuellen Marktnachfrage nach Architekten, die eine erfolgreiche Vision aufrechterhalten und vorantreiben, ist es wichtig, viele Planungssitzungen und Dokumentationen einzubauen.

Stammdatenmanagement

Salesforce kann große Mengen an Transaktions- und Stammdaten verbrauchen und erzeugen. Salesforce kann auch stark isolierte Teams hervorbringen. Die Entwicklung einer Master Data Management (MDM)-Strategie für Daten, die in Salesforce verwendet werden oder sich dort befinden, ist äußerst wichtig. Diese Bedeutung ist nicht nur betrieblich oder akademisch, sondern hat auch steuerliche Auswirkungen. Ein unkontrolliertes Datenwachstum kann reale, greifbare Auswirkungen auf die Kosten haben. Es ist sehr wichtig, Data Champions einzustellen und zu schulen, wenn deine Salesforce-Implementierung eine große Anzahl von Datensätzen erzeugen wird. Das Verhältnis zwischen Speicherwert und Speicherkosten sollte bei jeder Anwendung ständig überprüft werden, aber die Verwaltung von Ressourcen in Salesforce kann sich viel direkter auf die Kosten auswirken als bei anderen Plattformen.

Melden

Die Berichterstattung kann beiläufig oder unternehmensweit erfolgen. Salesforce eignet sich sehr gut für gelegentliche Berichte, aber wenn du daran interessiert bist, aus großen Datenmengen tatsächliche Geschäftseinblicke zu gewinnen, solltest du ein BI-Tool verwenden. Die Planung, wie und wann du Salesforce-Daten für anspruchsvolle Berichte nutzen willst, sollte schon früh in der Entwurfsphase erfolgen. Salesforce verfügt über ein internes System zur Erstellung von Berichten (Reports), das sich hervorragend für grundlegende Berichte eignet und einige nützliche Funktionen zur Datenbereinigung und -überprüfung bietet. Es ist in der Lage, gut aussehende, gemeinsam nutzbare Berichte zu erstellen, vorausgesetzt, deine Anforderungen sind nicht zu komplex. Mit dem eingebauten Berichtssystem kannst du auch komplexere Berichte erstellen, allerdings müssen dafür einige komplexe Beziehungen hinzugefügt werden. Das liegt daran, dass die systemeigenen Berichte in erster Linie auf Echtzeitabfragen der tatsächlich genutzten Daten beruhen. Komplexere Abfragen sind nur mit Daten möglich, die getrennt von den internen Live-Daten gespeichert und verarbeitet werden. Cubes und andere Mechanismen zur Verflachung, Zwischenspeicherung und Vorverarbeitung von Abfragen sind in Tableau und anderen modernen BI- und Reporting-Tools möglich. Wende dich an diese externen Systeme, wenn du ernsthafte Anforderungen an die Datenverarbeitung hast .

Tableau ist eine der führenden BI-Plattformen weltweit und wurde kürzlich von Salesforce übernommen. Tableau ist extrem ausgereift und leistungsstark; es kann definitiv alle Berichtsanforderungen erfüllen. Tableau ist der häufigste Vorschlag des Salesforce-Vertriebsteams (und die Nutzung wird wahrscheinlich noch vorteilhafter, wenn es weiter in die Salesforce-Plattform integriert wird), aber Daten sind Daten und du solltest kein Problem damit haben, mit jeder anderen modernen BI-Plattform zu arbeiten.

Massenimport von Daten

Das wichtigste Tool von für das Massenladen von Daten aus Dateien (CSV) in Salesforce ist der Data Loader. Es handelt sich um ein clientbasiertes Java (OpenJDK)-Tool, das auf Windows oder Mac läuft und die Massen-APIs zum Parsen und Laden von Flat File-basierten Daten nutzen kann. Data Loader ist eine beliebte Wahl, auch weil es kostenlos ist. Die Web-APIs zum Laden von Daten sind jedoch standardisiert und können von allen Programmen genutzt werden, die HTTP verarbeiten können und moderne Web-Authentifizierungsstandards unterstützen.

Da es sich um eines der wenigen serverbasierten/lokalen Tools im Salesforce-Ökosystem handelt, solltest du dir darüber im Klaren sein, dass Sicherheits- und Virtualisierungsgrenzen seine Nutzung beeinflussen können. Die Upload-Geschwindigkeit kann von vielen Variablen beeinflusst werden, z. B.:

• Zielobjekt-Validierungen

• Komplexität der Zielobjektbeziehung

• Datenstruktur der Datei

• Geschwindigkeit des Netzwerks und des virtuellen privaten Netzwerks (VPN)

• Andere Tunnel und Entfernung zur Salesforce-Instanz

• Arbeitsspeicher, Speicherung und Prozessorgeschwindigkeit des Servers oder der virtuellen Desktop-Infrastruktur (VDI)

• Data Loss Prevention (DLP) und anderer Overhead bei der Paketkontrolle

Warnung

Es gibt zwei Produkte namens "Data Loader", die Teil von Salesforce sind: Data Loader und dataloader.io. Data Loader ist die herunterladbare Java-Anwendung, die Salesforce für das serverbasierte oder PC-basierte Laden von Stapeldaten unterstützt. Dies ist das skriptfähige Datenimport-Tool, das im gesamten Ökosystem weit verbreitet ist. dataloader.io ist Teil der MuleSoft-Produktlinie; es ist eine externe Weboberfläche, die das kostenlose Laden begrenzter Mengen von Dateidaten ermöglicht. dataloader.io ist nicht zu verwechseln mit dem Datei-Import-Assistenten, einer plattforminternen Weboberfläche, die in Salesforce enthalten ist und ebenfalls das kostenlose Laden kleiner Mengen von Dateidaten ermöglicht.

Die meisten großen Unternehmen sollten eine bevorzugte Version einer webbasierten Middleware oder einer ETL-Schicht als ihr primäres Datenzufuhrsystem einsetzen. Data Loader kann ein sehr nützliches Dienstprogramm für das Laden von Testdaten oder für erste Ladungen vor dem Livegang sein.

Ein weiteres Tool für den Datenzugriff, das häufig verwendet wird, ist Workbench. Workbench ist eine Reihe kostenloser webbasierter Tools, mit denen du dich mit deiner Salesforce-Instanz verbinden und deine Datensätze anzeigen und aktualisieren kannst. Die Verwendung von Workbench ist so weit verbreitet, dass die meisten Leute annehmen, dass es Teil der Plattform ist, aber eigentlich gehört es nicht zu Salesforce; es ist eine Website-Schnittstelle, mit der du dich mit einer Salesforce-Instanz verbinden kannst. Es wird nicht empfohlen, sie für den Zugriff auf Produktionsdaten zu verwenden. Mit der Workbench kannst du Daten aus einer CSV-Datei oder manuell abfragen oder in großen Mengen aktualisieren. Sie ist ein äußerst wertvolles Tool, um Daten aus einer Perspektive zu betrachten, die die Hauptschnittstelle nicht bietet.

Das Gute

Mit etwas Erfahrung kannst du so ziemlich jedes Standard-Datenmuster in Salesforce implementieren .

Die Gotchas

Die Arbeit mit Salesforce-Daten erfordert besondere Disziplin. Die Daten in Salesforce werden erst angezeigt, nachdem die Anfrage mehrere Ebenen von Logik und Berechtigungen durchlaufen hat. Es ist auch wichtig zu bedenken, dass du es bei Salesforce mit gemeinsam genutzten mandantenfähigen Ressourcen zu tun hast. Deine Daten befinden sich wahrscheinlich in der gleichen Datenbank und den gleichen Tabellen wie die vieler anderer Kunden. Die Legende besagt, dass die eigentliche Datenbank für jeden Salesforce Pod weniger als 20 Tabellen hat. Alle anderen Datenstrukturen werden durch Filterlogik verwaltet. Das Ergebnis ist ein maximaler Bandbreiten- oder Geschwindigkeitsverlust. Es gibt viele Kontrollsysteme, die deine Datenanfragen und E/A überwachen, um sicherzustellen, dass du bestimmte Grenzen nicht überschreitest, die sich negativ auf andere Nutzer/innen/Kund/innen auswirken würden. Stapelverarbeitung, Bulk Loading, Backups und andere Arbeitslasten, die eine hohe CPU-, E/A- oder Speichernutzung verursachen könnten, müssen speziell für die Arbeit in Salesforce strukturiert werden. Auch die Speicherung von Datensätzen und unstrukturierten Daten (Dateien) ist mit hohen Kosten verbunden.

Archivierungsstrategien sind keine Option für Anwendungsfälle, die ein schnelles Wachstum aufgrund von Übernahmen beinhalten. Das Ändern von Datenmodellen ist in Salesforce nicht einfach umkehrbar. Salesforce enthält auch keine spezielle Backup- und Recovery-Lösung. Es ist zwar intern fehlertolerant und verfügt über Redundanzen, aber viele dieser Redundanzen werden dir nichts nützen, wenn du deine eigenen Daten versehentlich beschädigst.

Der Aufbau einer groß angelegten Salesforce-Implementierung erfordert Investitionen in mehrere Cloud-Technologien und deren Verwaltung. Zum Glück ist es relativ einfach, diese zusätzlichen Systeme im Laufe der Zeit zu nutzen. Kosten- und Lizenzmanagement sind eine eigene Disziplin. Achte darauf, dass dein Wachstumsplan regelmäßige Überprüfungen der Größenordnung und der Kosten vorsieht.

Aufgrund der Einschränkungen bei den Beziehungstypen und Datenmustern ist es nicht immer möglich, bestehende Anwendungen in Salesforce zu übernehmen und zu verschieben. Nur sehr wenige Entwicklungsplattformen haben die gleichen Beschränkungen in Bezug auf optimale Beziehungen. Du musst das Quelldatenmodell genau auf seine Kompatibilität mit Salesforce prüfen. Sobald du ein Salesforce-kompatibles Datenmodell hast, kann es einfach sein, die Funktionalität neu zu erstellen, aber wenn sie nicht stark auf JavaScript basiert, wird es wahrscheinlich nicht schnell gehen. JavaScript lässt sich leichter portieren (d. h. Funktionen, die in einer Sprache oder Plattform entwickelt wurden, auf eine andere übertragen) als viele andere Frameworks.

Das Management der Datensicherheit mit all den verschiedenen Ebenen, die verteilte Daten mit sich bringen, muss ein Schwerpunkt sein. Dies ist ein weiterer Bereich, der als eigene Disziplin behandelt werden sollte, und du solltest diese Bemühungen auf die Sensibilität und den Wert der Daten abstimmen, die du besitzt.

Das Wachstum

Alles, was im vorherigen Abschnitt besprochen wurde, mag einschüchternd klingen, ist aber in Wirklichkeit nur ein Teil der modernen Cloud-Architektur. Am einfachsten lässt sich die Funktionsweise der verschiedenen Komponenten erklären, wenn wir darüber sprechen, an welchem Punkt des Skalierungsprozesses Herausforderungen auftreten. In den letzten Jahren hat Salesforce viele Übernahmen getätigt, die es ermöglichen, große Unternehmensfunktionen in und um Salesforce herum zu entwickeln. Viele der Probleme werden jetzt schon überbrückt.

Die Entwicklung des Plattform-Ereignisbusses, den wir uns im nächsten Kapitel ansehen werden, deutet auf den Wunsch hin, den Datentransfer innerhalb und außerhalb der Plattform in großem Umfang zu ermöglichen. Das Innenleben des neuen Busses ist eigentlich Kafka, verpackt in einigen geheimen Erweiterungen. Die Kafka-Optionen für High-Volume-Streaming sind derzeit Inside-Inside oder Inside-Outside, aber das wird sich wahrscheinlich ändern, wenn das Angebot ausgereift ist. Der Event-Bus der Plattform verspricht eine Hochgeschwindigkeitsdatenleitung für künftige Integrationen zu sein, die den Ressourcenverbrauch für den Datenbus-Transfer von der Hauptplattform entlastet.

Hinweis

Inside-inside bedeutet, dass die Komponenten der Salesforce-Plattform in der Lage sind, Ereignisse auf dem Event-Bus in großem Umfang zu veröffentlichen und zu abonnieren. "Inside-outside" bedeutet, dass externe Systeme den Event-Bus in großem Umfang abonnieren können, obwohl die Lizenzierung die maximale Anzahl der Nachrichten, die vom Bus empfangen werden können, vorschreibt. Es gibt auch Lizenzbeschränkungen für die Veröffentlichung von Nachrichten, die von außen an den Event Bus gesendet werden. Diese Grenzen sind für einige Anwendungsfälle hoch genug, aber je nach deinen Bedürfnissen ist es wahrscheinlich nicht kosteneffizient, den Event Bus anstelle eines dedizierten Nachrichtendienstes wie Kafka zu verwenden.

Salesforce hatte bereits ein respektables Reporting Framework, bevor es Tableau kaufte. Die Übernahme von Tableau sollte dir zeigen, dass das Unternehmen mehr als nur "respektabel" anstrebt. Die Übernahme von Tools wie Tableau und Slack zeigt, dass Salesforce viele Funktionen von "angemessen" zu "best-in-breed" entwickeln will. Salesforce konzentriert sich auch auf das Segment der erstklassigen Datenerfassung und investiert stark in Snowflake. Jeden Tag werden mehr und mehr nahtlose Integrationen mit Snowflake aufgedeckt. Snowflake selbst entwickelt sich zu viel mehr als nur einem operativen Datenspeicher, und zwar so sehr, dass es eine Herausforderung ist, es mit nur wenigen Schlüsselbegriffen zu beschreiben.

Auch durch die Partnerschaft von Salesforce mit AWS gibt es ständige Verbesserungen. Die Erweiterung von Salesforce-Anwendungen mit den Ressourcen von AWS wird weitere Früchte tragen. Hyperforce und Salesforce Functions sind ein gutes Beispiel für die zukünftigen Möglichkeiten, die der Plattform ständig hinzugefügt werden. KI ist ein weiterer Bereich, den Salesforce im Zuge des GPT-Hypes schnell für sich entdeckt hat; rechne damit, dass mehr dieser schnell wachsenden Modelle die Möglichkeiten für dein Unternehmen erweitern werden.

In den Salesforce-Angeboten fehlen vor allem Data Lake- und Data Warehouse-Lösungen. Da es hier keine Ökosystemkomponente gibt, die gebrandmarkt und angepriesen wird, solltest du einen Überblick darüber haben, ob sie benötigt werden. Salesforce-Praktiker lernen aus der Flut an neuen Funktionen und Umbenennungen. Wenn Konzepte es nicht in den Wasserschlauch schaffen, können sie übersehen werden.

Ein weiterer Punkt, den du berücksichtigen solltest, ist die Stratifizierung. Bist du derzeit an ein monolithisches Unternehmenslayout gebunden, das nicht mehr zu dir passt? Sind deine Ressourcen überdimensioniert und nicht ausgelastet? Vielleicht profitierst du von der Flexibilität kleinerer, lose gekoppelter Systeme, anstatt eine riesige, einheitliche Infrastruktur zu unterhalten. Diversifizierung ist ein mächtiges Werkzeug für die Geschäftskontinuität, und die Aufteilung deiner Infrastruktur, um die Vorteile des "Schwarmdenkens" zu nutzen, kann einen Mehrwert schaffen.

Zusammenfassung

Insgesamt haben die Zwänge der Leistungs- und Ressourcenverwaltung dazu geführt, dass die Salesforce-Funktionalität in einer Art goldenem Käfig gehalten wird - allerdings nur in Bezug auf einen echten Hosting- oder Cloud-Ersatz. Es gibt definitiv einige Überlegungen, die du bei der Implementierung von Datenarchitekturen in Salesforce beachten solltest. Fast alle kritischen Komponenten für jede Funktionalität sind fertig, fast fertig oder werden gerade angeschafft. Mit all den genannten Ergänzungen stellt sich nicht mehr die Frage , ob Salesforce dein einziger Anbieter von Cloud-Ressourcen sein könnte, sondern wann. Es ist nur eine Frage der Zeit, bis irgendwo im Setup ein Kontrollkästchen "Quantum Processing aktivieren" auftaucht. Beachte auch, dass die in Abbildung 4-1 aufgelisteten Labels zwar die Beispiele sind, über die am meisten gesprochen oder die am meisten vermarktet werden, dass es aber für jedes Element eine Menge würdiger Alternativen gibt und dass sich viele Firmen auf diese Alternativen spezialisiert haben. Kluge Architekten können an dieser Stelle alles umsetzen. Entscheidend ist nur, dass du das Budget und die Fähigkeiten hast, um Salesforce-Implementierungen zu planen, umzusetzen und zu verwalten. Die wichtigere Frage ist, ob du dich an einem Wendepunkt befindest, der mit der Reife der Salesforce-Angebote übereinstimmt, und ob es daher an der Zeit ist, ein Replatforming in Betracht zu ziehen.