search

ExLibrisGroup / SpineOMatic

Spine label printing for Ex Libris' Alma
MIT License
36 stars 18 forks source link

unexplained 400 error message #22

Closed alicecarli closed 3 years ago

alicecarli commented 3 years ago

I have been using Spinomatic for some time. For two recently cataloged copies of the same item, on the same record, the software created a label as usual for copy 2, but gives an error message ("The remote server returned an error: (400) Bad Request.") for copy 1. I checked over the Alma record and noted that copy 1 did not have a Material Type entered in its record. We have corrected that today, but Spinomatic is still giving the same error message. Neither I nor the cataloger who looked at the metadata for the two copies could find anything else wrong with copy 1. Any other suggestions of what we should do? The item involved is Sibley Music Library M14.4.W3 C598 1957, copy one (the copy listed as being in Sibley Music Storage Folios).

Anjijade commented 3 years ago

Hello, just curious if you are seeing this behavior on other items as well? Last week we started getting "Error Can't retrieve XML File. Error message: The remote server returned an error: (404) Not Found" on all items we have tested. Our key and URL have not changed. Our Spineomatic in house expert recently retired too.
I realize this might be a completely different issue but the timing makes me wonder if there is something else going on.

Anjijade commented 3 years ago

I just found a closed case for my XML issue that says TLS may be the culprit.

mgobat commented 3 years ago

@alicecarli, did you resolve the problem?

cmc-tech commented 3 years ago

We just started having the problem (400 error message above) today. The OCLC Client Software had to be repaired, as well. When I looked in the XML settings SOM said it couldn't load, I found a new error issue. Before, the problem was that the forward slash on an older version we screenshot was at the beginning of the method entry, but now had to be at the end of the URL, instead. This, because the XML was reading the end tag as part of the URL info, not stopping there. Now the same problem exists with or without the forward slash moved! It's once again reading the end tag as part of the URL, which would create an obvious error browsing the Internet. I'm stumped. Even the latest version 8.1.1 does this! (We were using 8.1.0.) It looks as if the part of the software that reads the XML is flawed.

mgobat commented 3 years ago

Please try this test, building the URL manually and submitting it via a web browser:

  1. Start will the "ALMA URL" on the "Alma Access" tab, for example, "https://api-na.hosted.exlibrisgroup.com".
  2. Add to it the "Method" from the "Alma Access" tab, for example, "https://api-na.hosted.exlibrisgroup.com/almaws/v1/items?view=label&item_barcode={item_barcode}"
  3. Replace {item_barcode} in #2 with the real item barcode you are using to print labels, for example: "https://api-na.hosted.exlibrisgroup.com/almaws/v1/items?view=label&item_barcode=12365"
  4. Now add "&apikey=" followed by the "API Key" from the "Alma Access" tab, for example: "https://api-na.hosted.exlibrisgroup.com/almaws/v1/items?view=label&item_barcode=12365&apikey=put_your_api_key_here"
  5. Then put the entire URL from #4 into a web browser and report back here what you get. Do you still get the 400 error message?

Thanks...

-mark

cmc-tech commented 3 years ago

@mgobat : I tried each of these in Chrome and got the following 4 attached messages at each consecutive step: Browser.txt Capture.

Also, there seems to be a not so obvious error in the XML because it looks like the end tag is being used as part of the address: Capture2

mgobat commented 3 years ago

@cmc-tech : The full URL test is the one that matters. If you built the URL correctly, it appears that your API KEY isn't defined correctly. Could you check that your API key has read access to bibliographic records? Alternatively, you could email me at mark.gobat@exlibrisgroup.com the full URL you tried from step 4, and I'll see if I can figure it out.

cmc-tech commented 3 years ago

@mgobat : I emailed you.

cmc-tech commented 3 years ago

@mgobat : Thanks for your assistance. We weren't able to check the permissions but we found another article/post and we learned that the first character in the API Key is an "l" not a "1". In the screenshot we took, with the font used, it looked as if it were a 1. Next time we'll know if we have to make a change.