Benutzerdefinierten Freigabe-Workflow erstellen

Wenn Sie einen benutzerdefinierten, zweistufigen Freigabe-Workflow anlegen und die zweite Stufe nicht erforderlich ist (d. h. die zweite Stufe ist optional), wechselt Onshape automatisch von „Ausstehend“ zu „Freigegeben“, wenn kein Genehmiger im Freigabepaket angegeben ist. Hierfür muss nichts extra eingerichtet werden. Die einzigen Voraussetzungen sind: ein zweistufiger Workflow, die zweite Stufe ist optional und es wurden keine Genehmiger im „Genehmiger“-Feld im Freigabe-Kandidaten angegeben.

So laden Sie die Onshape Standard-Workflow Dateien herunter:

1. Navigieren Sie zu Ihren Enterprise-Einstellungen und wählen Sie Freigabe-Management aus.
2. Vergewissern Sie sich, dass die Option „Verwaltete Workflows aktivieren“ aktiviert ist. Klicken Sie dann auf „In Dokument anzeigen“.

   

   Die Workflow-Datei wird in einem öffentlichen Dokument in einer anderen Registerkarte geöffnet.

3. Klicken Sie auf „Herunterladen“ und geben Sie einen neuen Namen für die Datei ein.
   

   Sie können diese Registerkarte schließen, sobald die Registerkarte heruntergeladen wurde.

1. Navigieren Sie in Ihrem Enterprise zur Dokumentenseite, wählen Sie „Erstellen“ > „Dokument“ und dann OK aus. (In diesem Beispiel lautet der Dokumentenname Company benutzerdefinierte Workflows).
2. Klicken Sie im neuen Dokument unten auf das Plus-Symbol und wählen Sie „Importieren“ aus:

3. Wählen Sie die Workflow-Datei aus, die Sie gerade heruntergeladen haben, und klicken Sie auf „Öffnen“.
4. In Ihrem Dokument erscheint eine weitere Registerkarte mit dem Namen der Datei, die Sie importiert haben. Wählen Sie diese Registerkarte aus, um sie zu öffnen:

Sie können FeatureScript-Workflow-Aktionen verwenden, um Eigenschaften von Freigabe-Objekten als Teil eines Workflow-Übergangs programmatisch zu aktualisieren. Indem Sie den angepassten Workflow auf ein Feature Studio im gleichen Arbeitsbereich wie die Workflow-Definition verweisen, kann eine Funktion in diesem Feature Studio als Aktion ausgeführt werden, die die auf jedes Objekt anzuwendenden Eigenschaftsaktualisierungen bestimmt.

Für einen benutzerdefinierten Workflow verwenden Sie die Workflow-Aktion „updateItemPropertiesFromFeatureScript“ als Umstellungsaktion oder als Eingangs- oder Ausgangsaktion für einen Status. Die Aktion benötigt folgende Parameter:

• FeatureStudio-ID: Das Feature Studio muss sich im selben Arbeitsbereich befinden wie die angepasste Freigabe-Workflow-Definition.

• Ein Funktionsname, der von diesem Feature Studio exportiert wird: Diese Funktion muss ein einziges Argument mit dem Typ „Abbildung“ annehmen. Der Typ „Abbildung“, der der Funktion bei ihrer Ausführung übergeben wird, enthält diese Daten:

{

// Das vollständige, detaillierte Freigabe-Paket, einschließlich aller Objekte und Eigenschaften

// (wie es von der REST-API getReleasePackage zurückgegeben würde)

"releasePackage": BTReleasePackageInfo,

// Der Benutzer, der die Umstellung durchführt

"currentUser": BTUserSummaryInfo,

// Der Benutzer, der den Freigabe-Kandidaten ursprünglich erstellt hat

"releaseCreator": BTUserSummaryInfo,

// Die auszuführende Umstellung, wie sie in der Workflow-Definition erscheint

"transition": BTTransitionDef,

// Das aktuelle UTC-Datum/die aktuelle UTC-Zeit als ISO-Datumszeichenkette

"currentDate": string

}

Die Funktion muss eine Abbildung mit der folgenden Form zurückgeben:

