24. Noodsysteem voor de leen in Brocade

Auteur

Richard Philips

Aanmaak

28 jan 2003

Aangepast door

Tom De Mey

Aangepast op

18 apr 2023

Oud BVV nr

2045

24.1. Abstract

Dit document beschrijft de werking van het noodsysteem voor de leen in Brocade. Het document bevat informatie over

24.2. Inleiding

Het noodsysteem voor de leen gaat uit van een minimale infrastructuur. Het noodsysteem moet kunnen werken zonder netwerking (geen netwerkconnectie met Brocade, en/of geen intern netwerk mogelijk) en dus ook zonder meta-informatie in verband met de leen en de eindgebruikers. Dit betekent dat de doelstellingen ook minimaal zijn. Het noodsysteem zorgt voor:

  • registratie van uitleen (op naam)

  • registratie van inname (anoniem)

  • registratie van verlenging (alle geleende beschrijvingen)

  • bijhouden van allerlei opmerkingen gemaakt door het personeel

Het noodsysteem doet NIET aan:

  • controle op maximum aantallen

  • kassatransacties (bij inname of leen)

  • boetesituaties

  • kastickets

De gekozen opzet heeft heel wat voordelen:

  • het systeem is onafhankelijk van (snel veranderende) leenparameters

  • kan ingezet worden zowel op een standalone PC als op een lokaal netwerk

  • kan gebruikt worden samen met een online leensysteem. Dit is van groot belang als er diverse filialen zijn binnen een leensysteem waarvan er sommige online zijn en andere niet.

  • het noodsysteem kan ook gebruikt worden bij mobiele filialen.

Het noodsysteem bestaat uit twee elementen :

  • een speciale software : localexec (te downloaden via het Software archief [link] ). Voor meer info over Localexec, zie documentatie over localexec

  • een speciale software : emergencywindows (te downloaden via het Software archief [link] ).

24.3. Installatie van het noodsysteem

Het noodsysteem dient lokaal op de baliepc geïnstalleerd te worden. De verwerking van de leengegevens gebeurt lokaal via de client, en de leentransacties worden weggeschreven in een bestand op die baliepc. Het noodsysteem kan dus nog werken als het lokale netwerk uitvalt, of als er helemaal geen netwerk is (niet in het netwerk verbonden pc, in bv. een bibliobus). Nadeel is dat de installatie op elke pc moet uitgevoerd worden, en dat de upload naar Brocade, als het netwerk hersteld is, op elk toestel apart moet gebeuren.

Volgende handelingen dienen uitgevoerd op elke baliepc :

  1. Installeer localexec

  2. Installeer emergencywindows

  3. Open de client via de rechtermuisknop op het icoontje van localexec

    Geef ter hoogte van het veld <werkstation> de passende identificatie van het werkstation in Brocade in.

  4. U kan nu leenacties uitvoeren via de client.

24.4. Transacties registreren met het noodsysteem

  • Start de client van het noodsysteem op via ´´Localexec´´.

  • Voor identificatie van eindgebruikers en objecten is de barcode noodzakelijk.

  • Bij registratie van verlengingen worden ineens alle werken verlengd ; het is niet mogelijk om een keuze te maken.

  • Je kan verschillende soorten opmerkingen registreren. Zo kan je bv. een nieuwe lener inschrijven, als je zorgt dat alle noodzakelijke gegevens genoteerd worden : naam, adres, gebruikersklasse, statistische codes, barcode.

  • Transacties worden weggeschreven in een bestand op C:Localexecxml, van de vorm : nsfinal.xx.xml, waarbij xx staat voor het nummer van de sessie.

24.5. Verwerken van het finale bestand met leentransacties

Alvorens de transacties, geregistreerd met het noodsysteem, op te laden in Brocade, raden we aan contact op te nemen met de Helpdesk van ANET. Zij kunnen assistentie verlenen bij de verdere procedures.

Volledigheidshalve volgt hieronder de hele procedure die moet doorlopen worden.

Het finale bestand - aangegeven in de beheersmodule - moet eerste worden geüpload via de toepassing Leen - Beheersfuncties - Verwerk leengegevens met het noodsysteem [link]

