Architekturansätze für Mandantenintegration und Datenzugriff

Es ist üblich, dass Systeme gemeinsam integriert werden, auch über Organisationsgrenzen hinweg. Wenn Sie eine multitenante Lösung erstellen, müssen Sie möglicherweise Daten an die Systeme Ihrer Mandanten senden oder Daten aus diesen Systemen empfangen. In diesem Artikel erläutern wir die wichtigsten Überlegungen und Ansätze für die Architektur und Entwicklung von Integrationen für eine multitenante Lösung.

Wesentliche Aspekte und Anforderungen

Richtung des Datenflusses

Es ist wichtig, die Richtung zu verstehen, in der Ihre Daten fließen. Die Datenflussrichtung wirkt sich auf mehrere Aspekte Ihrer Architektur aus, z. B. die Verwaltung von Identität und Netzwerktopologie Ihrer Lösung. Es gibt zwei allgemeine Datenflüsse:

• Exportieren, was bedeutet, dass die Daten von Ihrem multitenanten System zu ihren einzelnen Mandantensystemen fließen.
• Importieren, was bedeutet, dass Daten aus den Systemen Ihrer Mandanten in Ihr multi-tenantes System stammen.

Es ist auch wichtig, die Netzwerkdatenflussrichtung zu berücksichtigen, die nicht unbedingt der logischen Datenflussrichtung entspricht. Sie können beispielsweise eine ausgehende Verbindung mit einem Mandanten initiieren, damit Sie die Daten aus dem Mandantensystem importieren können.

Voll- oder Benutzerdelegierter Zugriff

In vielen Systemen ist der Zugriff auf bestimmte Daten auf bestimmte Benutzer beschränkt. Die Daten, auf die ein Benutzer zugreifen kann, sind möglicherweise nicht identisch mit den Daten, auf die ein anderer Benutzer zugreifen kann. Es ist wichtig, zu berücksichtigen, ob Sie mit vollständigen Datensätzen arbeiten möchten, oder wenn die von Ihnen importierten oder exportierten Datensätze auf der Grundlage der Berechtigung eines bestimmten Benutzers basieren, auf die sie zugreifen können.

Betrachten Sie z. B. Microsoft Power BI, der ein multitenanter Dienst ist, der Berichts- und Business Intelligence über kundeneigene Datenspeicher verfügt. Wenn Sie Power BI konfigurieren, konfigurieren Sie Datenquellen zum Abrufen von Daten aus Datenbanken, APIs und anderen Datenspeichern. Sie können Datenspeicher auf zwei verschiedene Arten konfigurieren:

• Importieren Sie alle Daten aus dem zugrunde liegenden Datenspeicher. Dieser Ansatz erfordert, dass Power BI mit Anmeldeinformationen für eine Identität bereitgestellt wird, die auf den vollständigen Datenspeicher zugreifen kann. Anschließend können Power BI-Administratoren Berechtigungen für die importierten Daten separat konfigurieren, nachdem sie in Power BI importiert wurde. Power BI erzwingt die Berechtigungen.
• Importieren Sie eine Teilmenge von Daten aus dem zugrunde liegenden Datenspeicher basierend auf den Berechtigungen eines Benutzers. Wenn ein Benutzer die Datenquelle erstellt, verwenden sie ihre Anmeldeinformationen und die zugehörigen Berechtigungen. Die genaue Teilmenge der Daten, die Power BI importiert, hängt von der Zugriffsstufe des Benutzers ab, der die Datenquelle erstellt hat.

Beide Ansätze verfügen über gültige Anwendungsfälle, daher ist es wichtig, die Anforderungen Ihrer Mandanten klar zu verstehen.

Wenn Sie mit vollständigen Datensätzen arbeiten, behandelt das Quellsystem das Zielsystem effektiv als vertrauenswürdiges Subsystem. Für diese Art der Integration sollten Sie auch die Verwendung einer Workloadidentität anstelle einer Benutzeridentität berücksichtigen. Eine Workloadidentität ist eine Systemidentität, die nicht einem einzelnen Benutzer entspricht. Die Workloadidentität wird einer hohen Berechtigung für die Daten im Quellsystem gewährt.

