Migration KIX 17
Sie können die Daten von KIX 17 nach KIX 18 automatisiert übertragen. Dies erfolgt komfortabel über die Benutzeroberfläche im Menü. KIX 18 (aktives System) holt sich dazu die Daten vom Quellsystem KIX 17 (passives System) ab.
Sie müssen in KIX 18 als Nutzer mit Admin-Rechten angemeldet sein, um die Migration durchführen zu können (Rollen: System Admin, Superuser).
Voraussetzung für die Migration sind:
eine aktuelle Version von KIX 17 (KIX 17.14.0 und höher)
die Aktivierung des Pre-Shared Key Modus in der Konfigurationsdatei von KIX 17 mit Angabe des Pre-Shared Keys .
Alternativ dazu kann die Migration auch manuell über die Konsole im Menü erfolgen. Die Konsole ermöglicht zudem die Migration einzelner Objekte wie Tickets, Organisationen etc.
Weiterführende Informationen zur Migration via Konsole sowie Hinweise zu den übertragenen Daten finden Sie unter: Migration KIX 17 zu KIX 18.
Zum Durchführen der Migration gehen Sie schrittweise wie folgt vor:
KIX 17 und KIX 18 unterstützen einen PSK-Modus (PSK = Pre-Shared-Key). Der PSK ist ein Prüfschlüssel zur Absicherung der Datenübertragung. Er verhindert den unautorisierten Zugang zur Datenbank. Nur wenn beiden Systemen dieser vorher vereinbarte Schlüssel bekannt ist, erfolgt die Migration. KIX 17 weist Anfragen zurück wenn kein oder ein falscher PSK übermittelt wird.
Der PSK wird in der Konfigurationsdatei Config.pm von KIX 17 hinterlegt und der Migration in KIX 18 als Parameter mitgegeben.
Warnung
Ist der PSK-Modus aktiviert, ist das System für den Zugriff von Außen geöffnet. Unbefugte Dritte können sich Zugang zur Datenbank verschaffen, wenn ihnen der Schlüssel bekannt ist.
Für die Benennung des Schlüssels sind daher die Konventionen zur Vergabe eines sicheren Passwortes bindend!
Löschen Sie nach Abschluss der Migration den Schlüssel in beiden Systemen und deaktivieren Sie den PSK-Modus, um den Zugriff von Außen zu unterbinden!
Verwenden Sie einen PSK, der keine zu URL-codierenden Zeichen beinhaltet (https://www.w3schools.com/tags/ref_urlencode.asp) oder führen bei Verwendung solcher Zeichen selbst eine Quotierung aus.
So aktivieren Sie den PSK-Modus
Öffnen Sie die Konfigurationsdatei im Dateisystem von KIX 17.
Diese finden Sie unter:
/opt/kix/Kernel/Config.pm.Suchen Sie den Abschnitt
insert your own config settings "here".Fügen Sie innerhalb des Abschnitts nachfolgende Codezeilen ein.
Entfernen Sie die Kommentare im Code.
Vergeben Sie statt "my_PSK_Password" ein eigenes, sicheres Passwort und speichern Sie Ihre Änderungen.
# PSK-Modus aktivieren $Self->{'Migration::Active'} = 1; # PSK benennen $Self->{'Migration::PSK'} = 'my_PSK_Password';
Hinweis
Sie können die Migration unterbrechen. Klicken Sie dazu auf . Die Hintergrundprozesse werden beendet. Dies kann je nach Migrationsfortschritt etwas Zeit beanspruchen. Beim erneuten Start der Migration werden nur die nicht oder teilweise migrierten Tickets betrachtet.
Tritt bei der Migration ein Fehler auf, wird dieser in einer Log-Datei dokumentiert (Menü System > Logs). In der Anzeige wird lediglich dokumentiert, dass ein Objekt fehlerhaft war. Im Falle eines HTTP-Fehlers (z. B. falsche URL) wird der HTTP-Status als Progress-Status angezeigt.
Navigieren Sie zu Menü .
Im Contentbereich wird ein Formular geöffnet, in welches Sie die erforderlichen Parameter eintragen können.
Abb.: Migrationsbeispiel mit Parametern
Tragen Sie folgende Parameter ein:
URL zu KIX 17 migration.pl
Tragen Sie die URL der Quelle (KIX 17) ein, z. B.
http:// myKIX17domain.de/kix/migration.plDie Angabe der Domain (z. B. myKIX17domain.de) ist ausreichend. KIX ergänzt die URL um
http://und/kix/ migration.pl.Die URL können Sie der Adresszeile im Browser Ihres geöffneten KIX17-Systems entnehmen, z. B.:
http://192.168.160.200:4711/kix/ index.pl oder https://myKIX17domain.de/kix/ index.pl
Die Angabe der URL entspricht der Angabe der
--source- idin der Konsole.Möchten Sie die durchgeführte Migration anschließend über die Konsole bereinigen, führen Sie dazu im Menü das Kommando Maint::Cache::Delete aus. Melden Sie sich dann vom System ab und wieder an.
Pre-Shared Key (PSK)
Tragen Sie den in KIX 17 hinterlegten Wert ein, z. B.
start123.Anzahl Worker
Anzahl der parallelen Prozesse, die für die Massenobjekte wie Tickets usw. verwendet werden sollen.
Standard: 1
Mit der Anzahl der Worker bestimmen Sie die zur Verfügung stehende Systemleistung. Dies hat Einfluss auf die Performance Ihres Servers. Je höher die Anzahl der Worker desto schneller der Migrationsprozess bei stärkerer Belastung des Systems.
Wichtig
Vermeiden Sie eine Überlastung Ihres Systems!
Bereits 4 Worker können einen Host zu 100% auslasten. Daher sind KIX.Cloud-Umgebebungen auf max. 2 Worker begrenzt.
Starten Sie die Migration mit einem Klick auf .
Die Tabelle zeigt den Status, Fortschritt und eventuelle Fehler der Übertragung pro Objekt an
rot: Fehler
gelb: ignoriert
grün: erfolgreich
weiß: wartend
Nach erfolgreicher Übertragung sind die Daten aus KIX 17 in KIX 18 enthalten.
Wichtig
Bei aktiviertem PSK-Modus können sich unbefugte Dritte Zugang zur Datenbank verschaffen, sobald sie in Besitz des Schlüssels gelangen.
Es ist daher zwingend erforderlich, nach Abschluss der Migration (oder nach Abbruch) den Zugriff auf die Datenbank wieder zu unterbinden!
Löschen Sie dazu den Schlüssel und deaktiveren Sie den Pre-Shared Modus wie folgt:
Öffnen Sie die Konfigurationsdatei im Dateisystem von KIX 17.
Diese finden Sie unter:
/opt/kix/Kernel/Config.pm.Suchen Sie den Abschnitt
insert your own config settings "here"Löschen Sie innerhalb des Abschnitts die von Ihnen eingefügten Codezeilen und speichern Sie diese Änderung.
Die migrierten Daten werden mit einem Migrations-Präfix gekennzeichnet, wenn im Zielsystem bereits eine gleichnamiges Objekt existiert, z. B. Klasse Migration-Computer oder Migration-Nutzername.
Überprüfen Sie die übertragenen Daten, Platzhalter, Signaturen etc. und passen Sie diese ggf. an. Sie können diese einzeln manuell oder durch Anwendung eines Jobs automatisiert bearbeiten.
Anmerkung
Nachdem die Daten übertragen wurden, stehen diese zur Verfügung. Der Aufbau der Indizes für Volltextsuchen oder Anzahl von Tickets pro Team, Assets pro Klasse o.ä. kann jedoch einige Zeit in Anspruch nehmen. Je nach Umfang der Daten (mehrere 100.000 Tickets) kann dies auch mehrere Stunden erfordern.
Anmerkung
Nach Abschluss der Migration ist auf der KIX 18 Umgebung eine Cache-Bereinigung durchzuführen, um inkonsistente Datendarstellung zu vermeiden. Führen Sie dazu im Menü das Kommando Maint::Cache::Delete aus, melden sich von der GUI ab und wieder an.
KIX 18 beantwortet diverse Szenarien anders als KIX 17 und verwirft einige der historisch gewachsenen Strukturen. Bitte beachten Sie, dass es nicht für alle Funktionen und Verhaltensweisen aus KIX 17 eine 1:1 Entsprechung in KIX 18 gibt. KIX 18 ist in großen Teilen ein eigenständiges Produkt. Nachfolgend finden Sie daher einige Hinweise auf relevante Aspekte.
Berechtigungsstruktur
Das Berechtigungssystem in KIX 18 ist von Grund auf neu erstellt (s. auch Berechtigungskonzept). Wenden Sie sich bitte an unseren Support, wenn Sie Unterstützung bei der Migration benötigen.
Kunden- und Agentennutzer
In KIX 18 bilden "Kontakte" die Grundlage für Ansprechpartner und Agenten. Einem Kontakt kann ein Nutzerkonto zugeordnet werden. Damit wird der Kontakt zum Nutzer und er kann sich am Self Service Portal oder als Agent am Agentenportal anmelden.
Die Migration erzeugt:
aus jedem KIX 17-Kundenansprechpartner einen KIX 18-Kontakt mit dem Nutzungskontext "Kunde" (Zugang zum Self Service Portal)
aus jedem KIX 17-Agentennutzer einen KIX 18-Kontakt mit dem Nutzungskontext "Agent" (Zugang zum Agentenportal).
Ist ein KIX 17-Login-Kenner sowohl als "Kundennutzer" als auch als "Agentennutzer" vorhanden, erhält der resultierende KIX 18-Nutzer beide Nutzungskontexte. Grundlage für die Migration bilden die in der KIX 17-Datenbank vorhandenen Kunden- und Agentennutzer (siehe Migrationsvorbereitung).
Kontakte und Organisationen
In KIX 18 muss den Kontakten nicht zwingend eine Organisation zugeordnet sein. Auch die Tickets zu diesen Kontakten bedürfen keiner Organisation. Daher wird bei einer Migration von Kontakten und Tickets keine Organisation mehr angelegt, wenn der Kontakt oder das Ticket keine zugeordnete Organisation hat. Ist keine Kundenfirma zur CustomerID eines Kontakts angelegt, werden die Zuordnungen nicht übertragen und die Kontakte existieren ohne jede Zuweisung.
Anmerkung
Bis auf Weiteres gilt: Für die Nutzung des SSP wird die Zuordnung einer Organisation verlangt.
Artikeltypen
KIX 18 verwendet keine Artikeltypen mehr. Stattdessen werden Kommunikationskanäle angeboten. Der Artikeltyp "Telefon" ist nicht mehr im Standard vorhanden und wird durch den Artikeltyp "Note" ersetzt. Dadurch werden Gespräche allgemein als Gesprächsnotizen dokumentiert - unabhängig davon, ob sie per Telefon oder von Angesicht zu Angesicht geführt wurden.
Hinweis
Spezifische Artikeltypen werden ebenfalls durch den Kommunikationskanal "Note" ersetzt.
Config Item Attachments
KIX 17 offeriert zwei Möglichkeiten für CI-Attachments. Die empfohlene und auch weiter bestehende ist die Verwendung von CI-Attributen vom Typ Attachment. Eine Änderung dieser Anhänge erzeugt auch in KIX 18 weiterhin eine Asset-Version. Die aus KIX 17 bekannten nicht-versionierenden Anhänge werden in in Assets nicht fortgeführt. Etwaige Anhänge werden übernommen und in versionierende Attribute überführt.
Hinweis
Bitte beachten Sie die sich damit ändernde Bedienung!
Verknüpfungstypen
KIX 17 verwendet einige Verknüpfungstypen und -beziehungen, die nicht plausibel erscheinen. In KIX 18 sind daher nicht mehr alle Verknüpfungstypen zwischen beliebigen Objekten zulässig. Die Migration legt derartige Verknüpfungen als "Relevant To"-Verknüpfungen an.
Konfigurationseinstellungen
Konfigurationseinstellungen werden nur teilweise übertragen und benötigen eine gezielte Betrachtung (siehe Erweiterte Konfigurationsübertragung).
Ticketstatustypen
Verwendet Ihre KIX-Installation eigene Ticketstatustypen, müssen die Ticketstatus zunächst auf standardmäßig vorhandene Ticketstatustypen geändert werden.
Achtung
Spezifische, eigene Ticketstatustypen können die Migration blockieren und müssen zwingend vor der Migration beseitigt werden.