We've had our GSX Certificate working for some time now, and I've been able to update the purchasing information with no issue, however this morning when I tried to update I received the message:
RPR.COM.008: Choose a Ship-To location.
It goes from Look Up Info to Complete very quickly without any results. I just wanted to see if others were experiencing something similar before reaching out to GSX Web Support Services.
I'm not certain if it would apply in this situation, but I recently went through the GSX certificate signing process and the requirements have changed notably since the last time I did this song and dance. Check out the "What are the instructions to follow when generating the CSR?" section here: https://gsxwsut.apple.com/apidocs/prod/html/WSFaq.html
Today, (May 16, 2016) AppleCare released an update to their API which requires not just the Sold-To, but your Ship-To as a part of the Warranty Lookup process.
What you're seeing here in the
RPR.COM.008 is the result of the JSS not having this information, or using it in your lookup. Ensure that your JSS is up to date, or reach out to Casper Support for an update.
(We're shipping the update to our own Warranty Updater today)
Hope this helps!
Thanks everyone for your help with this! It's at least reassuring to know you're not alone.
I reached out to GSX Web Services Support:
"Please contact JAMF Support for guidance.
Once you speak with JAMF please reach out to me with any actions that are required on my side.
There was an update this past weekend in GSX, that now requires the Ship To location to be included in the Warranty Status Request."
We are running 9.81, with plans to upgrade to 9.91 two weeks from now. I reached out to our TAM to see if the upgrade would fix it. I'll keep you updated. Thanks again!
@jedfrye @Yager @CasperSally @aurica @james179 @watchmanmonitor This is a known issue with the current GSX integration that prevents the collection of Purchase and Warranty Expiration Date for hardware records. You can reference "PI-002276" to keep track of this Product Issue. In our next release, we will resolve the handling of this "Ship To" address when interacting with GSX to collect Purchase and Warranty Expiration Dates. In the meantime, you can access this data directly through GSX.
Thank you for posting this and bringing the issue to our attention. The feedback from our community is incredibly valuable as we constantly work to make our products better.
Hopefully, the specific GSX fix maybe able to be dropped in place, then restart tomcat? This could be a sort of "hot fix" to apply while sticking with current JSS version.
These are the likely GSX components needing updates on RHEL:
ls -1 /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/classes/com/jamfsoftware/jss/gsxws/ AuthenticateRequest.class AuthenticateResponse.class GSXCertificateException.class GSXException.class GSXFault.class GSXService.class GSXSession.class GSXUtils.class GSXWSRequest.class GSXWSResponse.class LegacyAuthenticateRequest.class LogoutRequest.class LogoutResponse.class PartDetail.class StandardAuthenticateRequest.class WarrantyRequest.class WarrantyResponse.class
As @watchmanmonitor and OP noted, seems GSX API now requires <shipTo> data in the request.
Click on the GSX Production reference for AASP, then flip-down "Repair Creation" > "Warranty Status". In the Warranty Status Request area, click "Sample SOAP Request XML" and you'll see an example, which includes a dummy tag for reference...
Compare that GSX example to what you see on your JSS webapp (using RHEL)...
cat /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/classes/com/jamfsoftware/jss/gsxws/WarrantyRequest.class # Snippet of output on JSS 9.82. Notice it's missing the <shipTo> entries. <soapenv:Body><glob:WarrantyStatus><WarrantyStatusRequest><userSession><userSessionId> ]^ _</userSessionId></userSession> </unitDetail></WarrantyStatusRequest>8</glob:WarrantyStatus></soapenv:Body>
@lee.smith GSX lookups definitely not resolved in any current Casper release. I only identified the suspected resource paths. I don't plan on editing any specified class resources; mainly just awaiting JAMF support reply about possibility of future hotfix for those of us who prefer not to wait/be tied to any full Casper point release.
Guess I could backup specified class files on Test JSS, make edits, then restart tomcat and see if I guessed correctly? If I get time to try or hear back from JAMF support, I'll reply back here.
Quite a bad time for this issue to be occurring considering we are starting to get shipments of all of our new hardware for setup over the summer and having all the warranty info is very important to our overall workflow.
Princeton Public Schools
I've installed this maintenance release and now GSX lookups just timeout and error now shows:
org.apache.http.conn.HttpHostConnectException: Connect to gsxapi.apple.com:443 [gsxapi.apple.com/188.8.131.52] failed: Operation timed out
Anyone having success or problems with this new 9.92 release?
Princeton Public Schools
We just updated to 9.92, but we're still getting this error:
ATH.LOG.14: Sold-To entered is not valid. Please enter a valid Sold-To.
UPDATE: I followed the suggestion on this post (https://jamfnation.jamfsoftware.com/scripts/article.html?id=26) and made sure the email address was one that has been used recently to sign into GSX, and now it's working.
Why I get this error always..
Traceback (most recent call last):
File "new_script.py", line 7, in <module>
File "/usr/local/lib/python2.7/site-packages/gsxws/products.py", line 94, in warranty
self._gsx._submit("unitDetail", "WarrantyStatus", "warrantyDetailInfo")
File "/usr/local/lib/python2.7/site-packages/gsxws/core.py", line 437, in _submit
result = self._req._submit(method, ret, raw)
File "/usr/local/lib/python2.7/site-packages/gsxws/core.py", line 335, in _submit
raise GsxError(xml=xml, url=self._url)
gsxws.core.GsxError: u'Cannot lookup serial number as there are no valid subscriptions for this ShipTo location.'