{[key: string]: {[key: string]: any}}

Die Hauptabbildung wird durch die ID des Freigabe-Objekts verschlüsselt. Die innere Abbildung erfolgt von der ID der Metadaten-Eigenschaft zu einem gewünschten neuen Wert. Ein Beispiel: Eine Funktion gibt die folgende Abbildung zurück:

{

"item1": {

"57f3fb8efa3416c06701d616": "New value",

"customIntProperty": 42

},

"item2": {

"57f3fb8efa3416c06701d617": "Some other value"

}

}

Für das Objekt mit der ID „item1“ wird in diesem Fall die Eigenschaft „Title 1“ auf die Zeichenfolge „New value“ und eine hypothetische benutzerdefinierte Eigenschaft (customIntProperty, siehe oben) auf die Zahl 42 gesetzt. Bei dem Objekt mit der ID „item2“ wird die Eigenschaft „Title 2“ auf die Zeichenfolge „Some other value“ gesetzt.

Die vollständigen Informationen des Freigabe-Pakets werden als Eingabe für die Funktion bereitgestellt, so dass zusätzliche Filterungen und Berechnungen bei Bedarf möglich sind. Beispielsweise kann eine Eigenschaft nur auf Objekte angewandt werden, bei denen es sich um Zeichnungen handelt, oder auf Objekte, die einer bestimmten Kategorie angehören. Ein Eigenschaftswert kann auch aus einem anderen Eigenschaftswert berechnet werden.

Es ist wichtig zu beachten, dass das FeatureScript selbst keine Änderungen am Freigabe-Paket vornimmt. Alle an den Eingabedaten vorgenommenen Modifikationen „überleben“ die FeatureScript-Ausführung nicht. Stattdessen ist es der von der Funktion zurückgegebene Wert, der dem System mitteilt, welche Änderungen vorgenommen werden sollen.

Typen von Eigenschaftswerten

Der Wertetyp in der zurückgegebenen Abbildung muss mit dem Wertetyp der entsprechenden Metadaten-Eigenschaft übereinstimmen (so wie er an die API „Metadaten aktualisieren“ gesendet werden würde). Ein ungültiger Wert führt zu einer fehlgeschlagenen Eigenschaftsaktualisierung.

Eine Metadaten-Eigenschaft vom Typ „Benutzer“ akzeptiert ein Array von Objekten der Form:

{"id": [userId]}

Eine Workflow-Eigenschaft vom Typ „Benutzer“ enthält ein Array von Objekten, bei denen die Benutzer-ID im Feld „entryId“ steht. Um einen Benutzer aus einer Workflow-Eigenschaft zu einer Metadaten-Eigenschaft hinzuzufügen, muss der Wert daher in das richtige Format umgewandelt werden.

Eine Metadateneigenschaft vom Typ „Benutzer“ akzeptiert nur Benutzer-IDs, keine Team- oder Rollen-IDs. Um eine Workflow-Eigenschaft vom Typ „Benutzer“ auf eine Metadaten-Eigenschaft vom Typ „Benutzer“ anzuwenden, verwenden Sie nur Einträge in der Workflow-Eigenschaft, bei denen es sich um Benutzer handelt – also solche mit einem „entryType“ von 0.

Wenn eine Eigenschaftsaktualisierung aufgrund einer fehlerhaften propertyID oder eines fehlerhaften Werts im zurückgegebenen Objekt fehlschlägt, schlägt die Workflow-Aktion fehl und die Fehler werden für Workflow-Entwickler zur Fehlersuche protokolliert (siehe Workflow-Debugging unten).

Die Aktion schlägt auch fehl, wenn während der Ausführung des FeatureScripts ein Fehler auftritt oder die Form des zurückgegebenen Objekts nicht entspricht, z. B. wenn das zurückgegebene Objekt keine Abbildung der Element-ID in Bezug auf Eigenschaftsaktualisierungen ist.

