Eltűnő kulcsszavak és űrlap hibák DSpace 9-ben: A tag input és a kontrollált szótárak csapdája

Képzeld el a szituációt: felhúzod a vadonatúj, Angular-alapú DSpace 9-et, a felület gyönyörű, a kollégák pedig lelkesen elkezdenék feltölteni az intézményi anyagokat. Gondosan megadják a kulcsszavakat, rányomnak a mentésre, és bumm… A kulcsszavak vagy szőrén-szálán eltűnnek a publikálás után, vagy a rendszer egy kövér 500-as Internal Server Error kíséretében teljesen összeomlik.

A hiba gyökere egy ártatlannak tűnő svéd szótár és az Angular frontend “túlgondolt” adatközlése között keresendő.

A probléma gyökere: Mi az az SRSC és mit keres itt?

Ha belenézel a DSpace alapértelmezett submission-forms.xml fájljába, a kulcsszavakért felelős dc.subject mezőnél ezt a beállítást találod:

<input-type>tag</input-type>
<vocabulary>srsc</vocabulary>

A tag beviteli típus a modern DSpace felület csilivili “címkézője”, amely gépelés közben (autocomplete módon) próbálja kiegészíteni a szavakat. Ehhez viszont kötelezően szüksége van egy adatbázisra, egy REST API végpontra.

Ezt a szerepet tölti be az SRSC, ami nem más, mint a Swedish Research Subject Categories (Svéd Kutatási Tárgyszó-kategóriák) rövidítése. A DSpace fejlesztői egy létező, működő szótárral akarták demonstrálni a funkciót az alaptelepítésben, és erre esett a választásuk. Szép és jó, de egy többnyelvű (például magyar, ukrán, angol) repozitóriumban egy svéd tudományos kategóriarendszer teljesen használhatatlan.

Az adminisztrátor első, teljesen logikus lépése tehát: Töröljük ki a <vocabulary>srsc</vocabulary> sort az XML-ből, és hagyjuk meg a tag bevitelt, hogy a kollégák szabadon írhassanak.

És pont itt van a csapda.

A hiba anatomiája: Amikor a frontend összevész a backenddel

Amint kiveszed a szótárat a tag mező alól, a DSpace Angular frontendje megzavarodik. Mivel kötelezően várna egy szótárat a háttérben, az adatok beküldésekor elkezdi hibásan formázni a csomagot. Ha belenézünk a Tomcat szerver logfájljaiba, pontosan látjuk, mi történik:

Could not read [{"value":["аналіз"],"language":"uk", ...}]
Cannot deserialize value of type java.lang.String from Array value (token JsonToken.START_ARRAY) ... through reference chain: ... ->org.dspace.app.rest.model.MetadataValueRest["value"]

Mit jelent ez emberi nyelven?

A DSpace REST API-ja a szerver oldalon szigorúan elvárja, hogy egy kulcsszó értéke (value) egy egyszerű szöveg (String) legyen. Például így:

{"value": "аналіз"}

Ehelyett a megzavarodott böngésző (az Angular) feleslegesen becsomagolja az egészet egy tömbbe (Array), és így küldi el a szervernek:

{"value": ["аналіз"]}

Amikor a Tomcat motorja (a Jackson JSON feldolgozó) megpróbálja beolvasni ezt az adatot, meglátja a szögletes zárójelet ([). Mivel ő egy egyszerű szöveget várt, a tömb láttán azonnal összeomlik (MismatchedInputException), megszakítja a folyamatot, a felhasználó pedig kap egy hibaüzenetet, vagy a beírt adat megy a kukába.

A megoldás: A felület “lebutítása” a megbízhatóságért

Hogy azonnal feloldjuk a blokkolást, el kell engednünk a tag beviteli típust. Egy olyan robusztus, “cél-szerszám” jellegű megoldásra van szükségünk, ami nem okoskodik, nem vár svéd szótárakat, csak megbízhatóan, egyszerű String formátumban küldi be az adatot.

Erre a onebox típus a jó választás.

1. Nyisd meg a konfigurációs fájlt:

nano /opt/dspace-9/config/submission-forms.xml

(A könyvtár elérési útja a saját rendszered szerint változhat.)

2. Keresd meg a kulcsszó mezőt és módosítsd:

Írd át az input-type értékét onebox-ra, és ellenőrizd, hogy a repeatable (többszörözhetőség) engedélyezve van-e.

<field>
    <dc-schema>dc</dc-schema>
    <dc-element>subject</dc-element>
    <dc-qualifier></dc-qualifier>
    <repeatable>true</repeatable>
    <label>Kulcsszavak</label>
    <input-type>onebox</input-type>
    <hint>Adjon meg a dokumentumhoz kapcsolódó kulcsszavakat.</hint>
    <required></required>
</field>

(Tipp: Ne felejtsd el ezt megtenni minden űrlapnál, például a traditionalpagetwo és az openairePublicationPagetwoForm blokkokban is, ha többet is használtok).

3. Mentsd el és indítsd újra a Tomcatet:

systemctl restart tomcat10

(Vagy tomcat9, attól függően, min fut a DSpace backend).

A fantomszavak esete: Miért tűntek el az adatok az eredeti beállításnál?

Jogos a kérdés: miért nem mentette el a rendszer a szavakat akkor, amikor az eredeti beállítás (<input-type>tag</input-type> és <vocabulary>srsc</vocabulary>) még érintetlen volt, és miért nem dobott hibát? A válasz a DSpace “autoritás-kezelésében” (authority control) rejlik. Amikor egy szótár be van kötve a mező mögé, a rendszer elvárja, hogy a kiválasztott kulcsszó rendelkezzen egy hivatalos azonosítóval (authority ID) az adott adatbázisból. Amikor a kollégák begépeltek egy egyedi magyar vagy ukrán kifejezést, a háttérben futó svéd szótár természetesen nem talált rá egyezést, így azonosítót sem tudott hozzárendelni. A modern Angular felület itt egy kicsit becsapós: vizuálisan engedi, hogy a begépelt szó ott maradjon a dobozban címkeként, mintha minden rendben lenne. Amikor azonban a mentés gombra kattintunk, a DSpace háttérrendszere átnézi a csomagot, és egyszerűen, némán eldobja azokat a szavakat, amelyek nem rendelkeznek érvényes szótári azonosítóval. Vagyis a kollégák hiába írták be a szavakat, a szerver “azonosítatlan fantomadatként” kezelte, és a publikálás pillanatában csendben kiszűrte őket a végleges rekordból.

Mi a végeredmény?

A beküldési felületen a “csilivili” buborékos címkéző helyett egy letisztult, hagyományos szövegdoboz jelenik meg. A felhasználó beírja a kulcsszót, nyom egy Entert vagy rákattint a “Hozzáadás” gombra, és az elem bekerül a listába.

Lehet, hogy vizuálisan kevésbé izgalmas, de ez az egyszerűsített beviteli mód garantálja, hogy az adatok pontosan abban a formátumban érkezzenek a szerverre, ahogy az elvárja. A JSON feldolgozó soha többé nem fog összeomlani, és a többnyelvű kulcsszavak végre hiánytalanul bekerülnek a repozitóriumba!