In diesem Blogbeitrag möchte ich ein wenig mit in-STEP BLUE puzzeln. Was lustig klingt, ist eine durchaus spannende Herausforderung! Stellen wir uns vor, eine Fachabteilung bekommt über einen Antrag einen Arbeitsauftrag. Der Antrag ist allgemein gehalten und muss von der Fachabteilung nach ihren Erfordernissen unterteilt werden, nämlich in Bauteile und Varianten.
Rahmenbedingungen für das Puzzle
Die Antragsnummer kommt aus einem Projekt und wird dort bei weiteren Anträgen hochgezählt:
Die Fachabteilung benötigt nun nachfolgendes Namens-Schema:
Bauteil:
Variante:
Für das Fachabteilungs-Projekt wird nun der Antrag in Bauteile aufgeteilt (01, 02, …), wobei für jedes Bauteil mindestens eine Variante (00, 01, …) benötigt wird. Jedes Bauteil erhält eine individuelle (gepuzzelte) Benennung.
So sieht die Lösung in in-STEP BLUE aus, inkl. generierter Standarddokumente:
Die Anforderungen an das Puzzle
Wie muss in-STEP BLUE jetzt konfiguriert werden, um folgende Anforderungen zu erfüllen:
a) Jedes Bauteil, das (zusätzlich) angelegt wird, folgt in der Benennung dem oben gezeigten Schema und zählt die Bauteilnummer hoch, beginnend bei 01.
b) Jede Variante, die (zusätzlich) angelegt wird, folgt in der Benennung dem oben gezeigten Schema und zählt pro Bauteil die Varianten hoch, beginnend bei 00.
c) Die Benennung wird immer an das Ende gestellt.
d) Bei (versehentlicher) händischer Umbenennung muss über das Kontextmenü der Standardname wiederhergestellt werden können.
e) Das automatische Umbenennen muss in einzelnen Fällen verhindert werden können.
Die Vorbereitungen: Auf die Plätze, fertig, los(gepuzzelt)
Neue (Puzzle-)Eigenschaften
Zum Hochzählen der einzelnen Puzzlebausteine werden diese Eigenschaftstypen definiert:
Warum jeweils einmal ein alphanumerischer und ein numerischer Wert benötigt wird, erkläre ich später. Außerdem werden benötigt:
Für das neu Anlegen von Bauteilen werden diese Eigenschaften gebraucht:
Und für das Anlegen von Dokumenten zur Variante mindestens:
Der oberste Knoten wird über einen Command-Server Befehl für Produkte (CoreProcess, systemweit) erstellt. Dabei wird der Name gebildet aus: %ProductName%-%Projektname%. Mit dem Anlegen des Produktes schreibt die Zustandsaktion für den Startzustand folgende Werte:
| (1) | DefaultProductName | ={is_ProductName}, RegEx: ^(.{0,14}).* → $1 |
Puzzleteil 1 |
| (2) | CounterBG_NUM | =1 | |
| (3) | CounterBG | ={isp_PRODUCTREVISION.CounterBG_NUM}, RegEx: ^([0]?)([\d])([\d]?)$ → 0$2$3 |
Puzzleteil 2 |
Der Name des obersten Knoten wird über eine Formel (siehe oben) gebildet. Um die Antragsnummer ohne den Projektnamen zu erhalten und in (1) zu speichern, muss mit Hilfe von RegEx der Ausdruck auf 14 Zeichen gekürzt werden (= Puzzleteil 1). Wie man RegEx in in-STEP BLUE nutzen kann, habe ich bereits in den Blogbeiträgen: “Drei Fälle für RegEx” und “RegEx Umbenennungen” erklärt.
(Mögliche Alternative: Der Antrag aus dem Projekt schreibt schon die Antragsnummer in die eigene Eigenschaft „DefaultProductName“, die dann vom Command-Server beim Anlegen des Produktes übergeben wird. In meiner Systemumgebung ist dafür der Aufwand zu hoch, weil diese Eigenschaft in zahllosen bestehenden Projekten fehlt und somit nicht in einem vertretbaren Rahmen nachträglich eingebaut werden kann.)
Der numerische Zähler für die Bauteile (2) wird auf 1 gesetzt und mit Hilfe von RegEx als Alphanumerischer Wert auf 2 Stellen in CounterBG (3) geschrieben (= Puzzleteil 2). Zum späteren Hochzählen wird der Wert numerisch benötigt (mittels Rechnung: Wert, neu = Wert+1), zum Puzzeln muss er zweistellig sein, also hilft hier der Alphanumerische Wert mit RegEx.
Bauteil-Puzzle
Die Bauteile und jeweils die Variante 0 werden durch einen Command-Server Befehl für Produkte (CoreProcess) erstellt. Dabei werden Metadaten vorher mit einem Formular abgefangen und der Command-Server-Befehl wird dann mit der Rückgabe des Formulars über einen Zustandsübergang ausgelöst. Im Detail sieht das dann so aus:
„Neues Bauteil anlegen“ (Command-Server für Produkte (CoreProcess) – Eigenschaften bearbeiten):
Zuerst sind die Pflichtfelder für das neue Bauteil auszufüllen (für unser Blog-Thema wird „Benennung Bauteil“ für das Puzzle benötigt = Puzzleteil 3), danach steht der Button „Zurückgeben und Ereignis auslösen“ zur Verfügung. Für den Fall, dass es nur ein Bauteil gibt und dieses identisch mit dem Antrag ist, kann der Schalter „Werte/Benennung wie Projekt“ gesetzt werden und die Pflichtfelder grauen aus (ich liebe die Möglichkeiten der Formularkonfigurationen 😀):
Die Eigenschaften, die abgefragt werden, wurden weiter oben definiert. Wichtig für unser Puzzle: „Neue Benennung“ (Alphanumerisch, K1), diese Eigenschaft wird dann in die Eigenschaft „Benennung“ überführt, wird aber auch als Puzzleteil 3 benötigt.
| (4) | Benennung | ={isp_PRODUCTREVISION.Neue Benennung} | Puzzleteil 3 |
Der Übergang, der beim Schließen des Formulars angesprochen wird, ruft nun einen Command-Server-Befehl zum Produktanlegen auf:
Und hier wird bei der Namensvorlage schon das erste Mal gepuzzelt:
%DefaultProductName%-%CounterBG%-%Neue Benennung%
= Puzzleteil1 Puzzleteil2 Puzzleteil3
Nach der Anlage eines (neuen) Bauteils empfängt noch die Quelle das Ereignis „BG Counter hochzählen (automatisch)“, was unser Puzzleteil 2 zu Beginn von 01 auf 02 hochzählt, vorbereitet für das nächste Bauteil, falls benötigt:
| (2a) | CounterBG_NUM | ={isp_PRODUCTREVISION.CounterBG_NUM}+1 | |
| (3) | CounterBG | ={isp_PRODUCTREVISION.CounterBG_NUM}, RegEx: ^([0]?)([\d])([\d]?)$ → 0$2$3 |
Puzzleteil 2 |
Varianten-Puzzle
Das abgeleitete Produkt (also das Bauteil) empfängt das Ereignis (Aktivität anlegen (automatisch)). Auch wenn diese Benennung historisch bedingt ist und tatsächlich eine Aktivität anlegt, wird zusätzlich auch ein Befehl ausgelöst, der über den Command-Server die Variante 0 anlegt.
Dazu muss vorher mit dem Erreichen des Startzustandes des Bauteils noch der Zähler für die Varianten gesetzt werden:
| (5) | CounterVAR_NUM | =0 | |
| (6) | CounterVAR | ={isp_PRODUCTREVISION.CounterVAR_NUM}, RegEx: ^([0]?)([\d])([\d]?)$ → 0$2$3 |
Puzzleteil 4 |
Auch hier gilt wieder: Für das Hochzählen wird der numerische Wert und für das Puzzeln der Alphanumerische Wert benötigt.
Und nun wird bei der Namensvorlage das zweite Mal gepuzzelt:
%DefaultProductName%-%CounterBG%-%CounterVAR%-%Benennung%
= Puzzleteil1 Puzzleteil2 Puzzleteil4 Puzzleteil3
Nach der Anlage einer (neuen) Variante empfängt noch die Quelle (das Bauteil) das Ereignis „VAR Counter hochzählen (automatisch)“, was unser Puzzleteil 4 zu Beginn von 00 auf 01 hochzählt und vorbereitet für die nächste Variante, falls benötigt:
| (2a) | CounterVAR_NUM | ={isp_PRODUCTREVISION.CounterVAR_NUM}+1 | |
| (3) | CounterVAR | ={isp_PRODUCTREVISION.CounterVAR_NUM}, RegEx: ^([0]?)([\d])([\d]?)$ → 0$2$3 |
Puzzleteil 4 |
Das abgeleitete Produkt (also die Variante) empfängt das Ereignis (V2_Start_Dummy_Dokumente_erstellen). Dieses Ereignis ruft zwei Command-Server-Befehle auf, die jeweils ein leeres Pflichtdokument anlegen.
Schauen wir uns nun einmal die Werte (unserer Puzzleteile) bei unserem Beispiel in in-STEP BLUE an:
Wichtig zum Puzzeln auf Varianten-Ebene ist es, dass die gültigen Zähler zum Puzzeln mitgegeben werden. Das geschieht im Command-Server, wenn die Eigenschaften kopiert werden:
Puzzeln auf Dokumentenebene
Und zu guter Letzt werden Dokumente (zum Beispiel Berichte, Notizen, etc.) an die Varianten gehängt, deren Namen ebenfalls gepuzzelt werden müssen, inkl. einer Bezeichnung des Dokumententyps. Hier ein Beispiel für eine sogenannte Notiz, die auch wieder über einen Command-Server-Befehl erstellt wird:
Der %ProductName% ist der Name der Variante, also = %DefaultProductName%-%CounterBG%-%CounterVAR%-%Benennung%. Somit wird der Name zusammengesetzt aus: Puzzleteil 1 + Puzzleteil 2 + Puzzleteil 4 + Puzzleteil 3 + ‚N‘ + Puzzleteil 5, wobei Puzzleteil 5 ein neuer Counter ist, der die in dieser Variante angelegten Notizen hochzählt (er ist nur numerisch, da er nicht eine 0 vorgestellt bekommen muss).
Puzzle-Korrekturen: erlauben und verhindern
Bis hierhin wurde schon viel erreicht! Wir haben reichlich Puzzleteile, mit denen wir die richtigen Namen an der richtigen Stelle zusammenbauen können. Aber zwei Anforderungen sind noch nicht erfüllt: (d) Händisch umbenannte Produkte müssen wieder „zurückgepuzzelt“ werden können und (e) das „Zurückpuzzeln“ muss auch für einzelne Produkte verhindert werden können.
Für die Anforderung (d) sollte ein Zustandsübergang mit der Aktion „Name kopieren/umbenennen“ ausreichen, die notwendigen Puzzleteile sind bekannt (siehe Beispiel aus in-STEP BLUE oben):
Dieser Übergang kann am höchsten Knoten (aber auch weiter unten) ausgelöst werden und wird (in unserer Konfiguration über die Referenzen) „nach unten“ durchgereicht.
Während für die Hauptprodukte (Baugruppe, Variante) eine manuelle Umbenennung nicht erwünscht ist, ist das Ändern des Namens bei Dokumenten, die an der Variante hängen, möglich und erlaubt. Deshalb müssen diese Änderungen bei Bedarf geschützt werden können (e).
Um Anforderung (e) erfüllen zu können, wird eine neue Boolesche Eigenschaft benötigt:
Vor der Umbenennung eines Produktes wird eine Bedingung gesetzt:
Um den Booleschen Wert zu setzen, kann jetzt wieder ein Formular definiert werden (Command-Server für Produkte (CoreProcess): Eigenschaften bearbeiten), mit dem komfortabel der Wert gesetzt werden kann:
Hinweis: In unserem Beispiel ganz oben ist zu erkennen, dass sich die Benennungen der Variante 1 (Benennung = Bauteil A – Stahl) und der Variante 2 (Benennung = Bauteil A – Alu) unterscheiden. Die Anpassungen wurden nachträglich händisch geändert und durch die Umbenennungsfunktion an die referenzierten Elemente nach unten weitergereicht. Auch wenn viele Automatismen implementiert sind, ist es schwierig, jeden Use Case abzubilden bzw. abzufangen: Geschütze Dokumente erhalten nun nicht die neue Benennung. Änderungen auf Bauteil-Ebene, die wieder durchgereicht werden sollen, würden händisch geänderte Benennungen überschreiben. Deshalb ist mit den Nutzern dieser Funktionalitäten genau abzustimmen, welche Anwendungsfälle gehäuft auftreten und somit von Automatismen profitieren und welche Anwendungsfälle eher selten sind.
Mein Puzzle-Fazit
Mit in-STEP BLUE kann man puzzeln! Auch hier hilft wieder RegEx, damit bestimmte Puzzleteile in Form gebracht werden. Derartige Konfigurationen helfen den Benutzern, Zeit zu sparen und Fehler zu vermeiden, Produktbenennungen können einem definierten Schema automatisiert folgen.