Wenn die Aktion fehlschlägt, liegt es wahrscheinlich eher an einem Fehler im Workflow-FeatureScript als an einem Systemfehler. In diesem Fall erhalten Sie eine Fehlermeldung, dass Sie (oder Ihre Benutzer) den Workflow-Administrator kontaktieren sollen. Der Workflow-Entwickler kann das Workflow-Audit-Protokoll verwenden, um den Fehler zu identifizieren und zu beheben (siehe Workflow-Audit-Protokollierung unten). Falls erforderlich, kann der Workflow-Entwickler ein Support-Ticket bei Onshape erstellen.

Globale Berechtigung „Workflows verwalten“

Dies ist eine neue globale Berechtigung in Onshape Enterprise, die das Veröffentlichen und Debuggen von angepassten Freigabe-Workflows ermöglicht. Benutzer mit dieser Berechtigung dürfen Workflows veröffentlichen und Freigabe-Kandidaten im Debug-Modus erstellen (siehe Workflow-Debugging unten).

Zyklische Workflows sind nicht erlaubt.

Nur Benutzer mit der globalen Berechtigung „Workflows verwalten“ können Workflows veröffentlichen. Weitere Informationen zu globalen Berechtigungen finden Sie unter Enterprise-Einstellungen — Globale Berechtigungen.

Bearbeiten Sie den benutzerdefinierten Workflow, wie unten beschrieben:

1. Nehmen Sie Änderungen an der JSON-Workflow-Datei vor. Während der Bearbeitung spiegelt das Diagramm auf der rechten Seite die vorgenommenen Änderungen wider.
2. Das Diagramm ist dynamisch und verschiebbar. Passen Sie die Struktur mit dem Mauszeiger an, wenn diese nicht dem gewünschten Workflow entspricht.
3. Wenn Sie mit Ihrer Bearbeitung zufrieden sind und Ihren Workflow für die Verwendung im Enterprise verfügbar machen möchten, klicken Sie auf Veröffentlichen, um das Dialogfenster „Benutzerdefinierten Workflow veröffentlichen“ zu öffnen:

   

   Das Dialogfenster warnt Sie vor Fehlern, die vor der Veröffentlichung behoben werden müssen. Dieses werden oben im Dialogfenster angezeigt:

   

   1. Klicken Sie auf Abbrechen, um das Dialogfenster zu schließen.

   2. Beheben Sie die Fehler.

   3. Klicken Sie erneut auf Veröffentlichen, um das Dialogfenster zu öffnen.

4. Geben Sie einen Namen, eine Beschreibung und einen Workflow-Typ an.

5. Führen Sie in der Dropdown-Liste „Workflow ersetzen“ einen der folgenden Schritte aus:

   1. Wenn dies ein neuer Workflow ist, wählen Sie „Keine“ aus.

   2. Um einen bereits existierenden Workflow zu ersetzen, wählen Sie den Workflow aus, den Sie ersetzen möchten. Die ausgewählten Ersatzfelder „Name“ und „Beschreibung“ werden automatisch ausgefüllt. Sie können die vorhandenen Werte beibehalten oder neue Werte eingeben:

      

6. Klicken Sie auf Veröffentlichen.

Wenn die Veröffentlichung eines Workflows zurückgenommen wird, geschieht Folgendes:

• Der Workflow ist nicht mehr für die Verwendung im Freigabe-Management zur Erstellung neuer Freigabepakete verfügbar.

• Alle Einstellungen, die den entfernten Workflow verwenden, werden auf den Onshape-Standard-Workflow zurückgesetzt.

• Freigegebene oder veraltete Kandidaten, die sich derzeit in dem entfernten Workflow befinden, werden weiter normal funktionieren. Bestehende Freigabepakete und übermittelte Freigabepakete, die den unveröffentlichten Workflow verwenden, bleiben davon unberührt. Sie können weiterhin bestehende Freigabepakete mit dem benutzerdefinierten Workflow öffnen, anzeigen und als obsolet definieren sowie ausstehende Freigaben umwandeln.

Nur Benutzer mit der Berechtigung Workflows zu verwalten (unter „Enterprise-Einstellungen“ > „Globale Berechtigungen“) können die Veröffentlichung eines Workflows zurücknehmen.

Veröffentlichung eines Workflows zurücknehmen:

