Hi Steve,
I’ve had no success getting SUSHI to work with ProQuest or GALE (nor with several others via our Sirsi Dynix-hosted instance of CORAL), tho I was grateful for
the GALE URL you provided. We got precisely the same error message you did when we tried it however.
Intrigued to hear that you have had success with so many vendors in setting up SUSHI; I have been very frustrated trying to get the connections set up and running
correctly. Still stuck on Elsevier, Wiley, ITHAKA, McGraw-Hill, plus ProQuest and GALE.
Even when I am able to set up a SUSHI connection and run successful tests with a vendor, those uploads do not appear to be running on schedule. So I must run
them manually – on the SUSHI page in the Usage module, the date in the “Latest Run” column is always the date I managed to run a successful test of the SUSHI connection.
TBH, All this has left me skeptical of SUSHI’s capabilities, and CORAL’s. But its early days in my experience with both, so remaining hopoeful.
Ultimately, I’ve resorted to getting the Sirsi Dynix and GALE tech reps on a conf call to resolve this. This will occur this week; if anything useful results,
I will update with that info.
Cheers,
damien
Damien McCaffery
Electronic Resources Librarian
Jefferson (Philadelphia University + Thomas Jefferson University)
4201 Henry Avenue
<image001.jpg>
Sent to SERIALST and ERIL-L.
I’m curious whether anyone has successfully connected to Gale’s or ProQuest’s SUSHI service.
ProQuest does not seem to provide instructions that are readily found or logically placed, e.g. I’ve looked everywhere I can think of in their admin module to no avail. They are listed as supporting SUSHI on the Project COUNTER site and I’ve reached out to
the person listed there as their contact but haven’t heard a response yet.
Gale at least provides instructions that I was able to find (see
https://support.gale.com/technical/sushi) but the SUSHI request I initiate (via
CORAL, our open source ERM) generates the following error and their support staff’s response is that this is a problem on CORAL’s end. It may be, but I’ve successfully set up over 50 other vendors without encountering this issue, so I’m doubtful at this stage.
-- Soap Connection successfully completed --
Exception performing GetReport with connection to Gale (GOLD): org.xml.sax.SAXException: SimpleDeserializer encountered a child element, which is NOT expected, in something it was trying to deserialize.
DB1 successfully retrieved from Gale (GOLD) for start date: 2017-01-01, end date: 2017-06-30
-- Sushi Transfer completed --
Failed XML parsing or no data was found.
The following is the XML response:
When we test the connection with the following setup, the connection for Gale is successful. The error message above occurs, though, whenever we attempt to actually run a report. Here are our settings:
Requestor ID [our admin login]
Customer ID loc=[our location id]
Password [our admin password]
One more thing: we also happen to have access to ExLibris’s UStat service and although we don’t use it (preferring CORAL), sometimes I check that system to test a particular vendor setup using a different SUSHI client, which often helps me figure out particular
wrinkles. However, Gale is not even listed as a valid vendor choice in that service, so this makes me wonder.
Steve Oberg
Assistant Professor of Library Science
Group Leader for Resource Description and Digital Initiatives
Wheaton College (IL)
+1 (630) 752-5852
NASIG President
<image004.png>
To unsubscribe from the SERIALST list, click the following link:
http://listserv.nasig.org/scripts/wa-NASIG.exe?SUBED1=SERIALST&A=1