Alma Aleph: Parallel Operations

(1)

DIE ÖSTERREICHISCHE BIBLIOTHEKENVERBUND UND SERVICE GMBH

Alma Aleph: Parallel Operations

Verbundtag 2018 , UB Klagenfurt 15.5.2018

Bettina Kann

Wolfgang Hamedinger

(2)

Parallelbetrieb ALEPH-ALMA Phase 2

(3)

Parallelbetrieb ALEPH-ALMA Phase 2

(4)

Alma Bridge Integration

54 Bridge IZs

Einzeln konfigurierbar

Abgleich mit tab_sublibrary (libraries) und tab40 (locations)

Laden der Konfiguration über configuration_form plus manuelle Nachbesserungen in einzelnen IZs

(5)

Alma Bridge Integration: Aleph Setup

 Neuer Expand: expand_doc_bib_hol_mab_alma Expand Holdings in BIB-Satz

 Bekannter Expand: expand_doc_bib_z30 Expand Items in BIB-Satz

 Aufsetzen des Publishings in tab_publish

 Run p_publish_04 (initial) und p_publish_06 für ongoing publishing

  Export von tar.gz Dateien

(6)

Alma Bridge Integration: Mapping ADM / sublibrary to Bridge IZ

Ursprünglicher Gedanke von Exl:

1:1 Beziehung Aleph ADM : Bridge IZ Bsp:

tab_sublibrary UAB  Annahme korrekt

(7)

Alma Bridge Integration: Mapping ADM / sublibrary to Bridge IZ Auswirkung der Annahme am Bsp. Holding

aseq: OWN$$aRUAB

200$$b27.1986 - 54.2013 etc.

Für Publishing der Holdings aus Aleph:

Nimm OWN$$a  gehe zu tab_sublibrary  extrahiere ADM Code aus Spalte 3

‚Exportergebnis:

</datafield>

[$$0 ist Systemnummer des Holdings, wird uns später noch begegnen]

Beim Import über Alma Bridge Integration UAB50  43ACC_BRIDGE_UAW

Bis hierher OK.

(8)

Aber: Annahme der 1:1 Beziehung FALSCH!

BMF, LOB, LOK … Multi-ADM, daher mehrere ADM Codes müssen auf eine Bridge IZ gemappt werden.

Bsp.: LBO

Holding:<datafield tag="OWN" ind1=" " ind2="9">

<subfield code="a">XOLMO</subfield>

</datafield>

Nur LBO50 43ACC_BRIDGE_LBO zugewiesen!

In Spalte 3 in tab_sublibrary ist XOLMO aber LBO51 zugeordnet!

(9)

(10)

Größtes Problem: nicht mehr aktive (= in tab_sublibrary auskommentierte oder nicht vorhandene Einträge)

Anforderung lt. CD-02: alle in BRIDGE_OBV

(11)

Lösung: neue in NZ konfigurierbare Tabelle mit individuellem Mapping

 336 Zeilen mussten manuell eingetragen werden!

(12)

Alma Bridge Integration: Mapping Holdings

Universal Holding Mapping oder: eines für alle, alle für eines

Ausgehend von Papier „lokale-zentrale Felder“

Problem 1: 200$$g (Sonderstandort)

Standort muss einer location in Alma entsprechen, wenn auf 852$$c gemappt  location in Alma muss tab.40 in Aleph entsprechen. Realität: in 200$$g steht alles mögliche. Dh. Mapping nach 852$$x, um

Information mitzunehmen

Resultat: ALLE Holdings stehen auf location

(13)

Alma Bridge Integration: Mapping Holdings

Problem 2: bc/bch Regel

Viele Holdings wäre „durchgefallen“, da nicht eindeutig.

Kreative Lösung:

OWN$$0Systemnummer des HOLs in Aleph wird nach 852$$l gemappt

(14)

Alma Bridge Integration: Mapping Holdings

Resultat in Alma: in NZ wird hinter Signatur in HOL der Aleph Bibliotheken die Aleph Systemnummer

angezeigt.

(15)

Alma Bridge Integration: Mapping Items

Vergleichsweise einfach, keine Überraschungen

Für jedes Item legt Bridge automatisch auch Holding an.

(16)

Alma Bridge Integration: Surprise, surprise 1

ALEPH

publishing

NZ Bridge

import

(17)

Alma Bridge Integration: Surprise, surprise 1

„Lösung?!“: Umpaketieren der tar.gz zu zip vor dem Import

(18)

Alma Bridge Integration: Surprise, surprise 2

Zu viele Dateien verderben die Bridge Integration

(19)

Alma Bridge Integration: Surprise, surprise 2

„Lösung?!“:

Anlegen von 25 (!) identen Bridge Integration Profiles

 jede verarbeitet nur 1 zip Datei

(20)

Alma Bridge Integration: Surprise, surprise 3

Definiere „Success“:

Es lagen ca. 5000 records zur Verarbeitung am FTP, verarbeitet wurden 0

(21)

Alma Bridge Integration: Surprise, surprise 3

„Lösung?!“: auspacken, wegschmeissen, einpacken und neu laden

(22)

Synchronisierung Alma  Aleph

Publishing BIB records aus Alma und Import in ACC01 via p_manage_18: stündlich; grundsätzlich OK, ABER:

(23)

Fazit

(24)

Vielen Dank für Ihre Aufmerksamkeit!