1. Klicken Sie oben rechts in der Dokument-Symbolleiste auf Ihren Namen oder das Symbol für den Kontonutzer () und wählen Sie „Enterprise-Einstellungen“ > „Freigabe-Management“ aus.

2. Wählen Sie aus der Dropdown-Liste den Freigabe-Workflow aus, der nicht veröffentlicht werden soll.

3. Klicken Sie auf den Link „In Dokument anzeigen“ rechts neben dem Workflow-Dropdown. Das Workflow-Dokument wird in der aktuellen Registerkarte des Browsers geöffnet.

4. Klicken Sie oben im Dokument auf die Schaltfläche Veröffentlichung zurücknehmen.

   

5. Das Dialogfenster „Veröffentlichung von Workflow zurücknehmen“ wird geöffnet. Klicken Sie auf die Schaltfläche Veröffentlichung zurücknehmen.

Wenn Sie die Veröffentlichung eines Standard-Workflows zurücknehmen, wird der Standard-Workflow auf den Onshape-Standard zurückgesetzt.

Ein Benutzer mit der globalen Berechtigung „Workflows verwalten“ kann einen Workflow in der Entwicklung im Debug-Modus testen.

Der Workflow muss zunächst veröffentlicht werden, damit er bei der Freigabe eines Bauteils/einer Baugruppe im Dialogfenster „Freigabe-Workflow auswählen“ verfügbar ist. (Wenn Sie mit dem neuen Workflow zufrieden sind, können Sie zu den Enterprise-Einstellungen zurückkehren und den Workflow aktivieren).

Ein typischer veröffentlichter Workflow verweist auf eine Version des Dokuments, in dem sich die Workflow-Definition befindet (die JSON-Datei). Freigaben, die diesen veröffentlichten Workflow verwenden, folgen dem Workflow, wie er in dieser Version definiert ist. Im Debug-Modus wird stattdessen der Workflow so verwendet, wie er in dem mit der veröffentlichten Version verbundenen Dokument-Arbeitsbereich vorhanden ist. Beachten Sie, dass ein Workflow nur dann im Debug-Modus gestartet wird, wenn es genau einen Arbeitsbereich oberhalb der veröffentlichten Version gibt. Dadurch werden Mehrdeutigkeiten vermieden.

Der Debug-Modus ermöglicht eine schnelle Iteration während der Workflow-Entwicklung. Sollte der Workflow nicht wie erwartet funktionieren, können Sie eine Änderung am Workflow-JSON oder am Feature Studio vornehmen, das von der neuen Aktion im Arbeitsbereich verwendet wird. Durch das sofortige Starten einer neuen Version können Sie (der Workflow-Entwickler) die Auswirkungen sehen, ohne zuerst eine neue Version des Workflows veröffentlichen zu müssen.

Um einen Workflow zu debuggen:

1. Aktivieren Sie das Kontrollkästchen „Debug-Modus“ (wie in der Abbildung oben zu sehen).

2. Klicken Sie auf OK.

   

3. In diesem Dialogfenster können Sie die Überlaufmenü-Schaltfläche () oben rechts und dann Audit-Protokoll anzeigen auswählen, um einen Audit-Trail der Workflow-Objekte und ihrer wichtigen Ereignisse zu sehen (z. B. Erstellung und Umstellung).

4. Sie können auch „Workflow anzeigen“ auswählen, um den Workflow als Diagramm zu sehen. Darin ist der letzte Status hervorgehoben, wie z. B. in dem folgenden Diagramm:

   

Änderungen, die im Arbeitsbereich an einem Workflow im Debug-Modus vorgenommen werden, wirken sich nicht auf eine bereits in Arbeit befindliche Version aus. Ein Debug-Release ist an die Mikroversion des Arbeitsbereichs zum Zeitpunkt der Erstellung gebunden. Um die Ergebnisse der Änderungen zu sehen, müssen Sie eine neue Version erstellen. Durch dieses Verfahren wird verhindert, dass Änderungen an der Workflow-Definition eine in Arbeit befindliche Freigabe zerstören und diese verworfen wird.

