Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Organisieren Ihrer Metadaten

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Nennen der wichtigsten Strategien für die Organisation nicht gepackter Metadaten in Paketen
  • Erkennen, wie freigeschaltete Pakete voneinander abhängen können
  • Beschreiben der drei Paketentwicklungsmodelle und Nennen von Kriterien für ihre Verwendung

Umsetzen der Prinzipien der Paketentwicklung in die Praxis

Herzlichen Glückwunsch! In der vorherigen Einheit haben Sie ein Paket erstellt und die DreamHouse-Anwendung in Ihrem Trailhead Playground installiert. Jetzt zeigen wir Ihnen, wie Sie einige der wichtigsten Prinzipien der Paketentwicklung in die Praxis umsetzen. Denken Sie daran, es ist in Ordnung, klein anzufangen und auf den Erfolgen aufzubauen.

Das Organisieren Ihrer Metadaten in Paketen:

  • Ist oft ein iterativer Prozess.
  • Ist kein Alles-oder-nichts-Ansatz.

Organisieren von Metadaten für eine neue oder bestehende benutzerdefinierte Anwendung

DreamHouse ist ein großartiges Beispiel dafür, wie Sie eine neue Anwendung von Grund auf neu erstellen und in ein freigeschaltetes Paket packen, damit Sie sie in Ihrer Organisation einführen und zukünftige Anpassungen verwalten können. Sie können diesem Prozess aber auch bei der Aktualisierung neuer Merkmale oder Funktionen für eine bestehende benutzerdefinierte Anwendung folgen.

Alles in allem haben wir DreamHouse entwickelt, um Ihnen Folgendes zu zeigen:

  • Integrieren der Salesforce CLI, Projekte und freigeschalteten Pakete in Ihren Anwendungslebenszyklus
  • Umsetzen bewährter Vorgehensweisen beim Organisieren von Metadaten und Erstellen von Paketgrenzen
  • Implementieren freigeschalteter Pakete beim Erstellen einer neuen Anwendung

Was können Sie tun, nachdem Sie ein freigeschaltetes Paket für DreamHouse erstellt haben?

  • Quellcode für die Anwendung unabhängig testen und verteilen
  • Das Anwendungsschema (benutzerdefinierte Objekte) von anderen Metadaten isolieren
  • Weitere Verbesserungen an der Anwendung vornehmen, indem Sie den Prozess wiederholen und neue Funktionen hinzufügen
  • Die Anwendung versionieren
  • Eine zweite Version als Upgrade einer vorhandenen Version installieren

DreamHouse-Metadaten

Metadaten Beschreibung
Schema Enthält benutzerdefinierte Objekte für "Broker", "Property" und "Favorite".

Beispiele: Broker__c, Property__c, Favorite__c

Lightning-Anwendungen und -Komponenten Untersuchen Sie Immobilien und zeigen Sie Details dazu an.

Beispiele: Property_Explorer.flexipage-meta.xml, Property_Record_Page.flexipage-meta.xml

Prozesse (Flows) Senden Sie Benachrichtigungen, wenn neue Immobilien hinzugefügt werden oder sich der Preis ändert.

Beispiele: Advertise_New_Property-2.flow-meta.xml, Price_Change_Push_Notification-1.flow-meta.xml

Einstein-Services Wenden Sie Bildverarbeitung an, um automatisch Hausdetails aus hochgeladenen Bildern zu erfassen.

Beispiel: EinsteinVisionController.cls

Bots Ermöglichen Sie Kunden, sich für die Immobiliensuche per Facebook Messenger, Slack oder Alexa zu verbinden.

Beispiel: HandlerFindProperties.cls

Aufgliedern der vorhandenen Metadaten Ihrer Organisation

Wie Sie sehen, ist es sehr sinnvoll, den Paketentwicklungs-Lebenszyklus für neue Projekte zu nutzen. Wir wissen jedoch, dass Bestandskunden, die die Entwicklung mit Änderungssets über mehrere Versionen oder sogar Jahre hinweg genutzt haben, nach Anleitung und Ratschlägen dazu fragen, wo sie anfangen sollen. Wie schlüsseln Sie den Inhalt Ihrer Organisation in separate Projekte auf und packen letztendlich Verzeichnisse?

Wir würden Ihnen wirklich gerne ein Patentrezept dafür geben, aber es gibt keinen vorgeschriebenen Aktionsplan. Der Ansatz beim Aufgliedern der nicht gepackten Metadaten ist eine Kombination aus Wissenschaft und Kunst. Sie können am besten beurteilen, welche Metadaten in welche Salesforce DX-Projekte passen.

Stellen Sie sich zu Beginn folgende Fragen:

  • Möchten Sie, dass Ihre Entwicklungsteams Anwendungen, neue Funktionen und Anpassungen selbstständig veröffentlichen können?
  • Können Sie Metadaten identifizieren, die eine Anwendung darstellen?
  • Können Sie Ihre Metadaten in Module für verschiedene Funktionen organisieren?
  • Wenn Sie ein nicht verwaltetes Paket für diese Funktion oder Anwendung erstellen, welche Abhängigkeiten liegen vor?

Wenn Sie mehrere Anwendungen und Anpassungen in Ihrer Organisation haben, sollten Sie mit einigen Abhängigkeiten zwischen Salesforce DX-Projekten rechnen.