Wenn Sie mit benutzerbezogenen Daten arbeiten, müssen Sie möglicherweise einen Ansatz wie die Delegierung verwenden, um auf die richtige Teilmenge von Daten aus dem Datensatz zuzugreifen. Anschließend erhält das Zielsystem die gleiche Berechtigung wie ein bestimmter Benutzer. Weitere Informationen zur Benutzerdelegierung finden Sie unter dem unten aufgeführten Ansatz für den delegierten Benutzerzugriff. Wenn Sie die Delegierung verwenden, sollten Sie überlegen, wie Sie Szenarien behandeln, in denen ein Benutzer deprovisioniert oder seine Berechtigungen geändert wird.

Echtzeit oder Batch

Überlegen Sie, ob Sie mit Echtzeitdaten arbeiten oder ob die Daten in Batches gesendet werden.

Für Echtzeitintegrationen sind diese Ansätze häufig:

• Anforderung/Antwort ist der Ort, an dem ein Client eine Anforderung an einen Server initiiert und eine Antwort erhält. In der Regel werden Anforderungs-/Antwortintegrationen mithilfe von APIs oder Webhooks implementiert. Anforderungen sind möglicherweise synchron, wo sie auf die Bestätigung und eine Antwort warten. Alternativ können Anforderungen asynchron sein, indem sie etwas wie das Asynchrone Anforderungsantwortmuster verwenden, um auf eine Antwort zu warten.
• Die lose gekoppelte Kommunikation wird häufig über Messaging-Komponenten aktiviert, die für lose Kopplungssysteme konzipiert sind. Beispielsweise bietet Azure Service Bus Nachrichten queuing-Funktionen, und Azure Event Grid und Event Hubs bieten Ereignisfunktionen. Diese Komponenten werden häufig als Teil der Integrationsarchitekturen verwendet.

Im Gegensatz dazu werden Batchintegrationen häufig über einen Hintergrundauftrag verwaltet, der zu bestimmten Zeiten des Tages ausgelöst werden kann. Häufig werden Batchintegrationen durch einen Stagingspeicherort wie z. B. einen Blobspeichercontainer durchgeführt, da die ausgetauschten Datensätze groß sein können.

Datenvolumen

Es ist wichtig, das Datenvolumen zu verstehen, das Sie durch eine Integration austauschen, da diese Informationen Ihnen dabei helfen, ihre Gesamtsystemkapazität zu planen. Wenn Sie die Kapazität Ihres Systems planen, denken Sie daran, dass verschiedene Mandanten möglicherweise unterschiedliche Datenmengen zum Austausch haben.

Für Echtzeitintegrationen können Sie Volumen als Anzahl der Transaktionen über einen bestimmten Zeitraum messen. Für Batchintegrationen können Sie das Volumen entweder als Anzahl von Datensätzen messen, die ausgetauscht werden oder die Datenmenge in Bytes.

Datenformate

Wenn Daten zwischen zwei Parteien ausgetauscht werden, ist es wichtig, dass beide eine klare Vorstellung davon haben, wie die Daten formatiert und strukturiert werden. Betrachten Sie die folgenden Teile des Datenformats:

• Das Dateiformat, z. B. JSON, Parkett, CSV oder XML.
• Das Schema, z. B. die Liste der Felder, die eingeschlossen werden, Datumsformate und Nullbarkeit von Feldern.

Wenn Sie mit einem multitenanten System arbeiten, ist es am besten, das gleiche Datenformat für alle Ihre Mandanten zu standardisieren und zu verwenden. Auf diese Weise vermeiden Sie, Ihre Integrationskomponenten für die Anforderungen jedes Mandanten anzupassen und erneut zu testen. In einigen Situationen müssen Sie jedoch möglicherweise verschiedene Datenformate für die Kommunikation mit verschiedenen Mandanten verwenden, und sie müssen möglicherweise mehrere Integrationen implementieren. Weitere Informationen finden Sie in den Abschnitten Kompposable-Integrationskomponenten für einen Ansatz, der dazu beitragen kann, diese Art von Situation zu vereinfachen.

Zugriff auf Mandantensysteme

Einige Integrationen erfordern, dass Sie eine Verbindung mit den Systemen oder Datenspeichern Ihres Mandanten herstellen. Wenn Sie eine Verbindung mit den Systemen Ihres Mandanten herstellen, müssen Sie die Netzwerk- und Identitätskomponenten der Verbindung sorgfältig berücksichtigen.

Netzwerkzugriff

Berücksichtigen Sie die Netzwerktopologie für den Zugriff auf das System Ihres Mandanten. Dazu gehören u. U. die folgenden Optionen:

• Stellen Sie eine Verbindung über das Internet her. Wenn Sie sich über das Internet verbinden, wie wird die Verbindung gesichert und wie werden die Daten verschlüsselt? Wenn Ihre Mandanten planen, basierend auf Ihren IP-Adressen einzuschränken, stellen Sie sicher, dass die Azure-Dienste, die Ihre Lösung verwendet, statische IP-Adressen für ausgehende Verbindungen unterstützen können. Berücksichtigen Sie beispielsweise die Verwendung von NAT Gateway, um statische IP-Adressen bereitzustellen, falls erforderlich. Wenn Sie ein VPN benötigen, überlegen Sie sich, wie Sie Schlüssel sicher mit Ihren Mandanten austauschen.
• Agents, die in der Umgebung eines Mandanten bereitgestellt werden, können einen flexiblen Ansatz bieten und Ihnen helfen, die Notwendigkeit Ihrer Mandanten zu vermeiden, eingehende Verbindungen zuzulassen.
• Relays, z. B. Azure Relay, bieten auch einen Ansatz, um eingehende Verbindungen zu vermeiden.

Weitere Informationen finden Sie in den Anleitungen zu Netzwerkansätzen für mehrstufige Mandanten.

Authentifizierung

Berücksichtigen Sie, wie Sie sich bei jedem Mandanten authentifizieren, wenn Sie eine Verbindung initiieren. Berücksichtigen Sie die folgenden Ansätze:

• Geheime Schlüssel, z.B. API-Schlüssel oder Zertifikate. Es ist wichtig zu planen, wie Sie die Anmeldeinformationen Ihrer Mandanten sicher verwalten. Durch die Verleckung ihrer Mandantenschlüssel kann ein wichtiger Sicherheitsvorfall auftreten, der sich möglicherweise auf viele Mandanten auswirkt.
• Microsoft Entra-Token, bei denen Sie ein Token verwenden, das vom eigenen Microsoft Entra-Verzeichnis des Mandanten ausgestellt wurde. Das Token kann direkt an Ihre Workload ausgestellt werden, indem Sie eine mehrstufige Microsoft Entra-Anwendungsregistrierung oder einen bestimmten Dienstprinzipal verwenden. Alternativ kann Ihre Arbeitslast delegierte Berechtigungen anfordern, um im Auftrag eines bestimmten Benutzers im Verzeichnis des Mandanten auf Ressourcen zuzugreifen.

Je nachdem, welche Vorgehensweise Sie auswählen, stellen Sie sicher, dass Ihre Mandanten dem Prinzip der geringsten Berechtigung folgen und vermeiden, Ihr System unnötige Berechtigungen zu gewähren. Wenn Ihr System beispielsweise nur Daten aus dem Datenspeicher eines Mandanten lesen muss, sollte die Identität, die Ihr System verwendet, keine Schreibberechtigungen haben.

Zugriff auf Ihre Systeme

Wenn Mandanten eine Verbindung mit Ihrem System herstellen müssen, sollten Sie dedizierte APIs oder andere Integrationspunkte bereitstellen, die Sie dann als Teil des Oberflächenbereichs Ihrer Lösung modellieren können.

In einigen Situationen können Sie entscheiden, Ihre Mandanten direkt auf Ihre Azure-Ressourcen zuzugreifen. Berücksichtigen Sie die Auswirkungen sorgfältig und stellen Sie das Verständnis sicher, wie Sie den Zugriff auf Mandanten auf sichere Weise gewähren. Sie können z. B. eine der folgenden Lösungsmöglichkeiten verwenden:

• Verwenden Sie das Valet Key-Muster, das die Verwendung von Sicherheitsmaßnahmen wie freigegebene Zugriffssignaturen umfasst, um eingeschränkten Zugriff auf bestimmte Azure-Ressourcen zu gewähren.
• Verwenden Sie dedizierte Ressourcen für Integrationspunkte, z.B. ein dediziertes Speicherkonto. Es empfiehlt sich, Integrationsressourcen von Ihren Kernsystemressourcen getrennt zu halten. Dieser Ansatz hilft Ihnen, den Strahlradius eines Sicherheitsvorfalls zu minimieren. Außerdem wird sichergestellt, dass ein Mandant versehentlich große Verbindungen mit der Ressource initiiert und seine Kapazität auslastet, dann wird der Rest des Systems weiterhin ausgeführt.

