Endpunkt „migratable“
Anmerkung
Diese Hilfeseite beschreibt die Verwendung eines Server-API-Endpunkts. Alles, was Sie für Ihre ersten Schritte mit der Server-API benötigen, finden Sie in der Server API-Übersicht.
Verwenden Sie den zur Migration bereiten Endpunkt, um Workflows über Server-Umgebungen hinweg zu migrieren. Damit können Sie Workflow-Bereitstellungen während der Entwicklungs- und Testphase verwalten.
Zunächst müssen Sie Workflows für die Migration aktivieren. Nachdem Sie Workflows für die Migration markiert haben, befolgen Sie die folgenden Schritte, um sie aus der Quellumgebung in das entsprechende Abonnement (Studio) der Zielumgebung zu veröffentlichen.
Schritt 1. Eine Liste von Workflows abrufen, die für die Migration bereit sind
Als Nächstes rufen Sie mit dem folgenden Endpunkt eine Liste von Workflows ab, die für die Migration bereit sind:
Umgebung: Quelle
Methode: GET
Endpunkt: webapi/admin/v1/workflows/migratable/?subscriptionIds={subscriptionIds}/
Fügen Sie eine kommagetrennte Liste von subscriptionIds als Abfrageparameter ein. Abonnement-IDs kennzeichnen ein bestimmtes Studio.
Die Rückgabe ist eine Reihe von Workflows, die als bereit für die Migration unter dem angegebenen Abonnement (Studio) markiert sind. Wenn Sie keine „subscriptionsIds“ bereitstellen, enthält die Rückgabe alle Workflows, die als bereit für die Migration markiert sind. Die Rückgabe enthält drei Eigenschaften: appId, die aktuell veröffentlichte revisionId und die subscriptionID, zu der der Workflow gehört.
Schritt 2. Workflows aus der Quellumgebung herunterladen
Der folgende Endpunkt lädt den Workflow als YXZP-Datei herunter.
Umgebung: Quelle
Methode: GET
Endpunkt: webapi/admin/v1/{appID}/package/
Fügen Sie eine appID als Pfadparameter ein. Die Rückgabe erfolgt als Download des gesamten Workflows als Paket.
Schritt 3. Workflows in der Zielumgebung veröffentlichen
Der folgende Endpunkt veröffentlicht den heruntergeladenen Workflow in der Zielumgebung.
Umgebung:: Ziel
Methode: POST
Endpunkt: webapi/admin/v1/workflows/
Parameter | |||
Parameter | Beschreibung | Typ | Erforderlich |
|---|---|---|---|
Datei | Der Dateiname des neuen Workflows. | Zeichenfolge | Wahr |
Name | Der neue Workflow-Name. | Zeichenfolge | Wahr |
Eigentümer | Der Besitzer des migrierten Workflows. Die E-Mail-Adresse muss in der Zielumgebung vorhanden sein. | Zeichenfolge | Wahr |
validieren | Flag zum Validieren des Workflows bei der Migration in die Zielumgebung. | Boolesch | Wahr |
isPublic | Flag zum Setzen des Workflows auf „öffentlich“; wird in der Zielumgebung unter „Server meines Unternehmens“ angezeigt. | Boolesch | Wahr |
sourceId | Dies ist die appId der Quellumgebung des zu migrierenden Workflows. Wenn ein Workflow mit derselben sourceID vorhanden ist, wird die Version des Workflows inkrementiert. Andernfalls wird ein neuer Workflow generiert. (Senden Sie eine leere Zeichenfolge, wenn Sie keine appID angeben möchten.) | Zeichenfolge | Wahr |
workerTag | Fügen Sie dem Workflow einen Worker-Tag hinzu, damit ein bestimmter Worker den Workflow ausführt. (Senden Sie eine leere Zeichenfolge, wenn Sie keinen Worker festlegen möchten.) | Zeichenfolge | Wahr |
canDownload | Flag zum Definieren des Workflows als für andere Benutzer in der Zielumgebung zum Herunterladen verfügbar. | Boolesch | Wahr |
(Optional) Schritt 4. Workflow-Migrationseinstellungen in der Quellumgebung zurücksetzen
Wenn Sie möchten, können Sie den zur Migration bereiten Endpunkt verwenden, um die Einstellung Dieser Workflow ist bereit für die Migration eines Workflows in der Quellumgebung nach der Workflow-Migration in der Zielumgebung wieder auf Nein zu setzen.
Umgebung: Quelle
Methode: PUT
Endpunkt: webapi/admin/v1/workflows/migratable/{appID}/