Nachdem Sie einen benutzerdefinierten Workflow veröffentlicht haben, können Sie auf Wunsch mehrere aktive Workflows in Ihrem Enterprise aktivieren. Wenn Benutzern mehrere aktive Workflows zur Verfügung stehen, können sie auswählen, welchem Workflow sie bei der Erstellung eines Freigabe-Kandidaten folgen möchten.

Es liegt in der Verantwortung des Administrators, die Benutzer darüber aufzuklären, welche Workflows unter welchen Bedingungen verwendet werden sollen.

Mehrere Workflows aktivieren:

1. Befolgen Sie die obigen Anleitungen, um mehr als einen benutzerdefinierten Workflow zu erstellen und in Onshape zu veröffentlichen.
2. Wählen Sie auf der Seite Freigabe-Management der Enterprise-Einstellungen aus dem Abschnitt „Verwaltete Workflows“ aus, welche benutzerdefinierten Workflows Sie aktivieren möchten, indem Sie das Kästchen „Aktiv“ neben dem jeweiligen Workflow aktivieren:

   

3. Klicken Sie auf das Symbol „Workflow-Vorschau“ (), um ein Dropdown-Menü mit einer Illustration des Workflows zu öffnen. Unterhalb der Illustration finden Sie eine Beschreibung des aktuellen Workflows:

   

4. Stellen Sie sicher, dass Sie auf Freigabe-Einstellungen speichern klicken, um die Änderungen zu speichern, die Sie an den Freigabe-Management-Einstellungen für das Enterprise vorgenommen haben.

Wenn Ihre Benutzer einen Freigabe-Kandidaten erstellen, erhalten sie die Möglichkeit, einen Workflow zu diesem Zeitpunkt (aus der Dropdown-Liste) auszuwählen:

Die Syntax zum Anpassen des Freigabe-Workflows oder des veralteten Workflows wird im Folgenden erläutert. Groß-/Kleinschreibung ist dabei wichtig.

Beachten Sie die folgenden Regeln.

Eigenschaften

Format

• name: string
• propertyId: string
• valueType: string|ENUM
• defaultValue?: any
• usersOnly?: boolesch
• teamsOnly?: boolesch
• enumValues?: list

Beschränkungen

• Eigenschafts-IDs müssen eindeutig sein (und sich von fest programmierten Namen, Beschreibungen oder Kommentar-Eigenschafts-IDs in Onshape unterscheiden).
• valueType muss der Name eines BTMetadataValueType sein (ausschließlich BLOB und OBJECT)
• Wenn der Wertetyp (valueType) ENUM ist, müssen ENUM-Werte (enumValues) angegeben werden, und die Eigenschaft muss einen oder mehrere enumValues enthalten. Jeder der enumValues muss ein Wertelement haben. Das Bezeichunungselement ist optional.
• Wenn der Standardwert (defaultValue) bereitgestellt wird, sollte er mit dem Wertefeld einer der ENUM-Werte (enumValues) übereinstimmen.
• „usersOnly“ und „teamsOnly“ schließen einander aus und sind nur für Eigenschaften des Typs USER gültig.
• „defaultValue“, falls vorhanden, muss mit dem korrekten Typ übereinstimmen, der durch „valueType“ angegeben wird.
  • STRING: string
  • BOOL: boolesch
  • INT: Ganzzahl
  • DOUBLE: dezimal
  • USER: string[]
  • DATE: ISO-Datumszeichenfolge
  • BLOB und OBJECT werden derzeit nicht unterstützt.
• Eigenschaftswerte des Typs USER sind eine Liste von Benutzer, Team und/oder Rollen-IDs.

Status

Format

• name: string
• displayName: string
• approverSourceProperty?: string
• notifierSourceProperty?: string
• entryActions?: Action[]
• exitActions?: Action[]
• editableProperties?: string[]
  • Die Werte können beinhalten:

    • genehmigende Personen

    • Beobachter

• requiredProperties?: string[]
• requiredItemProperties?: string[]

Beschränkungen

