Cicero bietet die Möglichkeit, Informationen über Kund*innen, die einer Einrichtung zugeordnet sind, aus
ausgewählten Webservices zu importieren.
Angaben zu Schüler*innen und Mitarbeitenden werden regelmäßig mit neuen Informationen aktualisiert, sodass Schüler*innen z. B. automatisch die Klasse wechseln (aufrücken), sobald die Einrichtung die Angaben in ihrem Webservice aktualisiert hat.
Nachfolgend wird beschrieben, wie der Import gehandhabt wird:
- Für jede Zweigstelle wird eine Kund*innengruppe mit dem Namen der Zweigstelle angelegt. Die Kund*innengruppe wird
als Kund*innengruppe unter „Alle“ angelegt, sofern sie noch nicht existiert. - Unter Zweigstelle werden drei Kund*innengruppen angelegt, nämlich „Schüler*innen“, „Mitarbeitende“ und „Ausgeschieden“. Darin werden Kund*innengruppen auf Grundlage der Klasseninformationen aus dem Infodienst angelegt.
- Der Import verändert keine anderen als die genannten Kund*innengruppen.
- Der Import ordnet Mitarbeitende direkt der Gruppe „Mitarbeitende“ zu.
- Für Schüler*innen wird pro Klasse eine Kund*innengruppe angelegt. Ein*e Schüler*in kann mehreren Gruppen angehören, grundsätzlich wird jedoch nur die Hauptgruppe importiert.
Cicero gleicht Schüler*innen und Mitarbeitende über UNI-Login ab, sekundär über die CPR-Nummer und zuletzt über Namen und
alle Adressfelder. Kund*innen (Schüler*innen) werden in die Gruppen einsortiert, die auf Grundlage der Angaben aus
dem Infodienst angelegt werden. Sofern Cicero den*die Kund*in nicht im System findet, wird der*die Kund*in angelegt.
Schüler*innen lassen sich nach dem Import somit in Kund*innengruppen folgender Form finden:
- Alle > Brædstrup Skole > Schüler*innen > 6b
Beim erstmaligen Ausführen eines Imports können potenziell Duplikate von Kund*innengruppen entstehen, da die Struktur aus
der Konvertierung des bestehenden Systems nicht zwangsläufig mit der Struktur übereinstimmt, die aus
dem Kund*innenimport-Webservice eingelesen wird. Der Import behält sowohl die ursprüngliche als auch die importierte Struktur bei,
sofern sie sich nicht überschneiden. Die Kund*innen gehören dann beiden Kund*innengruppen an. Ist die Schule mit der
importierten Struktur zufrieden, können die alten Kund*innengruppen gelöscht werden.
Haben mehrere Zweigstellen dieselbe Einrichtungsnummer, werden die Klassen auf beiden Zweigstellen angelegt, und damit
sind die Kund*innen der Klasse auf beiden Zweigstellen zugeordnet. Das tritt typischerweise im Zusammenhang mit administrativen
Schulzusammenlegungen auf.
Konfiguration des Imports von Kund*innendaten aus Webservices
Es ist möglich zu konfigurieren, welche Daten importiert werden sollen – entweder über UNI*C, den UC-Kund*innenimport-
Service, TIETO/IST oder durch Upload einer CSV-Datei. Dies geschieht über Admin > Allgemeine Einstellungen > Kund*in > Import-Kund*innenregeln. Die Konfiguration kann bei Bedarf für jede einzelne Zweigstelle unterschiedlich eingerichtet werden.
Die Konfiguration ist in XML-Syntax verfasst und sieht im Ausgangszustand wie folgt aus:
<ImportLoanerConfiguration>
<Service>
</Service>
<DataToImport>
<BirthDate>true</BirthDate>
<CPR>true</CPR>
<Address>true</Address>
<Email>true</Email>
<Phone>true</Phone>
<AllGroups>false</AllGroups>
<Guardian>true</Guardian>
</DataToImport>
<OverwritePhoneNumbers>false</OverwritePhoneNumbers>
<OverwriteEmails>false</OverwriteEmails>
<OverwritePickupBranch>true</OverwritePickupBranch>
<EnableNotificationOnDataUpdate>
<SMS>false</SMS>
<Email>false</Email>
<DigitalPost>false</DigitalPost>
</EnableNotificationOnDataUpdate>
<UseCPRasUserId>false</UseCPRasUserId>
<NotifyNewPatron>false</NotifyNewPatron>
<SkipEmailIdentifier>false</SkipEmailIdentifier>
<AutoDeletePatronsWithOutstandings>false</AutoDeletePatronsWithOutstandings>
<AutoDeleteReservationsOnBranchTransfer>false</AutoDeleteReservationsOnBranchTransfer>
</ImportLoanerConfiguration>
Wichtig ist, dass der Text zwischen „< >“ nicht verändert wird und dass ausschließlich „true“ oder
„false“ angegeben werden kann, je nachdem, ob der Import des jeweiligen Feldes aktiviert oder deaktiviert werden soll.
- <BirthDate> Steht dieser auf false, wird das Geburtsdatum nicht eingefügt/aktualisiert.
-
<CPR> Wird dieser auf false gesetzt, ist das CPR-Feld beim Anlegen eines*r neuen Kund*in leer, und das Feld
wird bei bestehenden Kund*innen nicht aktualisiert. CPR-Nummern in den importierten Daten werden unabhängig von dieser Einstellung dafür verwendet, bestehende Kund*innen zuzuordnen. - <Address> Steht dieser auf false, wird das Feld nicht aktualisiert.
- <Email> Steht dieser auf false, wird die E-Mail-Adresse nicht eingefügt/aktualisiert.
- <Phone> Steht dieser auf false, wird die Telefonnummer nicht eingefügt/aktualisiert.
-
<AllGroups>
o Standardmäßig deaktiviert (false).
o Beim Import aus UNI*C und TIETO/IST gilt: Steht der Parameter auf false, wird nur
die Hauptgruppe importiert. Das ist typischerweise die Klasse des*r Schüler*in. Wird er auf true gesetzt, werden alle
Gruppen importiert, die einem*r Kund*in in UNI*C oder TIETO/IST zugeordnet sind. Dazu zählen
häufig zahlreiche Fachgruppen. -
<Guardian> Dies ist nur beim Import aus UNI*C, TIETO und IST relevant. Wird dieser auf
true gesetzt oder ist nicht gesetzt, werden wirtschaftlich Verantwortliche zu den Kund*innen importiert. Steht er auf false,
werden diese nicht importiert. Standardmäßig aktiviert. -
<OverwritePhoneNumbers> Steht dieser auf true, werden bestehende Telefonnummern
überschrieben/gelöscht. - <OverwriteEmails> Steht dieser auf true, werden bestehende E-Mails überschrieben/gelöscht.
- <OverwritePickupBranch> Steht dieser auf true, wird der Bevorzugte Abholort der Kund*innen überschrieben.
-
<EnableNotificationOnDataUpdate><SMS> Steht dieser auf true, werden SMS-Mitteilungen
für die importierte Mobilnummer aktiviert, sofern der*die Kund*in noch keine Mobilnummer
für Mitteilungen hinterlegt hat. -
<EnableNotificationOnDataUpdate><Email> Steht dieser auf true, werden E-Mail-Mitteilungen
für die importierte E-Mail-Adresse aktiviert, sofern der*die Kund*in noch keine E-Mail-Adresse für Mitteilungen hinterlegt hat. -
<EnableNotificationOnDataUpdate><DigitalPost> Steht dieser auf true, werden Digital-Post-
Mitteilungen für eine*n Kund*in aktiviert, sofern der*die Kund*in erstmals importiert wird. -
<UseCPRasUserId> Steht dieser auf true, wird eine Kund*innen-ID vom Typ
„Gesundheitskarte“ mit der CPR-Nummer des*r Kund*in angelegt. Vorausgesetzt, die CPR-Nummer
wird importiert und ist vorhanden. -
<NotifyNewPatron> Steht dieser auf true, werden „Willkommen für neue Kund*innen“-E-Mails an
Kund*innen versandt, die durch den Import angelegt werden. - <SkipEmailIdentifier> Steht dieser auf true, werden die E-Mail-Adressen der Kund*innen beim Import aus Tieto, IST, Schoolsoft oder Feide nicht als Identifier verwendet. Dies sollte aktiviert werden, wenn mehrere Kund*innen dieselbe E-Mail-Adresse besitzen (was z. B. der Fall sein kann, wenn Schüler*innen mit der E-Mail-Adresse ihrer Eltern erfasst sind), da der Import andernfalls fehlschlägt.
- <AutoDeletePatronsWithOutstandings> Steht dieser auf true, werden Kund*innen in der Gruppe „Ausgeschieden“ automatisch gelöscht, auch wenn sie noch aktive Ausleihen oder andere Außenstände haben. Mehr dazu unter Verwaltung ausgeschiedener Schüler*innen.
- <AutoDeleteReservationsOnBranchTransfer> Steht dieser auf true, werden bei Kund*innen, die innerhalb derselben Agentur die Schule wechseln, alle Reservierungen gelöscht, deren Abholzweigstelle auf die vorherige Schule eingestellt ist.
Neben der Konfiguration der verschiedenen Kund*innenimport-Regeln muss auch konfiguriert werden, welcher Kund*innenimport-Webservice verwendet werden soll. Cicero unterstützt folgende Integrationen:
- Infodienst von UNI-Login (ws17)
- UC-Kund*innenimport-Service
- Tieto, IST, Schoolsoft, Feide
- CSV-Dateien
Infodienst von UNI-Login (ws17)
Soll dieser Service angebunden werden, muss <UNICImport/> im <Service>-Element ergänzt werden, sodass
es wie folgt aussieht:
<ImportLoanerConfiguration>
<Service>
<UNICImport/>
</Service>
…
</ImportLoanerConfiguration>Voraussetzung für einen Kund*innenimport mit dem Infodienst von UNI-Login ist eine genehmigte Datenvereinbarung
zwischen KOMBIT bzw. Systematic und der jeweiligen Schule.
Die Bibliothek muss „KOMBIT A/S Infotjeneste ws17“ den Zugriff auf die Daten über https://tilslutning.stil.dk/tilslutning/.
Weitere Informationen gegebenenfalls in der Dokumentation von STIL oder unter FBS integration to STIL Infotjenesten.
UC-Kund*innenimport-Service
Soll dieser Service angebunden werden, muss Folgendes im <Service>-Element stehen:
<ImportLoanerConfiguration>
<Service>
<UCImport>
<ServiceURL>URL</ServiceURL>
<UcKortNavn>name</UcKortNavn>
<ApiKey>key</ApiKey>
</UCImport>
</Service>
…
</ImportLoanerConfiguration>- <ServiceURL>: Die URL des UC-Kund*innenimport-Webservices.
- <UcKortNavn>: Der Kurzname der Einrichtung.
- <ApiKey>: Ein Shared Secret.
Tieto, IST, Schoolsoft, Feide
Soll dieser Service angebunden werden, muss <Import/> im <Service>-Element ergänzt werden, sodass
es wie folgt aussieht:
<ImportLoanerConfiguration>
<Service>
<Import>
<UseImportHierarchy>true/false</UseImportHierarchy>
</Import>
</Service>
…
</ImportLoanerConfiguration>
<UseImportHierarchy>:
Boolescher Wert, der festlegt, ob die Kund*innengruppen-Hierarchie in Cicero die Gruppenhierarchie aus der externen Datenquelle widerspiegeln soll. Standardmäßig ist dieser auf „False“ gesetzt.
Es kann sinnvoll sein, ihn auf „True“ zu setzen, wenn mehrere Schulen dieselbe Bibliothek (Zweigstelle) nutzen. Sind
mehrere Schulen unter derselben Zweigstelle, während der boolesche Wert auf „False“ steht, lässt sich nicht erkennen,
zu welcher Schule die einzelne Klasse gehört. Haben die Schulen Klassen mit identischem Namen, werden diese in Cicero
als eine Klasse angelegt. Wir empfehlen daher, den booleschen Wert in diesen Fällen auf „True“ zu setzen, da
dies eine zusätzliche Ebene in der Kund*innengruppen-Hierarchie einfügt, mit der sich die Schulen voneinander unterscheiden lassen.
Das bedeutet allerdings, dass alle Schulen eine zusätzliche Ebene erhalten – nicht nur die Schulen, an denen mehrere Schulen pro
Bibliothek (Zweigstelle) vorhanden sind.
Beispiele:
False: In Cicero wird eine Kund*innengruppen-Hierarchie wie folgt angelegt:
- All
Zweigstelle A
▪ Elever
• Klasse A
• Klasse B
Zweigstelle B
▪ Elever
• Klasse A
• Klasse B
True: In Cicero wird eine Kund*innengruppen-Hierarchie wie folgt angelegt:
- All
Zweigstelle A
▪ Elever
• Skole A
o Klasse A
o Klasse B
• Skole B
o Klasse A
o Klasse B
Zweigstelle B (Skole C)
▪ Elever
• Skole C
o Klasse A
o Klasse B
CSV-Dateien
Beim Import aus CSV-Dateien spielt das <Service>-Element keine Rolle und kann daher leer bleiben:
<ImportLoanerConfiguration>
<Service></Service>
…
</ImportLoanerConfiguration>Mehr zum Import per CSV-Datei unter Kundenimport.