Es gibt viele gute Gründe, um aus einer in in-STEP BLUE abgelegten Datei eine PDF-Datei zu erstellen. So möchte man beispielsweise im Austausch mit seinem Kunden keine veränderbare Word-Datei versenden, sondern den Arbeitsstand in einer sicheren PDF-Datei dokumentieren. Im von VOITH aktuell genutzten in-STEP BLUE Release (6.7.2) gibt es dafür diese Zustandsautomaten-Aktionen:
Datei in ein anderes Format konvertieren
Unterstützt wird nur MS Excel als Quellprodukt. Die generierte PDF-Datei kann auf einem Server-Pfad abgelegt werden oder innerhalb von in-STEP BLUE im Ordner der Quelldatei („gemeinsames Vaterprodukt“).
Word-Datei in ein anderes Format exportieren (asynchron)
Bei dieser Aktion wird nur MS Word als Quellprodukt unterstützt. Die generierte PDF-Datei kann auch hier auf einem Server-Pfad abgelegt werden oder innerhalb von in-STEP BLUE im Ordner der Quelldatei („gemeinsames Vaterprodukt“). Nach Abschluss der asynchronen Ausführung kann ein Ereignis an die Quelle gesendet werden. Da aber keine Verbindung zu der generierten PDF-Datei besteht, können dort keine Aktionen ausgelöst werden.
Da fehlte noch was
Mit den zuvor gezeigten Aktionen hörten die Konfigurationsmöglichkeiten und damit weitere Möglichkeiten zur Automatisierung bisher auf. Die abgelegte PDF-Datei war ein freies Produkt (also ohne Produkttyp) und folgte somit dem Zustandsautomat für freie Produkte – völlig losgelöst von der jeweiligen Quelle. Ein individuell auf die Erstellung von PDF-Dateien abgestimmter Zustandsautomat mit spezifischen Zuständen war nicht möglich. Schön war aber schon, dass jede weitere PDF-Datei, die aus einer Quelle generiert wurde, über eine namensgleich bestehende Datei gestapelt wurde, das heißt, dass die PDF-Datei eine Historie bekam.
Folgende zusätzliche Anforderungen wurden bei uns für umfangreichere Konfigurationen benötigt:
- Weitere Quellen und alle Quellen in einer Aktion: MS Word, MS PowerPoint, MS Excel
- Zuweisung eines Produkttypen
- Zuweisung einer Referenz (Eigenschaftstyp: Produkt) (Quelle zeigt auf PDF)
- Ereignis wird am Quellprodukt ausgelöst nach der Erstellung (z.B. werden Eigenschaften von der Quelle an das PDF über die Referenz übertragen)
- Ereignis wird am Ziel (PDF) ausgelöst durch Benachrichtigung über die Quelle über die Referenz (z.B. „Bearbeiter benachrichtigen“ oder „Name kopieren/umbenennen“, …)
Da geht jetzt viel mehr
Ab Version 6.7.4 von in-STEP BLUE sieht der Dialog für die Aktion so aus:
In der nachfolgenden Tabelle kann man die neue Vielfalt der Einstellungsmöglichkeiten erkennen:
|
dem Namen der Datei |
dem Namen der Datei
der PID der Datei der ID der Datei diese drei Auswahlmöglichkeiten gab es auch in der ursprünglichen Version |
| unterhalb des gemeinsamen Vaterprodukts | unterhalb des gemeinsamen Vaterprodukts
auf dem Server unter … in dem Ordner, der in der Eigenschaft ‘…’ referenziert wird. Neu: Die PDF-Datei wird in einem Ordner abgelegt, der über eine Eigenschaft definiert wird. Anwendungsfall: Es gibt einen gemeinsamen Ordner, in dem alle PDF abgelegt werden sollen. im Standardverzeichnis des Produkttyps gespeichert. Neu: Die PDF wird im Standardordner des Produkttyps abgelegt, der ihr zugewiesen wird (siehe übernächste Tabellenzeile) |
| Es wird das Ereignis “…” am Ende der Generierung an die Datei gesendet | Neu: Mit Abschluss der Generierung der PDF-Datei wird am Quelldokument ein Ereignis ausgelöst. So kann zum Beispiel über die Referenz zur PDF-Datei (siehe übernächste Tabellenzeile) diese angesprochen werden. |
| Die Datei erhält den Produkttyp “…” | Neu: Die PDF-Datei erhält einen definierten Produkttyp. Dadurch wird es möglich, einen produkttypspezifischen Zustandsautomaten zu erstellen, der die generierten PDF-Dateien verwaltet. |
| Eine Referenz zu der Datei wird im Quellprodukt in der Eigenschaft “…” hinterlegt |
Neu: Im Quellprodukt, aus dem die PDF-Datei erstellt wird, kann in den Eigenschaften eine Referenz (vom Typ „Produkt“) hinterlegt werden. Dadurch ist es über ein Ereignis möglich, die generierte PDF-Datei anzusprechen und weitere Aktionen auszulösen oder auch zum Beispiel Eigenschaften der Quelldatei zu kopieren. |
Konfiguration – ein Beispiel aus der Praxis
Anforderungen
Folgende Anforderungen sollen in dieser Beispielkonfiguration umgesetzt werden:
- Die Version des Originals soll in eine gesonderte Eigenschaft der PDF-Datei geschrieben werden, um schnell erkennen zu können, aus welcher Version des Originals diese PDF-Version erstellt wurde.
- Die Eigenschaften „Sprache“ und „Kategorie“ sollen an die zu generierende PDF-Datei übergeben werden.
- Das PDF soll automatisch nach der Generierung in einen finalen Zustand versetzt werden.
- Eine neue, finale Version des Quelldokuments soll die PDF-Datei wieder in einen Bearbeitungszustand versetzen.
- Die Version einer PDF-Datei soll ganzzahlig hochgezählt werden.
Voraussetzungen
Um alle Anforderungen erfüllen zu können, wird ein Produkttyp benötigt, der bei der PDF-Generierung verwendet werden kann. Dabei ist im Vorfeld zu überlegen, wo z.B. die generierte Datei erzeugt werden soll. Ist ein eigener Ordner vorgesehen, der alle PDF-Dateien sammeln soll, so macht es Sinn, einen für PDF exklusiven Produkttypen inklusive Zustandsautomat zu erstellen. Dieser kann in der Regel sehr schlank gehalten werden. In diesem Beispiel liegt aber eine komplexe Prozessstruktur vor. Es sind unzählige Ordner für die Projektabwicklung definiert und es ist gewünscht, dass eine PDF-Datei immer parallel zum Quelldokument liegt, d.h. im gleichen Ordner. Dabei ist schon für jeden Ordner ein enthaltener Dokument-Standard als Referenz-Produkttyp definiert (das Original liegt in einem gesonderten Definitionsbereich):
Um den Aufwand möglichst gering zu halten, ist es in diesem Beispiel sinnvoll, dem PDF auch den Produkttyp „Dokument – Standard“ zu geben. Daraus folgt, dass der Zustandsautomat „für STANDARD-PRODUKTTYPEN“ erweitert werden muss.
Für die Erfüllung der ersten Anforderung wird eine alphanumerische Eigenschaft benötigt, in welche die Versionsnummer geschrieben werden kann. Ich nenne sie einfach „revision“. Dann definiere ich eine Aktion, die immer, wenn das Produkt zurückgegeben wird (also eine neue Produktversion erzeugt wird) diese in die Eigenschaft schreibt:
Da in Sichten auch Produkt-Eigenschaften editiert werden können, dabei eine neue Version entstehen kann aber keine Produkt-Zurückgeben-Aktion ausgelöst wird, muss auch der Übergang „Eigenschaften geändert“ konfiguriert werden:
Für die Anforderungen 2-5 (siehe vorheriges Kapitel) wird eine Eigenschaft vom Typ „Produkt“ benötigt. Der Einfachheit halber wird sie „PDF“ genannt, der Name der Rückrichtung ist „Original“.
Konfiguration des Zustandsautomaten
Im ersten Schritt wird ein neues Ereignis für den Übergang definiert (→ PDF aus dieser Datei erstellen (WORD, EXCEL, PP).
Der Übergang für dieses Beispiel sieht dann so aus:
Ereignis: → PDF aus dieser Datei erstellen (WORD, EXCEL, PP)
| 1 | Bedingung für die Erstellung der PDF: Die Quelldatei darf nicht ausgeliehen sein. In diesem Beispiel darf eine PDF-Datei aus jedem Zustand heraus erstellt werden. Vorstellbar ist, dass der Zustand der Quelle auch ein Endzustand sein muss. |
| 2 | In dieser Konfiguration soll der Name der PDF identisch sein mit dem Namen der Quelle. |
| 3 | Die PDF wird unterhalb des gemeinsamen Vaterproduktes abgelegt. |
| 4 | Als Produkttyp wird „Dokument-Standard“ ausgewählt (siehe oben). |
| 5 | In diesem Beispiel wird kein Ereignis an das Quellprodukt gesendet. Es ist aber möglich, dass hier ein Quellproduktübergang definiert wird, der den Punkten (7) und (8) entspricht. Ein typisches Ereignis wäre hier zum Beispiel ein Übergang von „freigegeben“ auf „archiviert“, nachdem das PDF erstellt wurde. |
| 6 | Als Referenzeigenschaft (vom Typ „Produkt“) wird die Eigenschaft „PDF“ ausgewählt. |
| 7 | Die definierten Eigenschaften werden in ihre Zieleigenschaft kopiert:
|
| 8 | Die PDF wird in ihren Endzustand versetzt (hier: „zur Information“). Dabei wird ganzzahlig hochgezählt:
|
Abschließend ist eine Benachrichtigung zu konfigurieren für den Fall, dass ein Quell-Produkt in einen Endzustand gesetzt wird. Dabei wird eine mögliche PDF-Datei versioniert und von einem Endzustand in einen bearbeitbaren Zustand versetzt:
Dadurch wird sofort über den Zustand der PDF-Datei erkennbar, dass eine neue Version erstellt werden muss.
Somit wurden alle oben genannten fünf Anforderungen erfüllt.
Das war doch bis hier gar nicht so aufwendig. Mit den neuen, erweiterten Möglichkeiten ist das schnell umgesetzt. Sie können jetzt gleich loskonfigurieren und einfach einmal ausprobieren, ob Sie die Anforderungen Ihres Teams umsetzen können. Im nachfolgenden Kapitel zeige ich noch ein paar ergänzende Beispiele und greife ein wenig tiefer in die Konfigurationstrickkiste. Neugierig? Dann einfach weiterlesen!
Ein Blick in die Tiefe
Task oder nicht Task, das ist hier die Frage
Es gibt mit unter sehr große Quelldateien, bei denen die PDF-Generierung mehr Zeit benötigt. Um Wartezeiten zu vermeiden, kann die eigentliche PDF-Generierung als Task abgearbeitet werden, d.h. der oben genannte und beschriebene Zustandsübergang wird in eine Aktion „Task anlegen“ verschoben:
Das Ereignis „→ PDF aus dieser Datei erstellen (WORD, EXCEL PP)“ wird unsichtbar gestellt und der Übergang (Ereignis), der den Task aufruft, neu definiert.
Es kann also schon weitergearbeitet werden, während der Server damit beschäftigt ist, die PDF-Datei zu erstellen.
Außerdem ist es möglich, über einen Task (diesmal aufgerufen über die Task-Verwaltung) einmal pro festen Zeitraum (z.B. pro Woche) aus Dateien eines Ordners jeweils die PDF-Dateien automatisch zu generieren. Dabei wird für das Vaterprodukt (also den Ordner mit eigenem Zustandsautomat) ein Zustandsübergang („Automatische PDF-Erstellung anstoßen“) definiert, der an alle seine Kinder das Ereignis sendet „→ PDF aus dieser Datei erstellen (WORD, EXCEL, PP)“.
In der Task-Verwaltung sieht das dann so aus:
PDF mit jeder finalen Version
Wenn gefordert ist, dass mit Freigabe einer Quelle immer automatisch eine PDF-Datei erzeugt und abgelegt wird, kann die PDF-Erstellung auch durch Erreichen des Endzustandes der Quelldatei angestoßen werden.
PDF-Lesezeichen erleichtern die Navigation
Ein weiterer Anwenderwunsch wurde auch erfüllt: das Inhaltsverzeichnis einer Worddatei wird auch als PDF-Lesezeichen im linken Menübereich einer PDF-Datei erstellt. Dieses Feature wurde ergänzt und erleichtert die Navigation in sehr großen Dateien.
Versionsnummer als Teil des Namens der PDF-Datei
Diese Anforderung ist etwas aufwendiger zu konfigurieren, aber dennoch möglich. Der Vorteil ist, dass die Versionsnummer der Quelle immer im Dateinamen sofort erkennbar ist und so Missverständnisse, z.B. mit dem Kunden, vermieden werden können. Aus der großen in-STEP BLUE Werkzeugkiste werden benötigt:
- RegEx, um den Dateinamen der Quelle ohne Endung in einer alphanumerischen Eigenschaft zu speichern. Lesen Sie dazu auch meinen RegEx Beitrag.
- Eine Zustandsaktion zur Umbenennung:
| 1 | Name des Originals in alphanumerischer Eigenschaft gespeichert |
| 2 | Version des Originals in alphanumerischer Eigenschaft gespeichert |
| 3 | Den Aufruf der Umbenennung nach der PDF-Generierung als zusätzliche Aktion: |
Last but not Least: Umbenannt und dennoch stapeln
Aktuell führt folgender Fall zu einem Problem: Aus der Quelldatei „Mein_Dokument.docx“ wird das PDF „Mein_Dokument.pdf“ erstellt und über die Eigenschaft „PDF“ referenziert. Anschließend wird die Version der Quelle (z.B. 0.5) an die PDF z.B. in die Eigenschaft „Quellversion“ geschrieben. Nun wird die Quelle umbenannt: „Mein_besseres_Dokument.docx“ und wieder eine PDF generiert, die dann „Mein_besseres_Dokument.pdf“ heißt, also nicht über die alte PDF gestapelt wird. Jetzt hängen zwei Dateien unter der Referenz „PDF“, was grundsätzlich richtig ist. Nun wird, im Rahmen der oben beschriebenen Konfiguration, über diese Referenz wieder die Versionsnummer kopiert und trägt somit auch bei der älteren PDF die aktuelle Quellversionsnummer ein. Das ist unschön und nicht richtig. Wie kann abgeholfen werden?
- Die Referenzeigenschaft erhält die Kardinalität 1, dadurch ist immer nur eine PDF referenziert. Nachteil: Nach einer Umbenennung gehen ältere PDF-Versionen „verloren“, sie bleiben zwar am Zielort erhalten, verlieren aber ihren Bezug.
- Vor dem Generieren der PDF-Datei wird überprüft, ob es schon einen Eintrag unter der Referenz „PDF“ gibt. Wenn ja, wird der aktuelle Name der Quelldatei gesendet und die alte PDF wird umbenannt. Danach kann die neue PDF-Datei generiert werden und stapelt sich korrekt. Die Umbenennung kann dann in der Historie nachverfolgt werden. Lesen Sie auch dazu meinen RegEx Beitrag. Eine Kombination aus Stapeln mit umbenannter Datei und Umbenennung mit Versionsnummer ist auch möglich:
| Original | Aktion | |
|---|---|---|
| Beispieldatei.docx, Version 1.0 |
1. PDF wird erstellt 2. PDF wird umbenannt |
Beispieldatei.pdf Beispieldatei_V.1.0.pdf |
| Beispieldatei_neu.docx, Version 2.0 |
1. Name wird kopiert 2. PDF wird erstellt 3. PDF wird umbenannt |
Beispieldatei_V1.0.pdf → Beispieldatei_neu.pdf Beispieldatei_neu.pdf Beispieldatei_neu_V2.0.pdf |
Fazit
Mit der erweiterten Aktion „Datei in ein anderes Format konvertieren“ wurde ein riesiger Schritt gemacht, um Systemverantwortlichen mehr Optionen zur Automatisierung zu geben. Dank dieser Erweiterung kann ich alle meine Benutzeranforderungen umsetzen.