• Namen müssen eindeutig sein.
• „approverSourceProperty“ und „notifierSourceProperty“, falls vorhanden, müssen die Eigenschafts-IDs des Workflows sein und auf die Eigenschaften des Typs USER verweisen.
• Ein Status darf höchstens eine bestimmte Eigenschaft als Genehmiger verwenden.
• Eine beliebige Anzahl von Status kann eine bestimmte Eigenschaft als benachrichtigendes Element verwenden.
• „editableProperties“ und „requiredProperties“ müssen Eigenschafts-IDs im gleichen Workflow sein.
• „requiredItemProperties“ müssen gültige Metadaten-Eigenschafts-IDs für Ihre Company sein (in Onshape integrierte Eigenschaften oder benutzerdefinierte Eigenschaften, ausgenommen berechnete Eigenschaften).

Detaillierte Informationen zu IDs finden Sie unter Wissenswertes über Projektrollen, Berechtigungspläne und deren Verwaltung.

Umstellungen

Format

• name: string
• displayName: string
• type: string
• sourceState: string
• targetState: string
• uiHint?: string (default: "primary")
• actions?: Action[]
• requiredProperties?: string[]

Beschränkungen

• Namen müssen eindeutig sein.
• Der Typ muss entweder „GENEHMIGEN“, „ABLEHNEN“ oder „SENDEN“ sein.
• „sourceState“ und „targetState“ müssen zwei unterschiedliche Status im Workflow sein.
• Es darf höchstens ein Übergang vom Typ APPROVE aus einem beliebigen Quellstatus erfolgen.
• Für eine Umstellung des Typs APPROVE muss „sourceState“ die Eigenschaft „approverSourceProperty“ aufweisen.
• „uiHint“, falls vorhanden, muss entweder „primary“ „success“ oder „danger“ sein. (Dies sind die Farben der Felder und anderer Elemente im Freigabe-Dialogfenster, die von Onshape festgelegt sind und nicht geändert werden können.)

Umstellungstypen

Einreichen

• Führt verschiedene „Initialisierungen“ an der Freigabe nach der Einrichtung und während des Übergangs in den Workflow durch, wie z. B. die Erstellung von Miniaturen für konfigurierte Bauteile in der Freigabe, die Verbindung von verknüpften Dokument-/Versions-IDs usw.
• Nur der Ersteller der Freigabe darf SENDEN-Übergänge ausführen.
• Umstellungen aus dem ursprünglichen Status heraus sollten Senden-Aktionen sein.
• Erfolgt durch das „Senden“ keine anfängliche Umstellung, hat keine besonderen Auswirkungen.

Genehmigen

• Kennzeichnet den Benutzer als Erteiler der Genehmigung (färbt das Token im Freigabe-Dialogfenster grün).
• Wenn die Company-Richtlinien auf Alle Genehmiger erforderlich eingestellt sind, wird die Umstellung erst durchgeführt, wenn alle Genehmiger die Genehmigung erteilt haben.
• Erzeugt Baugruppen-/Zeichnungsinhalts-Referenzen für Objekte.
• Nur eine solche Umstellung aus einem Status heraus ist zulässig.
• Nur ein Genehmiger des aktuellen Status (oder ein Administrator) darf etwas genehmigen.

Ablehnen

• Kennzeichnet den Benutzer als Ablehner (färbt das Token im Freigabe-Dialogfenster rot).
• Nur ein Genehmiger des aktuellen Status (oder ein Administrator) darf etwas ablehnen.

Aktionen

Format

• name: string
• params?: {[key: string]: any}

Beschränkungen

• Der Name muss mit einem unserer vordefinierten Aktionsnamen übereinstimmen (siehe unten unter Zulässige Aktionen).
• Einige Aktionen sind möglicherweise nur für Status oder Umstellungen zulässig und können Beschränkungen hinsichtlich der Reihenfolge haben.

Zulässige Aktionen

• sendEmailNotifications: Senden Sie E-Mail-Benachrichtigungen für eine Umstellung (einschließlich mobiler Push-Benachrichtigungen).
  • Erlaubt für: nur Umstellungen
  • Parameter: keine
• sendUserNotifications: Senden Sie Benutzerbenachrichtigungen für eine Umstellung.
  • Erlaubt für: nur Umstellungen
  • Parameter: keine
