7. Staten in Impala

Auteur Richard Philips
Aanmaak 8 april 2004
Oud BVV nr 2079

7.1. Abstract

Dit document beschrijft de staten die een Impala request kan doorlopen. Ook de ‘events’ die leiden tot een staat overgang wordt vermeld.

7.2. Staten

" "
Een Impala aanvraag heeft de lege staat zolang hij niet in het Impala circuit terecht komt. Dit doet zoch voor bij de opbouw van een aanvraag: het Impala nummer werd reeds toegekend, maar niet alle gegevens zijn voorhanden om een volwaardige beschrijving te hebben.
active

De Impala aanvraag is compleet en wordt in het Impala circuit geplaatst. Deze staat bestaat slechts even. Er zijn vier mogelijke (automatische) overgangen:

atsupplier-unaware De eerste beschikbare supplier wordt aangeduid.
finished-failed-nosuppliers Er zijn geen beschikbare leveranciers meer.
finished-failed-timeout De aanvrager vindt dat de aanvraag reeds te lang in het systeem zit (parameter bij de aanvrager).
finished-stopped De aanvrager stopt de aanvraag.
finished-failed-nosuppliers
Eindstaat
finished-failed-timeout
Eindstaat
finished-stopped
Eindstaat
atsupplier-unaware

De Impala aanvraag wacht op verwerking door de leverancier. Van hieruit zijn er de volgende overgangen mogelijk:

atsupplier-unaware-timeout De leverancier wacht te lang met het bekijken van de aanvraag (parameter bij de aanvrager).
atsupplier-unaware-stopped De aanvrager trekt de aanvraag terug.
atsupplier-unaware-skipped De aanvrager trekt de aanvraag terug bij de huidige leverancier.
atsupplier-aware De leverancier begint de verwerking van de aanvraag.
finished-success-delivered De aanvrager bevestigt de ontvangst van de aanvraag.
atsupplier-unaware-timeout
De staat gaat automatisch over op active.
atsupplier-unaware-stopped
De staat gaat automatisch over op finished-stopped.
atsupplier-unaware-skipped
De staat gaat automatisch over op active.
atsupplier-aware

De leverancier neemt de aanvraag in behandeling. Van hieruit zijn er weer diverse andere staten mogelijk:

atsupplier-aware-timeout De leverancier wacht te lang met het afwerken van de aanvraag. Een parameter bij de aanvrager geeft aan hoelang dit mag duren.
atsupplier-aware-rfi De leverancier vraagt bijkomende informatie.
atsupplier-success De leverancier kan leveren.
atsupplier-failure De leverancier erkent dat hij niet levert.
finished-success-delivered De aanvrager bevestigt de ontvangst van de aanvraag.
atsupplier-released
De staat gaat automatisch over op active.
atsupplier-aware-timeout
De staat gaat automatisch over op active.
atsupplier-aware-rfi

De leverancier heeft de aanvraag in behandeling en heeft een vraag om meer informatie. Van hieruit zijn er weer diverse andere staten mogelijk:

atsupplier-aware-timeout De leverancier wacht te lang met het afwerken van de aanvraag. Een parameter bij de aanvrager geeft aan hoelang dit mag duren.
atsupplier-aware-rfi-answer De leverancier krijgt bijkomende informatie.
atsupplier-success De leverancier kan leveren.
atsupplier-failure De leverancier erkent dat hij niet levert.
atsupplier-redirect De leverancier redirect de aanvraag naar een andere leverancier.
atsupplier-aware-rfi-answer
De staat gaat automatisch over op atsupplier-aware.
atsupplier-failure
De staat gaat automatisch over op active.
atsupplier-redirect
De staat gaat automatisch over op active.
atsupplier-success

De aanvraag is succesvol afgehandeld. Toch zijn er nog twee staten mogelijk:

finished-success-timeout Een parameter bij de aanvrager zorgt voor de automatische overgang.
finished-success-delivered De aanvrager erkent dat de leverancier heeft geleverd.

7.3. Staten bij leveranciers

Sommigen van deze staten worden ook bij de leverancier bewaard. Het is de laatste staat die relevant is voor de leverancier. Tegelijk wordt ook de datum ($H-formaat) bijgehouden.

atsupplier-unaware
atsupplier-released
atsupplier-unaware-skipped
atsupplier-unaware-stopped
atsupplier-aware
atsupplier-redirected
atsupplier-aware-timeout
atsupplier-success
atsupplier-failure

7.4. Staatovergangen

_images/bvv-2079transits.jpg
  Van   naar Wanneer? Initiator Voorwaarden
[1] active atsupplier-unaware Ogenblikkelijk Systeem
Voorwaarden:
- Param(“next”)=1 (user interface: de aanvrager plaatst een aanvraag)
- De ‘volgende’ supplier bestaat