Kompatibilität

Wenn Sie beginnen, direkt mit den Daten Ihrer Mandanten zu interagieren oder diese Daten zu übertragen, ist es wichtig, dass Sie ein klares Verständnis der Governance- und Complianceanforderungen Ihrer Mandanten haben.

Zu berücksichtigende Ansätze und Muster

APIs verfügbar machen

Echtzeitintegrationen umfassen häufig die Bereitstellung von APIs für Ihre Mandanten oder andere Parteien. APIs erfordern besondere Überlegungen, insbesondere bei der Verwendung durch externe Parteien. Stellen Sie sich die folgenden Fragen:

• Wer erhält Zugriff auf die API?
• Wie authentifizieren Sie die Benutzer der API?
• Gibt es eine Beschränkung auf die Anzahl der Anforderungen, die ein API-Benutzer über einen Bestimmten Zeitraum vornehmen kann?
• Wie stellen Sie Informationen zu Ihren APIs und dokumentationen für jede API bereit? Müssen Sie beispielsweise ein Entwicklerportal implementieren?

Eine gute Methode besteht darin, ein API-Gateway wie Azure API Management zu verwenden, um diese Bedenken und viele andere zu behandeln. API-Gateways bieten Ihnen einen einzigen Ort zum Implementieren von Richtlinien, die Ihre APIs befolgen, und sie vereinfachen die Implementierung Ihrer Back-End-API-Systeme. Um mehr darüber zu erfahren, wie API Management eine mandantenfähige Architektur unterstützt, lesen Sie Verwendung von Azure API Management in einer multimandantenfähigen Lösung.

Muster „Valet-Schlüssel“

Gelegentlich benötigt ein Mandant möglicherweise direkten Zugriff auf eine Datenquelle, z. B. Azure Storage. Erwägen Sie, das Valet Key-Muster zu folgen, um Daten sicher zu teilen und den Zugriff auf den Datenspeicher einzuschränken.

Beispielsweise können Sie diesen Ansatz beim Exportieren einer großen Datendatei verwenden. Nachdem Sie die Exportdatei generiert haben, können Sie sie in einem Blobcontainer in Azure Storage speichern und dann eine zeitgebundene, schreibgeschützte freigegebene Zugriffssignatur generieren. Diese Signatur kann dem Mandanten zusammen mit der BLOB-URL bereitgestellt werden. Der Mandant kann die Datei dann aus Azure Storage herunterladen, bis die Signatur abläuft.

Ebenso können Sie eine freigegebene Zugriffssignatur mit Berechtigungen zum Schreiben in ein bestimmtes Blob generieren. Wenn Sie eine freigegebene Zugriffssignatur für einen Mandanten bereitstellen, können sie ihre Daten in das Blob schreiben. Mithilfe der Ereignisrasterintegration für Azure Storage kann Ihre Anwendung benachrichtigt werden, um die Datendatei zu verarbeiten und zu importieren.

webhooks

Webhooks ermöglichen Es Ihnen, Ereignisse an Ihre Mandanten an eine URL zu senden, die sie Ihnen zur Verfügung stellen. Wenn Sie Informationen zum Senden haben, initiieren Sie eine Verbindung mit dem Webhook des Mandanten und fügen Ihre Daten in die HTTP-Anforderungsnutzlast ein.

Wenn Sie ihr eigenes Webhook-Ereignissystem erstellen möchten, sollten Sie den CloudEvents-Standard folgen, um die Integrationsanforderungen Ihrer Mandanten zu vereinfachen.

Alternativ können Sie einen Dienst wie Azure Event Grid verwenden, um Webhook-Funktionen bereitzustellen. Das Ereignisraster funktioniert nativ mit CloudEvents und unterstützt Ereignisdomänen, die für Multitenant-Lösungen nützlich sind.

Delegierter Benutzerzugriff

Wenn Sie auf Daten aus den Datenspeichern eines Mandanten zugreifen, sollten Sie überlegen, ob Sie die Identität eines bestimmten Benutzers verwenden müssen, um auf die Daten zuzugreifen. Wenn Sie dies tun, unterliegt Ihre Integration den gleichen Berechtigungen, die der Benutzer hat. Dieser Ansatz wird häufig als delegierter Zugriff bezeichnet.