Drei Modelle zum Aufschlüsseln Ihrer Metadaten

In realen Szenarien werden Sie wahrscheinlich eine Kombination dieser Strategien anwenden und sie so anpassen, dass sie Ihren Geschäftsanforderungen am besten entsprechen.

Modell Beschreibung
Anwendungsbasiert Sie identifizieren Metadaten, die eine Anwendung darstellen. Dieser Ansatz ist ähnlich wie das Erstellen eines Pakets für die DreamHouse-Anwendung, mit der Ausnahme, dass die Metadaten bereits in Ihrer Organisation enthalten sind.
Anpassungsbasiert Organisieren Sie nicht gepackte Metadaten für Anpassungen und Funktionsänderungen in Ihrer Produktionsorganisation, wie etwa Anpassungen für Sales Cloud, Service Cloud oder eine AppExchange-Anwendung.
Freigegebene Bibliothek Wenn Abhängigkeiten bestehen, verwenden Sie ein gemeinsames Salesforce DX-Paket, um eine Reihe von Apex-Klassen oder häufig verwendeter benutzerdefinierter Objekte zu organisieren. Andere Pakete, die Sie erstellen, können von diesem gemeinsamen Paket abhängen.

Verwenden eines nicht verwalteten Pakets als Ausgangspunkt

Der folgende Workflow eignet sich gut als Ausgangspunkt, um Ihre nicht verwalteten Metadaten in mehreren Paketen zu organisieren:

  1. Wählen Sie eine kleine Menge nicht gepackter, eigenständiger Metadaten aus Ihrer Produktionsorganisation aus. Wählen Sie Metadaten aus, die eine Anwendung, eine Anpassung einer bestehenden Anwendung, eine Funktion oder Funktionseinheit oder Anpassungen von Standardobjekten darstellen.
  2. Erstellen Sie ein nicht verwaltetes Paket, um die von Ihnen identifizierten Metadaten von der Gesamtmenge der Metadaten in Ihrer Organisation zu isolieren. Wenn Sie Metadaten zum Paket hinzufügen, sehen Sie, welche abhängigen Metadaten automatisch vom System geladen werden. Dieser Schritt hilft Ihnen, einige nicht so offensichtliche Abhängigkeiten zwischen Ihren Metadaten aufzudecken.
  3. Rufen Sie mit dem Befehl force:mdapi:retrieve die Quelle aus Ihrem nicht verwalteten Paket ab.
  4. Richten Sie ein Salesforce DX-Projekt und ein Git-Repository zur Verwaltung der Paket-Metadaten ein.
  5. Führen Sie den Befehl force:mdapi:convert aus, um die Quelle in das Salesforce DX-Format zu konvertieren.
  6. Übertragen Sie diese Metadaten mit force:source:push in eine Testorganisation und überprüfen Sie, dass dies die Metadaten sind, die Teil eines freigeschalteten Pakets sein sollen.
  7. Erstellen Sie ein freigeschaltetes Paket unter Verwendung des Flags --nonamespace.
  8. Testen und verteilen Sie das freigeschaltete Paket.
  9. Wenn das freigeschaltete Paket alle CI-Läufe und Benutzerakzeptanztests in Sandbox-Organisationen bestanden hat, stufen Sie die Paketversion hoch.
  10. Installieren das freigeschaltete Paket in der Produktionsorganisation.

Wenn Sie ein Paket für diese Metadaten erstellen, werden diese automatisch in das Paket verschoben. Da der vollständige Name der Entität die Metadaten in der Organisation und im Paket bezeichnet, überschreiben wir die bereits in der Organisation vorhandenen Metadaten und aktualisieren interne Referenzen, um zu zeigen, dass sie nun im Paket enthalten sind.

Paketabhängigkeiten

Ein wichtiger Vorteil freigeschalteter Pakete ist, dass Sie einen Satz voneinander abhängiger Paketen entwickeln und pflegen können.

  • Ein freigeschaltetes Paket kann von einem AppExchange-Paket abhängen. Wenn Sie ein AppExchange-Paket verwenden, können Sie eine eigene Anpassung für dieses in einem freigegebenen Paket platzieren. Wenn Sie das freigegebene Paket installieren, muss das AppExchange-Paket vorhanden sein.
  • Ein freigeschaltetes Paket kann von einem anderen freigeschalteten Paket abhängen. Angenommen, Sie erstellen eine neue Anwendung, mit der Mitarbeiter Spesenabrechnungen einreichen können. Diese Anwendung teilt sich einige Backend-Integrationsfunktionen mit Ihrer bestehenden Gehaltsabrechnungsanwendung. In diesem Szenario hängt das freigeschaltete Spesenabrechnungs-Paket vom freigeschalteten Gehaltsabrechnungs-Pakets ab.
  • Ein freigeschaltetes Paket kann von einem anderen freigeschalteten Paket abhängen, das wiederum von einem anderen freigeschalteten Paket abhängt. Es werden mehrere Abhängigkeitsebenen unterstützt.

Sie geben die Abhängigkeiten im Abschnitt "packageDirectories" der Datei sfdx-project.json an. Durch die Unterstützung von Abhängigkeiten fördern freigeschaltete Pakete die modulare Entwicklung mit einem umfassenden Abhängigkeiten-Framework. Weitere Informationen zur Salesforce DX-Projektdatei finden Sie im Salesforce DX Developer Guide.