In Param(“supplier”) komt de index van de nieuwe leverancier
[2] active finished-failed-nosuppliers Ogenblikkelijk Systeem Er zijn geen suppliers meer (automatisch).
[3] active finished-failed-timeout Ogenblikkelijk Systeem De aanvraag overschrijdt zijn maximale levensduur (automatisch).
[4] atsupplier-unaware atsupplier-aware Supplier ziet de aanvraag Supplier Via de gebruikers interface wordt Param(“aware”)=1 gezet.
[5] atsupplier-unaware atsupplier-unaware-stopped Aanvrager stopt de aanvraag Aanvrager Via de gebruikersinterface heeft de aanvrager een “stop” gescheduled. Is de aanvraag in de staat atsupplier-unaware, dan wordt de status naar atsupplier-unaware-stopped gebracht.
  Van   naar Wanneer? Initiator
[6] atsupplier-unaware atsupplier-unaware-timeout Systeem merkt de timeout Systeem
[7] atsupplier-unaware atsupplier-unaware-skipped De aanvrager skipped de aangesproken leverancier Aanvrager
[8] atsupplier-aware atsupplier-unaware Leverancier zet de aanvraag terug op unaware Leverancier
[9] atsupplier-unaware-skipped active Ogenblikkelijk Systeem
[10] atsupplier-unaware-timeout active Ogenblikkelijk Systeem
[11] active finished-stopped Ogenblikkelijk Systeem
[12] atsupplier-aware atsupplier-success Supplier levert Supplier
[13] atsupplier-aware atsupplier-aware-rfi Supplier vraagt info Supplier
[14] atsupplier-aware atsupplier-failure Supplier levert niet Supplier
[15] atsupplier-aware atsupplier-redirect Supplier redirect de aanvraag Supplier
[16] atsupplier-aware atsupplier-aware-timeout Systeem merkt de timeout Systeem
[17] atsupplier-aware finished-success-delivered De aanvrager bevestigt de levering Aanvrager
[18] atsupplier-aware-timeout active Ogenblikkelijk Systeem
[19] atsupplier-redirect active Ogenblikkelijk Systeem
[20] atsupplier-failure active Ogenblikkelijk Systeem
[21] atsupplier-aware-rfi atsupplier-failure Supplier levert niet Supplier
[22] atsupplier-aware-rfi atsupplier-redirect Supplier redirect de aanvraag Supplier
[23] atsupplier-aware-rfi atsupplier-aware-timeout Systeem merkt de timeout Systeem
[24] atsupplier-aware-rfi atsupplier-success Supplier levert Supplier
[25] atsupplier-aware-rfi atsupplier-aware-rfi-answer Aanvrager geeft info Aanvrager
[26] atsupplier-aware-rfi-answer atsupplier-aware Ogenblikkelijk Systeem
[27] atsupplier-success finished-success-delivered Aanvrager bevestigt de levering Aanvrager
[28] atsupplier-success finished-success-timeout Systeem merkt de timeout Systeem

7.5. Bibliotheken in Impala

Het is niet altijd even duidelijk wat precies een bibliotheek, aanvrager of een leverancier is in Impala. Deze schijnbaar eenvoudige concepten verbergen subtiliteiten die voor een goede werking van Impala aan verklaring toe zijn.