• markItemsPending: Ändern Sie den Metadatenstatus aller Objekte in der Freigabe auf „Ausstehend“.
  • Erlaubt für: Status oder Umstellungen
  • Parameter: keine
  • Ist in veralteten Workflows nicht erlaubt.
  • In Freigabe-Workflows, nicht möglich nach der Anwendung von „markItemsReleased“ oder „markItemsRejected“.
• markItemsRejected: Ändern Sie den Metadatenstatus aller Objekte in der Freigabe auf „Abgelehnt“.
  • Erlaubt für: Status oder Umstellungen
  • Parameter: keine
  • Ist in veralteten Workflows nicht erlaubt.
  • In Freigabe-Workflows, nicht möglich nach der Anwendung von „markItemsReleased“ oder vor „markItemsPending“
• releaseItems: Ändern Sie den Metadatenstatus aller Objekte in der Freigabe auf „Freigegeben“ und erstellen Sie für diese Objekte Revisionen (automatische Festlegung anderer Revisionen als veraltet, falls in der Unternehmensrichtlinie festgelegt).

  Erlaubt für: Status oder Umstellungen

  Parameter: keine

  Ist in veralteten Workflows nicht erlaubt.

• obsoleteItems: Ändern Sie den Metadatenstatus aller Objekte im Paket auf „Veraltet“ und definieren Sie deren entsprechende Revisionen als obsolet.
  • Erlaubt für: Status oder Umstellungen
  • Parameter: keine
  • Ist in einem Freigabe-Workflow nicht erlaubt.
• updateItemPropertiesFromFeatureScript: Verwenden Sie dies, um ein FeatureScript-Feature als Umstellungsaktion oder als Eingangs- oder Ausgangsaktion für einen Status zu verwenden.
  • Erlaubt für: Status oder Umstellungen
  • Parameter: Abbildung (ein einziges Argument mit diesem Typ)

Bei der Definition eines benutzerdefinierten Workflows können Sie einen Abschnitt „Optionen“ einfügen, welcher so gestaltet werden kann, dass bestimmte Company-Freigabe-Einstellungen überschrieben werden, die auf der Seite Enterprise-Einstellungen > Freigabe-Management definiert sind. Die Optionen zum Überschreiben werden im Folgenden erläutert:

"options": {

„revisionSchemeId“: Zeichenkette,

„requireApprover“: boolesch,

„requireAllApprovers“: boolesch,

„disallowCreatorAsApprover“: boolesch,

„requireNote“: boolesch,

„autoObsolete“: boolesch,

„errorOnFeatureListErrors“: boolesch,

„errorOnRolledBack“: boolesch,

„errorOnAssemblyErrors“: boolesch,

„errorOnAssemblyRefsOutOfDate“: boolesch,

„errorOnDrawingOutOfDate“: boolesch,

„errorOnPartNumberPending“: boolesch,

„errorOnPendingTask“: boolesch,

„nameOverride“: string, (überschreibt die Bezeichnung des Freigabe-Namens oder des Obseletionsnamens im Freigabe-Dialogfenster)

„descriptionOverride“: (überschreibt die Bezeichnung der Versionshinweise bzw. der Obseletionshinweise im Freigabe-Dialogfenster)

}

Dieser Abschnitt und alle Felder sind optional. Sie können eine beliebige Teilmenge auswählen, mit der Sie eine Company-Einstellung außer Kraft setzen wollen. Alle Felder, die nicht im Code enthalten sind, werden standardmäßig auf die Spezifikation in den Enterprise-Einstellungen gesetzt.

Die Revisionsplan-ID kann aus dem schreibgeschützten Textfeld auf der Seite Enterprise-Einstellungen > Freigabe-Management abgerufen werden:

Alle Workflow-Objekte erstellen einen Audit-Trail für wichtige Ereignisse während ihrer Lebensdauer, z. B. Erstellung und Umstellung. Dieses Protokoll kann abgerufen werden mit:

GET /api/workflow/obj/<object id>/auditlog

Sie können die Ausgabe dieses Aufrufs über einen Link in der Freigabe anzeigen, um Probleme zu untersuchen und zu beheben.

