Veröffentlichung und Governance
Definitionen haben unterschiedliche Lebenszyklen. Prüfe die tatsächlichen Kontrollen und den Speicherstatus. Eine Studio-Änderung kann gespeichert und unveröffentlicht sein; eine veröffentlichte Automation kann inaktiv sein; eine übertragene Definition kann weitere Einrichtung im Ziel benötigen.
Wirkung der Aktionen verstehen
| Aktion | Ergebnis |
|---|---|
| Versionierten Entwurf speichern | Bewahrt Arbeit, ohne live Veröffentlichung zu ersetzen. |
| Checkpoint speichern | Erstellt einen Verlaufspunkt zur Wiederherstellung. |
| Material, Arbeitsplatz, Stückliste, Arbeitsplan veröffentlichen | Macht die Definition im Kontext verfügbar und zeichnet eine Version auf. |
| App veröffentlichen | Erstellt die nutzbare Version; weitere Entwurfsänderungen bleiben getrennt. |
| Tabelle speichern | Wendet Schema direkt an; keine separate Veröffentlichung. |
| Dokument-/Etikettenvorlage veröffentlichen | Macht Layout verfügbar; vorhandene Ausgaben behalten ihre Inhalte. |
| Automation veröffentlichen | Prüft und speichert den Ablauf. |
| Automation/Rezept aktivieren | Ermöglicht die vorgesehene automatische/Laufzeitnutzung. |
| Test nach Produktion übertragen | Gleicht unterstützte Konfiguration im gewählten Werk ab. |
| Bericht finalisieren | Fixiert eine Revision/PDF, nicht ihre Quellvorlage. |
Entwurf, Veröffentlichung, Zuweisung, Ausführung und Übertragung benötigen unterschiedliche Rechte. Eine Vorschau erteilt keine nächste Berechtigung. Konnie verwendet dieselben kontextbezogenen Dienste und Freigabe-/Abhängigkeitsregeln.
Vor Veröffentlichung prüfen
Prüfe Werk/System und Definition, warte auf Speichern und kontrolliere Entwurf sowie Abhängigkeiten. Nutze Vorschau mit typischen, leeren und Variantenfällen. Prüfe im Graph jeden Pfad.
Öffne das genannte Feld oder den Knoten bei Validierungsfehlern. Repariere fehlende Referenzen, Typen, Pflichtzuordnungen, Provider und Empfänger. Ersetze verweigerte Abhängigkeiten nicht durch vermutete Kennungen.
Ergänze eine Notiz mit der operativen Wirkung, etwa „Charge vor Abschlussprüfung verpflichtend“. Veröffentliche den geprüften Entwurf und prüfe anschließend die nutzbare Veröffentlichung. Autospeichern oder ein geschlossener Dialog belegt sie nicht allein.
Verlauf und Wiederherstellung
Verlauf/Checkpoints zeigen gespeicherte Inhalte und Veröffentlichungen. Wiederherstellung erzeugt gewöhnlich einen Entwurf. Vergleiche Abhängigkeiten und veröffentliche, wenn er live werden soll. Eine wiederhergestellte Vorlage verändert keine ausgestellten Dokumente; Berichtskorrekturen erzeugen neue Revisionen.
Ein Versionskonflikt bedeutet parallele Änderung. Sichere benötigte ungespeicherte Informationen, lade den aktuellen Stand, vergleiche und wende deine Änderung erneut an. Überschreibe nicht wiederholt einen neueren Entwurf.
Testkonfiguration nach Produktion übertragen
Öffne im gewählten Werk Test nach Produktion. Vorschau und Anwendung haben getrennte Rechte. Für die Anwendung gelten Vorbereitungsrechte in Test und Übertragungsrechte in Produktion. Wähle Alles, Kategorien oder Ausgewählte Objekte und prüfe Feldänderungen, Abhängigkeiten und Probleme.
Alles und Kategorien behalten Objekte, die nur in Produktion bestehen. Physisches Löschen über Übertragung, Zurücksetzen oder Rücknahme ist gesperrt: Eine Referenzprüfung kann einen gleichzeitig erstellten Laufzeitdatensatz nicht ausschließen. Archiviere oder entferne Definitionen zuerst über ihren eigenen Lebenszyklus im Ziel. Direkte Produktionsänderungen und ein fehlender gemeinsamer Ausgangsstand benötigen eine ausdrückliche Entscheidung für das jeweilige Objekt. Berechtigte Personen können Produktion weiterhin direkt bearbeiten.
Veröffentliche Quellentwürfe, bevor du ihre Definition überträgst. Die Vorschau nennt ausgewählte unveröffentlichte Quellarbeit, statt unbemerkt eine ältere gespeicherte Definition zu übertragen. Zielentwurf und Quellveröffentlichung sind getrennte Aktionen. Zurücksetzen verwendet die veröffentlichte Produktionsdefinition und nennt nicht übernommene Quellentwürfe.
Die Anwendung gilt für die geprüfte Vorschau. Ändert sich ein Arbeitsbereich oder Zielentwurf, aktualisiere und prüfe die Vorschau erneut. Eine Übertragung wird in einer Transaktion angewandt; spätere Prüf- oder Schreibfehler lassen frühere Konfigurationsänderungen unangewandt. Ist das Ergebnis unbekannt, prüfe vor einem erneuten Versuch den Übertragungsverlauf.
Der Plan betrifft Konfiguration. Laufzeitaufträge, Verlauf und Produktionsbindungen werden nicht aus Test kopiert. Abhängigkeiten können die Auswahl erweitern. Behebe blockierende Probleme und aktualisiere die Vorschau. Ein erfolgreicher Quelltest beweist keine vollständige Laufzeiteinrichtung im Ziel.
Arbeitsplatzkonfiguration wird sofort angewendet; aktuelle Aufträge, Betriebsstatus und Kennzahlen bleiben im Ziel erhalten. Ein geänderter Zielentwurf blockiert eine normale Übertragung; ein unveränderter Editor folgt der übertragenen Definition. Prüfe diese unmittelbare Wirkung getrennt von bereitgestellten Zielentwürfen.
Die normale Übertragung legt Zielentwürfe für Apps, Etiketten, Dokumentvorlagen und Automationen an. Aktuelle Zielveröffentlichungen, Zielgruppen, Ausführungssperren, Verantwortliche und Ausführungsidentitäten bleiben erhalten. Veröffentliche und aktiviere im Ziel mit den passenden Rechten. Eine Quellversionsnummer wird nicht zur Zielveröffentlichung und eine neue Automation nicht automatisch aktiv. Nicht unterstützte feste Laufzeitreferenzen sowie Tabellen-/Ansichtsbindungen müssen vor der Übertragung des Pakets geklärt werden. Inaktive Rezepte erhalten einen Zielentwurf mit Checkpoint; Änderungen an aktiven Zielrezepten erfolgen über deren eigenen Lebenszyklus.
Prüfe nach Anwendung den Übertragungsverlauf und die Zieldefinitionen. Kontrolliere App-Zielgruppe/Zuweisung, aktive Abläufe, sicheren Integrationszugriff und verwaltete Laufzeitvoraussetzungen. Führe einen vereinbarten Zieltest aus.
Eigenständige Formulare wurden eingestellt und können nicht übertragen werden. Materialien, Stücklisten und Arbeitspläne werden über native Zielentwürfe und Checkpoints übertragen. Aktive Definitionen und Standardauswahlen bleiben bis zur nativen Veröffentlichung bestehen. Unveröffentlichte Zieländerungen blockieren eine Übertragung; prüfe und veröffentliche oder verwirf sie zuerst im Ziel. Vollständige Abhängigkeitspakete übersetzen Komponentenmaterialien, Arbeitsplätze und Arbeitsplanreferenzen in Zielidentitäten. Die native Veröffentlichung benötigt weiterhin die entsprechenden Bearbeitungs- und Veröffentlichungsrechte im Ziel.
Test aus Produktion zurücksetzen aktualisiert unterstützte Testkonfiguration und ersetzt die geprüften Testentwürfe. Sichere vorher Arbeit, die du behalten möchtest. Die Vorschau berücksichtigt geänderte Entwürfe auch bei unveränderter gespeicherter Definition. Operative Aufträge, Ergebnisse und Verlauf bleiben in Test. Das Zurücksetzen erzeugt weder eine leere Testdatenbank noch eine Kopie der Produktionsaktivität.
Zwischen weiteren Umgebungen übertragen
Öffne Freigabe → Zwischen Umgebungen … und wähle Quelle und Ziel innerhalb des aktuellen Standorts. Jedes Paar hat eigene Rechte, eine eigene Vorschau und den Zielverlauf. Ein Wechsel von Quelle oder Ziel verwirft die alte Vorschau. Gleiche Quell- und Zielumgebungen können nicht angewendet werden. Die beschriebenen Schutzregeln für Konflikte, Abhängigkeiten, Zugangsdaten, Entwürfe und unbekannte Ergebnisse gelten auch hier. Standortübergreifende Übertragungen werden nicht unterstützt.
Eine Übertragung zurücknehmen
Wähle im Verlauf Zurücknehmen für die abgeschlossene Übertragung und prüfe die Vorschau. Dies stellt betroffene Konfiguration wieder her und bewahrt Laufzeithistorie sowie Produktionsbindungen. Die Rücknahme einer veröffentlichten Definition wird als neuer Zielentwurf geprüft und veröffentlicht; sie setzt weder eine aktive Versionsreferenz noch Rechte oder Zeitplan einer Automation zurück. Auch ein geänderter Zielentwurf blockiert eine veraltete Rücknahme.
Die Rücknahme ist blockiert, wenn ein Zielobjekt seitdem geändert, entfernt oder neu erstellt wurde, wenn sie ein neu erstelltes Objekt physisch löschen würde oder wenn einem älteren Beleg die Entwurfs-/Veröffentlichungsdaten fehlen. Stelle solche älteren Definitionen im eigenen Zieleditor wieder her. Bestandshistorie und Einheitenbeschränkungen bleiben wirksam. Kläre den konkreten Konflikt; eine blinde Rücknahme ist keine Wiederherstellung operativer Daten.
Operatives Ergebnis prüfen
Öffne die veröffentlichte Ziel-App mit dem vorgesehenen Konto. Prüfe Daten und eine autorisierte Testaktion. Lies Ergebnisdatensatz/Bericht und gegebenenfalls Lauf-/Druckhistorie. Prüfe bei Zugriffsänderungen ein Konto, das abgewiesen werden soll.
Unterscheide in Übergaben gespeichert, veröffentlicht, aktiv, übertragen und operativ geprüft. Siehe Rollen und Berechtigungen, Konnie-Freigaben und Auditprotokolle.