libloi
Dit is een nummer dat verwijst naar een datastructuur die opgeslagen wordt in de ^ULIB-global. Een libloi staat voor wat we het best kunnen omschrijven als een rechtskundige entiteit. Aan deze entiteit kunnen we bijvoorbeeld allerhande adressen associeren. Algemeen gezegd kunnen we stellen dat we aan een libloi verantwoordelijkheden en rechten kunnen toemeten. Een voorbeeld: UA staat voor een libloi.
catlibs
Dit zijn acroniemen die worden gebruikt binnen catalografische beschrijvingen. De gegevens die worden bewaard bij een catlib hebben te maken met het catalografisch proces. In veel gevallen kan men de catlib ondubbelzinnig associeren met een libloi. Toch kan het ook zijn dat verschillende catlibs worden geassocieerd met een en dezelfde libloi. Een voorbeeld: UA-CDE, UA-CMI, UA-CST zijn catalografische instellingen die allen geassocieerd zijn met UA.
werkomgevingen
Er zijn de mensen die willen werken met Impala. Deze mensen zijn gelokaliseerd op een bepaalde campus in een bepaald gebouw (vb. iemand die werkt in Leeszaal R op Campus Drie Eiken van de UA; of iemand die werkt in filiaal Sint-Anneke van de Openbare Bibliotheek Antwerpen. Het spreekt vanzelf dat deze personen gerichte informatie moeten krijgen. Het is zinloos de eerste te laten werken als personeel van UA en de tweede als personeel van de OBA. Om dit probleem op te lossen wordt het concept van de werkomgevingen gedefinieerd.

7.6. De werkomgeving

Elke participant van Impala krijgt een URL van de vorm http://anet.be/impala/862. Deze URL is:

  • stabiel: de gebruiker kan een link leggen naar deze URL met de verzekering dat deze operationeel blijft.
  • het nummer is het nummer dat hoort bij de libloi.

Het ingangspunt in Impala wordt dus - zoals het hoort - bepaald door de rechtskundige entiteit. Deze entiteiten kunnen op hun rechten (bijvoorbeeld: uitnodigen om mensen te sturen om opleiding te volgen, ...) en hun verantwoordelijkheden (bijvoorbeeld: vragen dat ze regelmatig hun Impala aanvragen opvolgen, ...) worden gewezen.

Bij elke libloi worden een aantal werkomgevingen gedefinieerd. Dit zijn gegevens die ervoor zorgen dat het Impala systeem zich kan richten naar het specifieke werk dat de gebruiker wil doen. In het inlogscherm weet Impala reeds met welke libloi er wordt gewerkt. Het systeem toont dan welke werkomgevingen van toepassing zijn. De Impala gebruiker kiest dan de gewenste werkomgeving en komt dan - na authenticatie - terecht in een passende menustructuur.

Een voorbeeld:

Bij de libloi die staat voor UA horen de werkomgevingen: CDE, CST, CMI, CZU.

Selecteert de gebruiker CDE dan ziet hij enkel de aanvragen die gesteld zijn vanuit CDE en de aanvragen die kunnen worden geleverd vanuit CDE.

Om het inloggen en de keuze van werkomgeving extra gemakkelijk te maken, voorzien we een URL van de vorm http://anet.be/impala/862.cde. Hoewel minder stabiel dan de hoger genoemde URL is deze toch meer dan voldoende om eenvoudig en efficient de juiste werkomgeving op te zoeken. Authenticatie blijft natuurlijk nodig.

Op het niveau van de werkomgeving worden de volgende elementen beheerd:

  • Wordt deze werkomgeving gebruikt als aanvrager, leverancier of beiden?
  • Volgt de leverancier de aanvraag op via Impala? (problematiek van de fax-bibliotheken)
  • Een link met de libloi.
  • Een URL/Scope noot met meer informatie.
  • De geprefereerde taal (N, E, F, U, D, U).
  • Een link naar het leveradres (dit adres blijft wel beheerd binnen de libloi).
  • Een eigen mailbox voor elektronische leveringen.
  • Een clearing house code + datum voor eigen aanvragen.
  • Een clearing house code + datum voor ontvangen aanvragen.
  • Een lijst met andere werkomgevingen naarwaar er redirectie mag zijn.

Linken naar ‘externe’ databanken worden beheerd via de libloi.

Werkomgevingen worden beheerd via het Impala secretariaat.

7.7. Catalografische bibliotheken

Deze worden op dit ogenblik beheerd in ^UINST: de gegevens worden gewoon overgenomen uit ^ULIB. Dit betekent nog dat de acroniemen in de bibliografische databanken dezelfde moeten zijn als in Impala.

Catalografische bibliotheken moeten hun eigen weg kunnen gaan. Er moet echter wel een algoritme bestaan ter hoogte van een catalografische bibliotheek dat toelaat om op basis van de elementen:

  • de betreffende catalografische bibliotheek
  • het plaatskenmerk (boeknummer)
  • het genre

het koppel (libloi, werkomgeving) te bepalen. Dit algoritme moet ook kunnen werken als het plaatskenmerk en/of het genre ontbreekt.

7.8. Clearing House

Deze worden apart beheerd. Het zijn identifiers waaraan de volgende gegevens worden gespecificeerd:

  • Een scope note.
  • Adres om de factuur naar toe te sturen. Dit is opnieuw een link naar een bestaand adres in een libloi.
  • Een begeleidende tekst met de factuur. In deze tekst is ruimte voor 3 parameters (<startdate>, <enddate> en <money>).
  • Adres om een kredietnota naar toe te sturen. Dit is opnieuw een link naar een bestaand adres in een libloi.
  • Een begeleidende tekst met de kredietnota. In deze tekst is ruimte voor 3 parameters (<startdate>, <enddate> en <money>).
  • Kostprijs van het uitsturen van een factuur.
  • Kostprijs van het uitsturen van een kredietnota.

Deze werkwijze heeft een aantal extra mogelijkheden:

  • betaling door derden is mogelijk
  • groepering over diverse libloi is mogelijk
  • splitsing van inkomsten en uitgaven is mogelijk