• Article Type: General
• Product: Primo
• Product Version: 3

Description:
Many of you who have experienced the problem in Primo (with Voyager sites) where the first result returns an error on the Locations tab.
The problem was somehow caused by RTA which wiped out the Location text next to “Available at”.
The source of the problem has been determined to be the Voyager ini file that contains the default enrichment values (949…).

First review the enrichment section of the Voyager export ini file: /m1/voyager/yyydb/ini/PrimoExp-Publishing.ini
InsertAVATag=959
InsertAUTTag=961
InsertSUBTag=962
InsertCRTag=952
InsertDPSTag=953
InsertEITMTag=954

Then go to the ini file that controls the XML coming from Voyager for RTA queries:
/m1/voyager/yyydb/tomcat/vxws/ini/PrimoExp.ini
InsertAVATag=949
InsertAUTTag=950
InsertSUBTag=951
InsertCRTag=952
InsertDPSTag=953
InsertEITMTag=954

The fix is to make the values in this file match those in the PrimoExp-Publishing.ini file.
If you have turned RTA off in your Primo configuration, then you will need to turn it back on in the View (Tiles/Brief Results/Locations).

So this is how Voyager RTA works:
1) Execute a search in Primo
2) Primo sends a query to Voyager containing the record ids: http://primo.XXX.hosted.exlibrisgroup.com:7014/vxws/VoyagerAvailabilityService?op=publish_avail&doc_num=498128,354199,401435,124606,50381,265091,428994,827924,408155,934501
3) Primo formats the XML per /yyydb/tomcat/vxws/ini/PrimoExp.ini
4) Primo receives the file and runs it through the normalization rules and then compares the display/availlibrary values.
5) Primo updates the availability status of items where it is different than the value held in Primo. The updated data exists for the life of the result set.

In this case the data did not match at all after being passed through normalization, but Primo went ahead and updated the result set with the new values which resulted in the problem because the values no longer matched anything in the Primo configuration ($$I, $$L, etc.).

Resolution: