-
Notifications
You must be signed in to change notification settings - Fork 62
Aktualisierungshinweise auf Kitodo.Production 3.x
- Schätzung der benötigten Zeit
- Voraussetzungen
- Vorbereitende Schritte
- Update des Systems
- Migration der Anwendung
Die folgenden Werte sind grobe Zusammenfassungen erlebter Zeiträume, die unter verschiedenen technischen Umständen gewonnen wurden und Ihnen eine vage Vorstellung davon geben sollen, wie lange die technischen Prozesse der Migration dauern können. Ihre eigenen Erfahrungen können jedoch abweichen.
🕑 Datenbankmigration: ≈ 1 Minute je 1000 Vorgänge
🕑 Metadaten konvertieren: ≈ 20 Min. / 1000 Vorgänge (abweichend wurden Werte bis zu 2 Std. / 1000 Vorgänge gemeldet)
🕑 Indexierung: ≈ 20 Min. / 1000 Vorgänge
🕑 Hierarchiemigration: ≈ 1 Stunde / 1000 Vorgänge
🕑 Bilder generieren: 1000 Bilder / Stunde und Thread
🕑 Zeitungsmigration: keine Prognose bekannt
Diese Anleitung setzt voraus, dass Sie Ihr System zuerst auf Version 2.3 migriert haben.
Die Production-Version 2.3 unterstützte zwei verschiedene interne Dateiformate: METS und XStream. Version 3.2 unterstützt nur METS. Daher müssen Sie Ihre Version 2.3 verwenden, um zuvor alle internen XStream-Dateien in METS-Dateien zu konvertieren.
Gehen Sie dazu zu den Projekteinstellungen und ändern Sie die interne Formateinstellung in METS. Wählen Sie dann alle Vorgänge dieses Projekts aus und führen Sie KitodoScript action:rewriteProcessMetadata aus.
In mehreren Einrichtungen wurden beim Anlegen von Zeitungsvorgängen in Production 2 Metadaten, die für die Ausgaben relevant sind, auf der obersten Ebene (im topstruct, z.B. Newspaper) oder auf der ersten Unterebene (im firstchild, also auf der Jahresebene, z.B. NewspaperYear) abgelegt und werden beim Export der Vorgänge mittels copyData-Ausdrücken an die richtige Stelle kopiert. copyData-Ausdrücke stehen in Production 3 in dieser Form nicht mehr zur Verfügung. Daher müssen Sie, wenn Sie betroffen sind, die Metadaten noch in Production 2 vor der Migration mit der KitodoScript action:copyData an die gewünschte Stelle innerhalb der Zeitungsvorgänge verschieben.
Die Systax der action:copyData unterscheidet sich leicht von den anderen KitodoScript-Aktionen. Die Regeln werden direkt hinter dem Kommando ohne ein Präfix und ohne umschließende Anführungszeichen angegeben. Beispiel:
action:copyData /PublicationYear[0]/PublicationMonth[*]/PublicationDay[*]/Issue@DatePublished \=format "%1$04d-%2$02d-%3$02d" #1@TitleDocMain #2@TitleDocMainShort #3@TitleDocMainShort
In Version 3 wurde das Regelsatz-Dateiformat geändert. Sie sollten sich intensiv mit dem neuen Format beschäftigen und einen neuen Regelsatz für Ihre Daten erstellen. Wenn Sie möchten, können Sie einen von Zeutschel GmbH bereitgestellten experimentellen Regelsatzkonverter verwenden, um einen Vorschlag zu generieren. Beachten Sie, dass die Ausgabe dieses Programms nicht perfekt ist und später manuell überprüft und korrigiert werden muss. (Sie ersparen sich jedoch einiges an Schreibarbeit).
ℹ️ In Version 3.2 sind Import und Export nicht mehr im Regelsatz definiert, sondern in XSLT-Dateien, die ein gewisses Maß an Flexibilität bieten. XSLT ist eine Programmiersprache, die in XML geschrieben ist und zum Konvertieren von XML in andere Darstellungsformen (z.B. HTML) verwendet wird. Sie benötigen umfassende Kenntnisse in XSLT, um den Import und Export ordnungsgemäß zu konfigurieren.
Bevor Sie das Migrationsskript ausführen, sollten Sie sicherstellen, dass Ihr Datenbankschema mit dem Standardschema der Version 2.3 übereinstimmt.
Hier sind einige Skriptlösungen für die folgenden Inkonsistenzen:
Wenn Ihre Datenbank noch bit-Felder enthält, sollten Sie diese in tinyint(1) konvertieren.
ALTER TABLE `benutzer` CHANGE `IstAktiv` `IstAktiv` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `benutzer` CHANGE `mitMassendownload` `mitMassendownload` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `benutzer` CHANGE `confVorgangsdatumAnzeigen` `confVorgangsdatumAnzeigen` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `benutzereigenschaften` CHANGE `IstObligatorisch` `IstObligatorisch` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `metadatenkonfigurationen` CHANGE `orderMetadataByRuleset` `orderMetadataByRuleset` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `projekte` CHANGE `useDmsImport` `useDmsImport` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `projekte` CHANGE `dmsImportCreateProcessFolder` `dmsImportCreateProcessFolder` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `projekte` CHANGE `projectIsArchived` `projectIsArchived` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `prozesse` CHANGE `IstTemplate` `IstTemplate` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `prozesse` CHANGE `swappedOut` `swappedOut` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `prozesse` CHANGE `inAuswahllisteAnzeigen` `inAuswahllisteAnzeigen` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `prozesseeigenschaften` CHANGE `IstObligatorisch` `IstObligatorisch` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typMetadaten` `typMetadaten` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typAutomatisch` `typAutomatisch` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typImportFileUpload` `typImportFileUpload` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typExportRus` `typExportRus` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typImagesLesen` `typImagesLesen` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typImagesSchreiben` `typImagesSchreiben` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typExportDMS` `typExportDMS` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typBeimAnnehmenModul` `typBeimAnnehmenModul` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typBeimAnnehmenAbschliessen` `typBeimAnnehmenAbschliessen` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typBeimAnnehmenModulUndAbschliessen` `typBeimAnnehmenModulUndAbschliessen` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typBeimAbschliessenVerifizieren` `typBeimAbschliessenVerifizieren` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `typScriptStep` `typScriptStep` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `schritte` CHANGE `batchStep` `batchStep` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `vorlageneigenschaften` CHANGE `IstObligatorisch` `IstObligatorisch` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `werkstueckeeigenschaften` CHANGE `IstObligatorisch` `IstObligatorisch` TINYINT(1) NULL DEFAULT NULL;
ALTER TABLE `prozesse` CHANGE `wikifield` `wikifield` LONGTEXT NULL DEFAULT NULL;
ALTER TABLE `prozesseeigenschaften` CHANGE `Wert` `Wert` LONGTEXT NULL DEFAULT NULL;
ALTER TABLE `vorlageneigenschaften` CHANGE `Wert` `Wert` LONGTEXT NULL DEFAULT NULL;
ALTER TABLE `werkstueckeeigenschaften` CHANGE `Wert` `Wert` LONGTEXT NULL DEFAULT NULL;Wenn eines dieser booleschen Felder nicht initialisiert ist, sollten Sie es initialisieren
UPDATE benutzer SET IstAktiv = 0 WHERE IstAktiv IS NULL OR IstAktiv != 1;
UPDATE benutzer SET mitMassendownload = 0 WHERE mitMassendownload IS NULL OR mitMassendownload != 1;
UPDATE benutzer SET confVorgangsdatumAnzeigen = 0 WHERE confVorgangsdatumAnzeigen IS NULL OR confVorgangsdatumAnzeigen != 1;
UPDATE benutzereigenschaften SET IstObligatorisch = 0 WHERE IstObligatorisch IS NULL OR IstObligatorisch != 1;
UPDATE metadatenkonfigurationen SET orderMetadataByRuleset = 0 WHERE orderMetadataByRuleset IS NULL OR orderMetadataByRuleset != 1;
UPDATE projectfilegroups SET previewImage = 0 WHERE previewImage IS NULL OR previewImage != 1;
UPDATE projekte SET useDmsImport = 0 WHERE useDmsImport IS NULL OR useDmsImport != 1;
UPDATE projekte SET dmsImportCreateProcessFolder = 0 WHERE dmsImportCreateProcessFolder IS NULL OR dmsImportCreateProcessFolder != 1;
UPDATE projekte SET projectIsArchived = 0 WHERE projectIsArchived IS NULL OR projectIsArchived != 1;
UPDATE prozesse SET IstTemplate = 0 WHERE IstTemplate IS NULL OR IstTemplate != 1;
UPDATE prozesse SET swappedOut = 0 WHERE swappedOut IS NULL OR swappedOut != 1;
UPDATE prozesse SET inAuswahllisteAnzeigen = 0 WHERE inAuswahllisteAnzeigen IS NULL OR inAuswahllisteAnzeigen != 1;
UPDATE prozesseeigenschaften SET IstObligatorisch = 0 WHERE IstObligatorisch IS NULL OR IstObligatorisch != 1;
UPDATE schritte SET typMetadaten = 0 WHERE typMetadaten IS NULL OR typMetadaten != 1;
UPDATE schritte SET typAutomatisch = 0 WHERE typAutomatisch IS NULL OR typAutomatisch != 1;
UPDATE schritte SET typAutomatisch = 0 WHERE typAutomatisch IS NULL OR typAutomatisch != 1;
UPDATE schritte SET typImportFileUpload = 0 WHERE typImportFileUpload IS NULL OR typImportFileUpload != 1;
UPDATE schritte SET typExportRus = 0 WHERE typExportRus IS NULL OR typExportRus != 1;
UPDATE schritte SET typImagesLesen = 0 WHERE typImagesLesen IS NULL OR typImagesLesen != 1;
UPDATE schritte SET typImagesSchreiben = 0 WHERE typImagesSchreiben IS NULL OR typImagesSchreiben != 1;
UPDATE schritte SET typExportDMS = 0 WHERE typExportDMS IS NULL OR typExportDMS != 1;
UPDATE schritte SET typBeimAnnehmenModul = 0 WHERE typBeimAnnehmenModul IS NULL OR typBeimAnnehmenModul != 1;
UPDATE schritte SET typBeimAnnehmenAbschliessen = 0 WHERE typBeimAnnehmenAbschliessen IS NULL OR typBeimAnnehmenAbschliessen != 1;
UPDATE schritte SET typBeimAnnehmenModulUndAbschliessen = 0 WHERE typBeimAnnehmenModulUndAbschliessen IS NULL OR typBeimAnnehmenModulUndAbschliessen != 1;
UPDATE schritte SET typBeimAbschliessenVerifizieren = 0 WHERE typBeimAbschliessenVerifizieren IS NULL OR typBeimAbschliessenVerifizieren != 1;
UPDATE schritte SET typScriptStep = 0 WHERE typScriptStep IS NULL OR typScriptStep != 1;
UPDATE schritte SET batchStep = 0 WHERE batchStep IS NULL OR batchStep != 1;
UPDATE vorlageneigenschaften SET IstObligatorisch = 0 WHERE IstObligatorisch IS NULL OR IstObligatorisch != 1;
UPDATE werkstueckeeigenschaften SET IstObligatorisch = 0 WHERE IstObligatorisch IS NULL OR IstObligatorisch != 1;Es sollte keine toten Referenzen geben. Löschen Sie verwaiste Datensätze.
SET FOREIGN_KEY_CHECKS=0;
DELETE FROM batchesprozesse WHERE batchesprozesse.ProzesseID NOT IN (SELECT prozesse.ProzesseID FROM prozesse);
DELETE FROM batchesprozesse WHERE batchesprozesse.BatchID NOT IN (SELECT batches.BatchID FROM batches);
UPDATE benutzer SET benutzer.ldapgruppenID = NULL WHERE benutzer.ldapgruppenID NOT IN (SELECT ldapgruppen.ldapgruppenID FROM ldapgruppen);
DELETE FROM benutzereigenschaften WHERE benutzereigenschaften.BenutzerID NOT IN (SELECT benutzer.BenutzerID FROM benutzer);
DELETE FROM benutzergruppenmitgliedschaft WHERE benutzergruppenmitgliedschaft.BenutzerGruppenID NOT IN (SELECT benutzergruppen.BenutzergruppenID FROM benutzergruppen);
DELETE FROM benutzergruppenmitgliedschaft WHERE benutzergruppenmitgliedschaft.BenutzerID NOT IN (SELECT benutzer.BenutzerID FROM benutzer);
DELETE FROM history WHERE history.processID NOT IN (SELECT prozesse.ProzesseID FROM prozesse);
DELETE FROM projectfilegroups WHERE projectfilegroups.ProjekteID NOT IN (SELECT projekte.ProjekteID FROM projekte);
DELETE FROM projektbenutzer WHERE projektbenutzer.BenutzerID NOT IN (SELECT benutzer.BenutzerID FROM benutzer);
DELETE FROM projektbenutzer WHERE projektbenutzer.ProjekteID NOT IN (SELECT projekte.ProjekteID FROM projekte);
UPDATE prozesse SET prozesse.ProjekteID = NULL WHERE prozesse.ProjekteID NOT IN (SELECT projekte.ProjekteID FROM projekte);
UPDATE prozesse SET prozesse.MetadatenKonfigurationID = NULL WHERE prozesse.MetadatenKonfigurationID NOT IN (SELECT metadatenkonfigurationen.MetadatenKonfigurationID FROM metadatenkonfigurationen);
UPDATE prozesse SET prozesse.docketID = NULL WHERE prozesse.docketID NOT IN (SELECT dockets.docketID FROM dockets);
DELETE FROM prozesseeigenschaften WHERE prozesseeigenschaften.prozesseID NOT IN (SELECT prozesse.ProzesseID FROM prozesse);
DELETE FROM schritte WHERE schritte.ProzesseID NOT IN (SELECT prozesse.ProzesseID FROM prozesse);
UPDATE schritte SET schritte.BearbeitungsBenutzerID = NULL WHERE schritte.BearbeitungsBenutzerID NOT IN (SELECT benutzer.BenutzerID FROM benutzer);
DELETE FROM schritteberechtigtebenutzer WHERE schritteberechtigtebenutzer.BenutzerID NOT IN (SELECT benutzer.BenutzerID FROM benutzer);
DELETE FROM schritteberechtigtebenutzer WHERE schritteberechtigtebenutzer.schritteID NOT IN (SELECT schritte.SchritteID FROM schritte);
DELETE FROM schritteberechtigtegruppen WHERE schritteberechtigtegruppen.BenutzerGruppenID NOT IN (SELECT benutzergruppen.BenutzergruppenID FROM benutzergruppen);
DELETE FROM schritteberechtigtegruppen WHERE schritteberechtigtegruppen.schritteID NOT IN (SELECT schritte.SchritteID FROM schritte);
DELETE FROM vorlagen WHERE vorlagen.ProzesseID NOT IN (SELECT prozesse.ProzesseID FROM prozesse);
DELETE FROM vorlageneigenschaften WHERE vorlageneigenschaften.vorlagenID NOT IN (SELECT vorlagen.VorlagenID FROM vorlagen);
DELETE FROM werkstuecke WHERE werkstuecke.ProzesseID NOT IN (SELECT prozesse.ProzesseID FROM prozesse);
DELETE FROM werkstueckeeigenschaften WHERE werkstueckeeigenschaften.werkstueckeID NOT IN (SELECT werkstuecke.WerkstueckeID FROM werkstuecke);
SET FOREIGN_KEY_CHECKS=1;Das Datenbankmodul sollte InnoDB sein.
ALTER TABLE batches ENGINE=innodb;
ALTER TABLE benutzer ENGINE=innodb;
ALTER TABLE benutzereigenschaften ENGINE=innodb;
ALTER TABLE benutzergruppen ENGINE=innodb;
ALTER TABLE benutzergruppenmitgliedschaft ENGINE=innodb;
ALTER TABLE dockets ENGINE=innodb;
ALTER TABLE history ENGINE=innodb;
ALTER TABLE ldapgruppen ENGINE=innodb;
ALTER TABLE metadatenkonfigurationen ENGINE=innodb;
ALTER TABLE projectfilegroups ENGINE=innodb;
ALTER TABLE projektbenutzer ENGINE=innodb;
ALTER TABLE projekte ENGINE=innodb;
ALTER TABLE prozesse ENGINE=innodb;
ALTER TABLE prozesseeigenschaften ENGINE=innodb;
ALTER TABLE schritte ENGINE=innodb;
ALTER TABLE schritteberechtigtebenutzer ENGINE=innodb;
ALTER TABLE schritteberechtigtegruppen ENGINE=innodb;
ALTER TABLE vorlagen ENGINE=innodb;
ALTER TABLE vorlageneigenschaften ENGINE=innodb;
ALTER TABLE werkstuecke ENGINE=innodb;
ALTER TABLE werkstueckeeigenschaften ENGINE=innodb;
ALTER TABLE batches ENGINE=innodb;
ALTER TABLE batches ENGINE=innodb;
ALTER TABLE batches ENGINE=innodb;
ALTER TABLE batches ENGINE=innodb;
ALTER TABLE batches ENGINE=innodb;Wenn Ihr System diesen Inkonsistenzen nicht unterliegt, sollten die Skripte keine Änderungen vornehmen. Im Anschluss können Sie das Migrations-SQL-Skript ausführen. Das Migrations-SQL-Skript funktioniert teilweise nicht, diese Fehler sollen jedoch nicht behoben werden. Sie können die Migration jedoch lokal wie hier angegeben anpassen.
In Version 3 wird Production erneut durch einen Suchmaschinenindex unterstützt. Da die Suchmaschinenintegration in Production 3.2 auf einem Missverständnis bei der Verwendung des Suchmaschinenindex beruht, der in ElasticSearch-Version 6 entfernt wurde, können Sie keine neueren Versionen der Software verwenden. Stellen Sie sicher, dass Sie die neueste Veröffentlichung von Version 5 installieren. Sie können dazu den Paketmanager verwenden:
Nicht mehr aktuell: Kommandos zum Installieren von ElasticSearch v. 5
export JAVA_HOME=/usr/lib/jvm/default-java
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
sudo add-apt-repository "deb https://artifacts.elastic.co/packages/5.x/apt stable main"
sudo apt-get update
sudo apt-get install elasticsearch
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearchProduction 3 verwendet das ImageMagick-Programm, um verschiedene Bilddateiformate zu generieren, z.B. um im Browser anzeigbare Bilder aus TIFF-Dateien zu erstellen, da die vollständige Unterstützung von TIFF-Dateien für Java 8 und neuer nicht mehr verfügbar ist. Sie können ImageMagick mit dem Paketmanager installieren:
sudo apt-get install imagemagick
convert-Programm installiert wird. (Dies ist unter Linux immer noch der Normalfall, muss jedoch bei der Installation unter Windows manuell aktiviert werden.)
Verschieben Sie das kitodo-Verzeichnis und die kitodo.war-Datei aus dem webapps-Verzeichnis von Tomcat. Löschen Sie das kitodo-Verzeichnis im work/Catalina/localhost-Verzeichnis von Tomcat.
ℹ️ Production 3.2 wird mit Modulen geliefert, diese unterscheiden sich jedoch sowohl von den Modulen aus Version 2.3 (die in der Datei modules.xml konfiguriert werden mussten) als auch von den Plug-Ins. Keines von beidem wird in Production 3.2 mehr unterstützt. (Sie können die modules.xml-Datei und das plugins-Verzeichnis löschen.) Die Module in Production 3.2 sind nur ein Teil des Programms, das von der WAR-Datei der Webanwendung getrennt wurde, um Querbezüge zwischen verschiedenen Teilen des Programms zu reduzieren.
Erstellen Sie ein Verzeichnis /usr/local/kitodo/modules und entpacken Sie dort die mit der Version gelieferten Module.
Starten Sie Tomcat, damit er die Webanwendung entpackt. Dann halten Sie ihn wieder an.
Überprüfen Sie die Einstellungen in der Datei webapps/kitodo/WEB-INF/kitodo_config.properties und passen Sie diese ggf. an.
Erstellen Sie einen Ordner /usr/local/kitodo/diagrams. Dieser muss für den Tomcat schreibbar sein.
Löschen Sie den Ordner messages.
Kopieren Sie alle XSLT-Skripten aus webapps/kitodo/WEB-INF/classes/xslt/ in den xslt-Ordner. Ersetzen Sie die vorhandenen Regelsätze durch die neu erstellten. Erstellen Sie für jeden Regelsatz eine Export-XSLT-Datei gleichen Namens (nur mit der Endung .xsl anstelle .xml). Sie können sich dabei am Beispiel ruleset_default.xsl orientieren.
Hinterlegen Sie die Dateien kitodo_opac.xml und kitodo_fileFormats.xml aus der Config-Zip-Datei im config-Ordner und die XSL-Dateien aus der Zip-Datei im xslt-Ordner.
Während der Migration empfehlen wir, den Log-Level auf die Einstellung trace (Ablaufverfolgung) zu erhöhen. Dies führt zu einer hilfreicheren Ausgabe während der Migration. Ändern Sie beispielsweise die Datei webapps/kitodo/WEB-INF/log4j2.xml wie folgt:
<Loggers>
<!-- Die Logger de.unigoettingen.sub.search.opac und org.goobi werden nicht mehr benötigt -->
<Logger name="org.kitodo" level="trace" additivity="false">
<AppenderRef ref="LOGFILE" /> <!-- Entfernen Sie hier das Attribut level="error" -->
</Logger>
<Root level="error">
<AppenderRef ref="STDOUT"/>
<AppenderRef ref="LOGFILE"/>
</Root>
</Loggers>Starten Sie Tomcat wieder.
Melden Sie sich mit einem Benutzer mit Administratorrechten bei der Benutzeroberfläche an.
ℹ️ Abhängig von der Konfiguration Ihres Benutzers müssen Sie dem Benutzer möglicherweise zusätzliche Berechtigungen über die Datenbank erteilen. Die Berechtigungen werden als Rollen in der Datenbank verwaltet, wobei jede role eine Sammlung mehrerer einzelner Berechtigungen ist. In Production 3.2 gibt es eine ganze Reihe von Einzelberechtigungen. Sie können Ihrem Benutzer Rollen zuweisen, indem Sie Verweise auf die Tabelle user_x_role hinzufügen.
Nach der Anmeldung landen Sie auf der Konfigurationsseite "System" auf der Registerkarte "Indexierung" und werden mit den Informationen konfrontiert, dass der Index aktualisiert werden muss. Das stimmt, aber vor der Indizierung sollten wir die METS-Dateien Ihrer Prozesse konvertieren, um sie indexieren zu können.
Wechseln Sie zur Registerkarte Migration. Wählen Sie “Metadaten konvertieren”, wählen Sie alle Projekte aus, die Sie migrieren möchten, und klicken Sie auf "Metadaten konvertieren".
Wechseln Sie zurück zur Registerkarte “Indexierung”. Erstellen Sie das Indexprofil und starten Sie die Indexierung. Wenn die Indexierunghängt, müssen Sie möglicherweise Tomcat neu starten, sich erneut anmelden und die Indizierung neu starten. Warten Sie, bis die Indexierung abgeschlossen ist.
Überprüfen Sie zum Generieren von Bildableitungen zunächst Ihre Projektkonfiguration. Es gibt einen Ordnerbereich. Stellen Sie sicher, dass der Quellordner korrekt konfiguriert ist. Aktivieren Sie die Bilderzeugung für jeden Ordner, dessen Inhalt generiert werden soll.
Zunächst müssen Sie möglicherweise zusätzliche Bildordner erstellen, falls diese noch nicht vorhanden sind. Gehen Sie zu Prozesse und wählen Sie alle Prozesse aus, deren Bilder Sie generieren möchten. Führen Sie KitodoScript action:createFolders aus.
Anschließend können Sie KitodoScript action:generateImages folders:all images:all ausführen. Die Bilder werden asynchron im Hintergrund generiert. Sie können den Fortschritt im Task-Manager überwachen.
Das Erstellen von Workflows ist eine intellektuelle Aufgabe, die von einem Fachverantwortlichen zu bearbeiten ist. Sie gehen auf das System, und wählen die Workflows-migrieren-Schaltfläche. Wählen Sie Projekte aus. Die Analyse wird durchgeführt. (Dies kann einige Zeit dauern, abhängig davon, wie viele Datensätze aus der Datenbank gelesen werden müssen. Warten Sie einfach oder beobachten Sie die Protokolldatei, um den Fortschritt zu sehen.) Anschließend werden die nach Vorkommen absteigenden Workflows in der folgenden Liste angezeigt. Sie klicken auf die Kreuzpfeile, um einen Workflow zu erstellen (oder einen vorhandenen Workflow wiederzuverwenden).
Beim Erstellen eines Workflows müssen Sie jeder Workflowaufgabe Rollen zuweisen. Sie können den Workflow bestehender Prozesse jedoch nicht ändern. Setzen Sie den Workflow auf aktiv und speichern Sie ab.
Später müssen Sie aus dem von Ihnen erstellten Workflow eine Produktionsvorlage erstellen und dann zuweisen. Das kann ein bisschen dauern. Warten Sie, bis der Inhalt des Fensters ausgeblendet wird (oder sehen Sie sich die Protokolldatei an, um festzustellen, wann der Vorgang abgeschlossen ist).
Die Hierarchie-Migrationsaufgabe wird automatisch ausgeführt, um hierarchische Prozesse zu erstellen.
ℹ️ Hierarchische Prozesse sind eine neue Funktion in Production 3, die eine weitere Komplexitätsebene hinzufügt. Prozesse können als Eltern − Kinder miteinander verknüpft werden, um hierarchische Abhängigkeiten von Katalogdatensätzen wie Serien oder mehrbändigen Werken darzustellen. Die übergeordneten Daten werden nur einmal in der übergeordneten Einheit gespeichert.
Hier muss die Migration alle Metadaten aus Dateien aller Prozesse einlesen, um übergeordnete Metadaten hierarchischer Eltern zu sammeln, dann Eltern zu erstellen und Links in Datenbank und Dateien zu erstellen. Dies ist komplex und dauert einige Zeit, wird jedoch im Hintergrund vollautomatisch ausgeführt.
Dies ist dasselbe wie für die Hierarchie, aber basierend auf einem Batch aus Production 2.3 für eine Zeitung wird eine Hierarchie der Zeitung erstellt, die noch komplexer ist. Dies passiert ebenfalls im Hintergrund.