Die Antwort des Audit-Protokolls enthält grundlegende Informationen über den Objekt-Workflow (einschließlich der veröffentlichten Workflow-Version und ob es sich um einen Debug-Modus-Workflow handelt) sowie alle seine protokollierten Ereignisse.

Jeder Protokolleintrag enthält:

• Ein Zeitstempel

• Ein Typ (dargestellt durch eine ganze Zahl, die eine Ordnungszahl von BTWorkflowAuditEntryType ist)

• Der Workflow-Status/Übergang/die Aktion zum Zeitpunkt des Ereignisses.

Es gibt auch einige andere Felder für zusätzliche ereignistypspezifische Informationen, falls zutreffend.

Es gibt folgende Arten von Audit-Ereignissen:

• Objekt erstellt: erstes Ereignis, das für ein Objekt protokolliert wird, wenn es erstellt wird.

• Objekt verworfen: wenn die spezielle Aktion „Verwerfen“ für das Objekt ausgeführt wird.

• Objekt gelöscht: wenn das Objekt entfernt wurde, in der Regel, weil es alt genug ist, um vom Bereinigungs-Server erfasst zu werden (das Audit-Protokoll für ein gelöschtes Objekt wird nicht gelöscht).

• Eigenschaften aktualisiert: wenn Workflow-Eigenschaften des Objekts geändert werden. Dies gilt für Eigenschaften auf Paketebene für ein Freigabe-Paket (zum Beispiel), nicht jedoch für Metadateneigenschaften für einzelne Objekte.

  • Dazu gehören die Eigenschafts-IDs (aus der Workflow-Definition), die geändert wurden, einschließlich ihrer alten und neuen Werte.

• Kommentar hinzugefügt: enthält die ID des neu hinzugefügten Kommentars.

• Benutzergenehmigt: wenn ein Benutzer die Genehmigungsaktion für den aktuellen Status durchführt. Je nach den Freigabe-Einstellungen des Unternehmens kann dies von einer Umstellung begleitet sein oder nicht.

  • Dazu gehören die Benutzer-, Team- oder Rollen-IDs in der Liste der Genehmigenden, für die die Aktion durchgeführt wurde, d. h. in deren Namen der Benutzer genehmigt hat.

• Von Benutzer abgelehnt: wenn ein Benutzer die Ablehnungsaktion für den aktuellen Status ausführt.

  • Dazu gehören die Benutzer-/Team-/Rollen-IDs in der Liste der Genehmigenden, für die die Aktion durchgeführt wurde (d. h. in deren Namen der Benutzer abgelehnt hat).

• Umstellung gestartet

• Umwandlung abgeschlossen

• Umstellung fehlgeschlagen: Dazu gehört gegebenenfalls eine Fehlermeldung oder ein Support-Code.

• Aktion gestartet

• Aktion abgeschlossen

• Aktion fehlgeschlagen: Dazu gehört gegebenenfalls eine Fehlermeldung oder ein Support-Code.

• FeatureScript ausgeführt: Dies schließt alle Konsolenausgaben der FeatureScript-Ausführung ein.

  • Dazu gehören alle Meldungen, die von der FeatureScript-Ausführung zurückgegeben werden (einschließlich einer Ausnahme, falls eine aufgetreten ist).

  • Beinhaltet den von der FeatureScript-Funktion zurückgegebenen Wert.

• Aktualisierungen von Objekt-Metadaten fehlgeschlagen: Wenn eine Anforderung zur Aktualisierung der Objekt-Metadaten eines Freigabe-Pakets während einer Umstellung fehlschlägt.

  • Dazu gehören die IDs der fehlgeschlagenen Metadateneigenschaften, die Metadaten-Hrefs der fehlgeschlagenen Objekte und eine Fehlermeldung.

  • Führt in der Regel zum Scheitern der Umstellung, es sei denn, dies geschieht während einer FeatureScript-Aktion. Integrierte Aktionen müssen erfolgreich sein, aber das Festlegen zusätzlicher Eigenschaften durch FeatureScript kann fehlschlagen, wenn eine Fortsetzung der Umstellung erlaubt ist.