Angenommen, Ihr mehrstufiger Dienst führt maschinelle Lernmodelle über die Daten Ihrer Mandanten aus. Sie müssen auf die Instanzen der einzelnen Mandantendienste zugreifen, z. B. Azure Synapse Analytics, Azure Storage, Azure Cosmos DB und andere. Jeder Mandant hat ein eigenes Microsoft Entra-Verzeichnis. Ihre Lösung kann delegierten Zugriff auf den Datenspeicher erhalten, sodass Sie die Daten abrufen können, auf die ein bestimmter Benutzer zugreifen kann.

Der delegierte Zugriff ist einfacher, wenn der Datenspeicher die Microsoft Entra-Authentifizierung unterstützt. Viele Azure-Dienste unterstützen Microsoft Entra-Identitäten.

Angenommen, Ihre mehrstufigen Webanwendungs- und Hintergrundprozesse müssen mithilfe der Benutzeridentitäten Ihrer Mandanten aus Microsoft Entra auf Azure Storage zugreifen. Führen Sie zum Zurücksetzen die folgenden Schritte aus:

1. Erstellen Sie eine mehrstufige Microsoft Entra-Anwendungsregistrierung, die Ihre Lösung darstellt.
2. Erteilen Sie der Delegierten Berechtigung der Anwendung, als angemeldeter Benutzer auf Azure Storage zuzugreifen.
3. Konfigurieren Sie Ihre Anwendung so, dass Benutzer*innen mithilfe von Microsoft Entra authentifiziert werden.

Nachdem sich ein*e Benutzer*in angemeldet hat, stellt Microsoft EntraI ID Ihrer Anwendung ein kurzlebiges Zugriffstoken aus, das für den Zugriff auf Azure Storage im Namen der Benutzerin/des Benutzers verwendet werden kann, und es stellt ein langlebigeres Aktualisierungstoken aus. Ihr System muss das Aktualisierungstoken sicher speichern, sodass Ihre Hintergrundprozesse neue Zugriffstoken abrufen und weiterhin im Auftrag des Benutzers auf Azure Storage zugreifen können.

Nachrichten

Messaging ermöglicht asynchrone, lose gekoppelte Kommunikation zwischen Systemen oder Komponenten. Messaging wird häufig in Integrationsszenarien verwendet, um die Quell- und Zielsysteme zu entkoppeln. Weitere Informationen zu Messaging und Multitenancy finden Sie unter Architekturansätze für Messaging in Multitenant-Lösungen.

Wenn Sie Messaging als Teil einer Integration mit den Systemen Ihrer Mandanten verwenden, sollten Sie überlegen, ob Sie freigegebene Zugriffssignaturen für Azure Service Bus oder Azure Event Hubs verwenden sollten. Freigegebene Zugriffssignaturen ermöglichen Es Ihnen, eingeschränkten Zugriff auf Ihre Messagingressourcen für Dritte zu gewähren, ohne dass sie auf den Rest Ihres Messaging-Subsystems zugreifen können.

In einigen Szenarien können Sie unterschiedliche Vereinbarungen auf Dienstebene (SLAs) oder QoS (Quality of Service, QoS)-Garantien für unterschiedliche Mandanten bereitstellen. Eine Teilmenge Ihrer Mandanten kann beispielsweise erwarten, dass ihre Datenexportanforderungen schneller verarbeitet werden als andere. Mithilfe des Musters Prioritätswarteschlange können Sie separate Warteschlangen für unterschiedliche Prioritätsebenen erstellen, wobei unterschiedliche Arbeitsinstanzen diese entsprechend priorisiert werden.

Komponierbare Integrationskomponenten

Manchmal müssen Sie möglicherweise in viele verschiedene Mandanten integrieren, von denen jede verschiedene Datenformate oder verschiedene Arten von Netzwerkkonnektivität verwendet.

Ein allgemeiner Ansatz in der Integration besteht darin, einzelne Schritte zu erstellen und zu testen, die die folgenden Arten von Aktionen ausführen:

• Abrufen von Daten aus einem Datenspeicher.
• Transformieren Sie Daten in ein bestimmtes Format oder Schema.
• Übertragen Sie die Daten mithilfe eines bestimmten Netzwerktransports oder an einen bekannten Zieltyp.

In der Regel erstellen Sie diese einzelnen Elemente mithilfe von Diensten wie Azure Functions und Azure Logic Apps. Anschließend definieren Sie den gesamten Integrationsprozess mithilfe eines Tools wie Logic Apps oder Azure Data Factory und ruft jede der vordefinierten Schritte auf.