De volgende stappen dienen in deze volgorde uitgevoerd te worden :

  1. Controleer het leensysteem en vraag een nieuwe verwerking aan

  2. Laad dan de gegevens van het noodsysteem op (radio-button aanklikken en registreren)

Indien er verschillende upload files zijn, dan kan deze operatie verschillende keren worden uitgevoerd. Elke upload file (een XML file) is voorzien van een digest. Deze elektronische handtekening verhindert het dubbel opladen van gegevens.

Het is mogelijk dat deze digest ontbreekt, bijvoorbeeld omdat het noodsysteem niet correct werd afgesloten. In dat geval voldoet het op te laden bestand niet aan de vereisten en zullen de gegevens niet verwerkt kunnen worden. Je kan dit probleem omzeilen door het XML bestand in kwestie te editeren. Zet in dat geval de waarde van het attribuut digest op ok. (voorbeeld: <EMERGENCY sessionid="2" digest="ok">

Het tijdselement is van groot belang: de transactietijden worden met elkaar vergeleken en ook met de transacties uitgevoerd op de Brocade server. Vandaar dat het ook belangrijk is alle bestanden op te laden vooraleer over te gaan tot de volgende stappen in de verwerking.

  1. Vraag dan de statistieken op

  2. Verwerk de opmerkingen. Hier kunnen ook nieuwe leners worden ingeschreven

  3. Verwerk de transacties en sluit de verwerking af

  4. Op het volgende scherm verschijnt nu een hyperlink naar het csv-bestand dat alle transacties bevat die Brocade verwerkt heeft. Deze verweringsrapport is cumulatief voor alle opgeladen bestanden, en maakt het mogelijk om na te gaan of leentermijnen, enz. correct geregistreerd werden.

24.6. Interpretatie van het verwerkingsrapport in csv-formaat

Download het csv-bestand naar je lokale PC en open het met Excel of een andere spreadsheet-software. Het bestand geeft een rapport over de verwerking van de data in het levend Brocade systeem. Het rapport bevat de volgende gegevens

  • object : o-loi van het object. In het noodsysteem worden enkel streepjescodes geregistreerd. Bij het opladen gebruikt Brocade de streepjescodes om de juiste objecten terug te vinden. Indien geen object wordt gevonden, creëert Brocade een tijdelijke beschrijving die in het verwerkingsrapport herkenbaar is als een object met een nummer voorafgegaan door een uitroepteken (bijv. !234).

  • action : De code in deze kolom geeft aan om wat voor leentransactie het precies gaat. Mogelijke waarden zijn

    • in: inname

    • out: uitleen

    • agn: verlenging

  • cost : Indien de transactie een bepaalde kost genereerde (bijv. leengeld), dan wordt het bijhorende bedrag in deze kolom genoteerd. Het type van aangerekende kost wordt vermeld in de kolom ktrans. De munteenheid van het aangerekende bedrag staat in de kolom munt.

  • date : Tijdstip van de transactie. Dit is het tijdstip waarop in het noodsysteem de transactie geregistreerd werd. Brocade gebruikt dit tijdstip om de transactie correct te kunnen filen. Het is mogelijk dat omwille van dit tijdstip bepaalde transacties niet worden opgeslagen en dit om inconsistenties in de leen te vermijden. In dat geval wordt de transactie geweigerd en staat de reden van weigering in de kolom reject.

  • euser : Geef de e-loi van de gebruiker bij wie de transactie geregistreerd werd. In het noodsysteem worden enkel streepjescodes van lezers geregistreerd. Bij het opladen gebruikt Brocade de streepjescodes om de juiste lezer terug te vinden. Indien Brocade met de gegeven streepjescode de lezer niet kan terugvinden, wordt de transactie weggeschreven bij een dummy gebruiker (bijv. Noodsysteem). Deze dummy gebruiker wordt gedefinieerd in Leen - Beheersfuncties - Leensystemen [link].

  • euserc : Geeft de gebruikersklasse van de lezer (zie onder euser) die betrokken is bij de transactie.

  • ktrans : Zie bij cost

  • munt : Zie bij cost

  • objc : Geeft de objectklasse van het object (zie onder object) dat betrokken is bij de transactie.

  • reject : Sommige transacties die in het noodsysteem werden geregistreerd kunnen niet door Brocade worden verwerkt. Hiervoor kunnen verschillende redenen bestaan. Onthoud wel dat bij het verwerken van de leentransacties uit de opgeladen noodbestanden telkens eerst gekeken wordt naar de meest actuele status in de databank. Indien de noodtransacties minder actueel zijn dan wat in de databank van Brocade online geregistreerd staat, worden deze specifieke noodtransacties niet verwerkt. Soms kan de weigering van transacties veroorzaakt zijn door een verkeerde tijdsinstelling op de PC waarop het noodsysteem wordt gebruikt. Tijdsynchronisatie is dus heel belangrijk. Zie daarover meer in BVV-2049.

    • action = out en reject = in

      Dit betekent: in het noodsysteem werd een uitleen geregistreerd, maar de transactie kan niet worden opgenomen omdat er voor dat object in de online databank een inname is geregistreerd van latere datum.

      Te ondernemen actie: verificatie op het rek en vooralsnog toch het object uitlenen aan de desbetreffende lezer.

    • action = out en reject = out

      Dit betekent: in het noodsysteem werd een uitleen geregistreerd, maar de transactie kan niet worden opgenomen omdat er voor dat object in de online databank een uitleen is geregistreerd van latere datum.

      Te ondernemen actie: in principe geen buiten misschien verificatie of het boek in het systeem staat genoteerd bij dezelfde gebruikers als degene aan wie het werd uitgeleend in het noodsysteem.

    • action = in en reject = not out

      Dit betekent: in het noodsysteem werd een inname geregistreerd, maar op dat ogenblik was het object niet uitgeleend.

      Te ondernemen actie: in principe geen buiten misschien verificatie op het rek om te zien of het object inderdaad beschikbaar is.

    • action = in en reject = in

      Dit betekent: in het noodsysteem werd een inname geregistreerd, maar er bestaat voor dat object een inname van recentere datum.

      Te ondernemen actie: in principe geen buiten misschien verificatie op het rek om te zien of het object inderdaad beschikbaar is.

  • transco : Elke verwerking in de leen - en dus ook de verwerking van transacties uit het noodsysteem - krijgt een afzonderlijk transactienummer. Met dit nummer kan je eventueel de details van de transactie opvragen via Leen - Beheersfuncties - Bekijken van de leentransacties [link].

  • until : Geeft de datum van teruggave voor transactie van het type out en agn

  • wks : Geeft het werkstation waar de transactie plaatsgreep. Indien in het noodsysteem geen werkstation werd vastgelegd, wordt de transactie weggeschreven bij een default werkstation. Dit default werkstation wordt gedefinieerd in Leen - Beheersfuncties - Leensystemen [link].

24.7. Voorbeeld van een verwerkingsrapport

verwerkingsrapport

object

action

cost

date

euser

euserc

ktrans

munt

objc

reject

transco

until

wks

o:ob:1220195

out

30/07/2003 8:31

e:OBA:12157

VBI

in

couwelaar-AVM

o:ob:1312382

in

30/07/2003 7:44

e:OBA:340240

ADM

VF1

not out

couwelaar-AVM

o:ob:1330470

in

30/07/2003 18:29

e:OBA:340240

ADM

in

couwelaar-AVM

o:ob:1216782

in

30/07/2003 7:20

e:OBA:27633

ADM

CD1

3312372

couwelaar-AVM

o:ob:1374686

in

30/07/2003 7:20

e:OBA:27633

ADM

CD1

3312373

couwelaar-AVM

o:ob:1380722

in

30/07/2003 7:20

e:OBA:27633

ADM

CD1

3312374

couwelaar-AVM

o:ob:1043821

out

1

30/07/2003 7:21

e:OBA:27633

VBI

L-V1

EUR

JV1

3312381

27/08/2003

couwelaar-AVM

o:ob:1098314

out

1

30/07/2003 7:21

e:OBA:27633

VBI

L-V1

EUR

JV1

3312382

27/08/2003

couwelaar-AVM

o:ob:1046030

agn

0

30/07/2003 9:02

e:OBA:11905

VBI

NF

3312551

27/08/2003

couwelaar-v

o:ob:1164859

out

0

30/07/2003 10:13

e:OBA:18947

S

F

3312667

27/08/2003

couwelaar-v

Op basis van het verwerkingsrapport kijk je best volgende zaken na:

  • Kijk de transacties na die geregistreerd staan bij de dummy gebruiker Noodsysteem

  • Kijk de objecten na die een dummy objectcategorie hebben gekregen

  • Kijk de objecten na die een dummy werkstation hebben gekregen

  • Kijk de transacties na die geweigerd werden door Brocade (kolom reject)

24.8. Parameters in het leensysteem ten behoeve van het noodsysteem

Op het ogenblik van verwerking van de bestanden geleverd door het noodsysteem, zijn de echte transacties al achter de rug. Dit betekent nog dat deze transacties in alle omstandigheden dienen uitgevoerd te worden op de Brocade server. Het leensysteem bezit enige parameters om dit mogelijk te maken:

  • nswks: Default werkstation voor het noodsysteem

    Deze waarde wordt gebruikt indien de transactiegegevens geen indicatie bevatten voor het werkstation. Dit kan enkel gebeuren indien de gebruikers van het noodsysteem een onvolledige URL activeren: vb. http://localhost:7765/emergency wordt geactiveerd in de plaats van http://localhost:7765/emergency?wks=ANET-TEST

  • nsuser: Default eindgebruiker voor het noodsysteem

    Aan de hand van de streepjescode wordt de eindgebruiker geïdentificeerd. Het kan gebeuren dat dit niet leidt tot identificatie (bijvoorbeeld: de streepjescode werd slecht ingescand). De transactie wordt dan uitgevoerd op naam van de gebruiker die in dit veld werd ingevuld. Daardoor blijft opvolging en inname van die boeken toch min of meer mogelijk. Het spreekt vanzelf dat deze gebruiker in het passende eindgebruikerssysteem moet worden aangemaakt en dat hij "ruime" bevoegdheden moet hebben. Indien blijkt dat de gebruiker geen ingevulde lenersklasse heeft, dan wordt de klas genomen van nsuser

  • nsobjc: Default object categorie voor het noodsysteem

    Objecten worden eveneens geïdentificeerd door een streepjescode en ook daar kunnen zich problemen voordoen. Indien het object niet werd gevonden, dan wordt er een object gedefinieerd (catalografie in de leen) dat de objectklasse nsobjc krijgt. nsobjc wordt ook nog gebruikt bij het uitvoeren van de transactie zelf: blijkt het dat de transactie niet kan doorgaan onder de normale objectklasse, dan wordt de transactie overgedaan met de code nsobjc.

  • nsextern: Externe factor voor het noodsysteem

    Deze code geeft aan welke externe factor wordt gebruikt bij het verwerken van de leentransacties. Het is belangrijk om de parameters hierbij zo te nemen dat alle leentransacties kunnen worden uitgevoerd. Vergeet niet dat de leentransactie in de realiteit is uitgevoerd.

Voor alle leensystemen in Brocade zijn deze parameters op voorhand en voorlopig gedefinieerd.

24.9. Back-up procedure voor het noodsysteem

Als de noodsituatie zich voordoet over verschillende dagen, dan is het aangewezen om op het einde van de werkdag de back-up optie uit te voeren. De back-up mag overigens meerdere keren worden uitgevoerd.

Per sessie wordt deze back-up verzameld in een gecomprimeerd bestand, van de vorm xx.gz", waarbij xx staat voor de lopende sessie van het noodsysteem. Bij elke nieuwe back-up wordt, per sessie, een nieuw gecomprimeerd bestand aangemaakt, met dezelfde naam, dat alle gecumuleerde gegevens bevat.

Als het om een of andere reden nodig is om terug te vallen op de gegevens van de back-up (omdat de bestanden van het noodsysteem corrupt zijn, of omdat er een schijffout is, enz.), dan raden we aan contact op te nemen met de Helpdesk van ANET. Zij kunnen assistentie verlenen bij het herstellen via back-up.

Volledigheidshalve volgt hieronder de procedure :

  • als het mogelijk is, sluit dan de lopende sessie

  • open een nieuwe sessie

  • registreer nieuwe leentransacties

  • als de noodsituatie voorbij is, sluit dan de sessie

  • decomprimeer het "xx.gz" bestand ; het uitgepakte bestand zal gewoon "xx" heten. Hernoem het in "nsfinal.xx.xml"

  • laad eerst het back-up bestand "nsfinal.xx.xml" op, en dan de bestanden van de latere sessies

  • de volgende stappen zijn dezelfde als bij een normale procedure

24.10. Tips voor het oplossen van probleemsituaties

Stel dat er bij het verwerken van de bestanden uit het noodsysteem iets fout gaat, dan zijn er in feite 2 mogelijk probleemsituaties voor wat de leenstatus van objecten betreft :

  • probleem 1: een object heeft in de databank online de status "uitgeleend" terwijl het in werkelijkheid al is ingenomen. Het blijft dan bij de lezer X geregistreerd staan, en dat kan op termijn leiden tot onterechte boetes. Dat is vervelend, maar op zich niet zo heel erg, omdat de werkelijke status van het object makkelijk op het rek kan gecontroleerd worden, of, als het ondertussen al opnieuw is uitgeleend, in Brocade, als het staat uitgeleend bij een andere lener Y. (in dat laatste geval wordt er een NNT aangemaakt bij lezer X).

  • probleem 2 : een object heeft in de databank online de status "beschikbaar" terwijl het in werkelijkheid is uitgeleend. Dat is vervelender, omdat je daardoor niet kan detecteren bij welke lezer het object zich bevindt.

Wanneer kunnen deze problemen zich voordoen ? Daarvoor is het belangrijk om weten dat bij het verwerken van de leentransacties uit de opgeladen noodbestanden telkens eerst gekeken wordt naar de meest actuele status in de databank. Indien de noodtransacties minder actueel zijn dan wat in de databank van Brocade online geregistreerd staat, worden deze specifieke noodtransacties niet verwerkt. Dus:

  • probleem 1 zal zich kunnen voordoen als noodbestanden niet correct zijn verwerkt (niet allemaal, of niet allemaal tegelijk). De enige controle die je daarbij hebt, zijn de eindrapporten (csv-bestanden van de verwerking) waar een foutcode staat bij de betreffende transacties. Maar als deze csv-bestanden zeer veel transacties bevatten, is controle daarvan misschien niet realistisch.

  • probleem 1 kan zich ook voordoen als de noodbestanden pas verwerkt worden nadat het online systeem al (enige tijd) terug in gebruik genomen is. Je hebt hier een zekere controle over, omdat het dan zou kunnen gebeuren dat je online een boek inneemt dat in de databank nog de status "beschikbaar" heeft - en dat genereert een foutmelding (gebruiker/object is niet gekend). In dat geval kan je afspreken om dergelijke objecten even opzij te leggen en uit te zoeken wat er aan de hand is.

  • probleem 2, het meest vervelende probleem, zal zich enkel kunnen voordoen indien uitleentransacties niet geregistreerd worden of indien er een noodbestand niet is opgeladen en verwerkt. Daar heb je verder geen controle over.

Conclusie :

  • het belangrijkste is om, na het gebruik van het noodsysteem, eerst alle bestanden (van alle werkstations) op te laden en dan pas te verwerken, en er voor te zorgen dat alles verwerkt wordt. Daarvoor moet je procedures afspreken intern, over taakverdeling, communicatie, enz. Ook het coördineren van het opladen van de bestanden is heel belangrijk. Indien op verschillende vestigingen terzelfdertijd opgeladen wordt, kunnen die acties elkaar doorkruisen, waardoor er misschien sommige bestanden niet opgeladen worden. Dus : opladen vestiging NA vestiging, en in elke vestiging pc/werkstation NA pc/werkstation

  • het is minder belangrijk om de noodbestanden onmiddellijk te verwerken nadat er terug met het online systeem kan gewerkt worden. Je zou dat verwerken eventueel op een later tijdstip kunnen uitvoeren.