Wenn Sie mit komplexen multitenanten Integrationsszenarien arbeiten, kann es hilfreich sein, eine Bibliothek der wiederverwendbaren Integrationsschritte zu definieren. Anschließend können Sie Workflows für jeden Mandanten erstellen, um die entsprechenden Elemente zusammen zu verfassen, basierend auf den Anforderungen dieses Mandanten. Alternativ können Sie einige der Datasets oder Integrationskomponenten direkt für Ihre Mandanten verfügbar machen, damit sie ihre eigenen Integrationsworkflows von ihnen erstellen können.

Ebenso müssen Sie möglicherweise Daten aus Mandanten importieren, die ein anderes Datenformat oder einen anderen Transport verwenden. Ein guter Ansatz für dieses Szenario besteht darin, mandantenspezifische Connectors zu erstellen. Konnektoren sind Workflows, die die Daten normalisieren und in ein standardisiertes Format und an einen standardisierten Ort importieren und dann Ihren gemeinsamen Hauptimportprozess auslösen.

Wenn Sie mandantenspezifische Logik oder Code erstellen müssen, sollten Sie das Muster der Antikorruptionsschicht befolgen. Das Muster hilft Ihnen, mandantenspezifische Komponenten zu kapseln und gleichzeitig den Rest Ihrer Lösung nicht über die hinzugefügte Komplexität zu verfügen.

Wenn Sie ein tarifiertes Preismodell verwenden, können Sie festlegen, dass Mandanten mit einem niedrigen Preisniveau einen Standardansatz mit einem begrenzten Satz von Datenformaten und Transporten befolgen. Höhere Preisstufen ermöglichen möglicherweise mehr Anpassungen oder Flexibilität in den von Ihnen angebotenen Integrationskomponenten.

Zu vermeide Antimuster

• Direktes Exposieren Ihrer primären Datenspeicher an Mandanten. Wenn Mandanten auf Ihre primären Datenspeicher zugreifen, kann der Schutz dieser Datenspeicher schwieriger werden. Möglicherweise verursachen sie auch versehentlich Leistungsprobleme, die sich auf Ihre Lösung auswirken. Vermeiden Sie das Bereitstellen von Anmeldeinformationen für Ihre Datenspeicher für Ihre Kunden, und replizieren Sie daten nicht direkt aus Ihrer primären Datenbank in die Lesereplikate desselben Datenbanksystems. Erstellen Sie stattdessen dedizierte Integrationsdatenspeicher, und verwenden Sie das Valet Key-Muster, um die Daten verfügbar zu machen.
• Bereitstellen von APIs ohne API-Gateway. APIs haben spezifische Bedenken für die Zugriffssteuerung, Abrechnung und Meterierung. Auch wenn Sie zunächst keine API-Richtlinien verwenden möchten, ist es ratsam, ein API-Gateway frühzeitig einzuschließen. Wenn Sie Ihre API-Richtlinien in Zukunft anpassen müssen, müssen Sie keine unterbrechungsweisen Änderungen an den URLs vornehmen, von denen ein Drittanbieter abhängig ist.
• Unnötig enge Kopplung. Lose Kopplung, z. B. mithilfe von Messaging-Ansätzen, kann eine Reihe von Vorteilen für Sicherheit, Leistungsisolation und Resilienz bieten. Wenn möglich, ist es ratsam, Ihre Integrationen mit Dritten lose zu verkoppeln. Wenn Sie eng mit einem Drittanbieter verbunden sein müssen, stellen Sie sicher, dass Sie bewährte Methoden wie das Wiederholungsmuster, das Trennschalter-Muster und das Bulkhead-Muster befolgen.
• Benutzerdefinierte Integrationen für bestimmte Mandanten. Mandantenspezifische Features oder Code können Ihre Lösung schwieriger testen. Außerdem ist es schwieriger, Ihre Lösung in Zukunft zu ändern, da Sie mehr Codepfade verstehen müssen. Versuchen Sie stattdessen, komponierbare Komponenten zu erstellen, die die Anforderungen für jeden bestimmten Mandanten abstrahieren und diese in mehreren Mandanten mit ähnlichen Anforderungen wiederverwenden.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• John Downs | Principal Software Engineer
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

• Will Velida | Customer Engineer 2, FastTrack for Azure

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Sehen Sie sich Architekturansätze für Messaging in mandantenfähigen Lösungen an.