twdorris Posted July 15, 2009 Share Posted July 15, 2009 I'm using UPS XML v 1.3.4 dated 2008/02/03 UPS released an update to their API servers this past weekend and ever since then, our UPS shipping option has been broken on our website. The message generated by the osCommerce UPS XML module is just a version mismatch: "This module supports only xpci version 1.0001 of the UPS Rates Interface. Please contact the webmaster for additional assistance." But in fact, the problem is more serious because the UPS response to the rates request is simply empty! The version check just happens to be the first thing done in the module, so that's the error you get back. I've grabbed a log file from the UPS XML module and I see the time in transit request/response work perfectly. But then the module submits the rates request and gets back nothing but an XML header. I'll include a dump below (sans the license/user/password data). Any ideas? I've been in contact with UPS and they have "escalated" my issue to the applications team, but that's where our communication has ceased.... One person did say something like "Oh, yeah, we've been getting complaints about an empty response since our update", so I assumed a resolution was eminent, but so far nothing and it's really starting to cause problems for us. DATE AND TIME: 2009-07-15 07:00:34 UPS URL: https://www.ups.com:443/ups.app/xml/Rate UPS REQUEST using exec(): <?xml version="1.0"?> <AccessRequest xml:lang="en-US"> <AccessLicenseNumber>licensenumber</AccessLicenseNumber> <UserId>userid</UserId> <Password>password</Password> </AccessRequest> <?xml version="1.0"?> <RatingServiceSelectionRequest xml:lang="en-US"> <Request> <TransactionReference> <CustomerContext>Rating and Service</CustomerContext> <XpciVersion>1.0001</XpciVersion> </TransactionReference> <RequestAction>Rate</RequestAction> <RequestOption>shop</RequestOption> </Request> <PickupType> <Code>01</Code> </PickupType> <Shipment> <Shipper> <ShipperNumber>0A3Y53</ShipperNumber> <Address> <City>Frederick</City> <StateProvinceCode>MD</StateProvinceCode> <CountryCode>US</CountryCode> <PostalCode>21702</PostalCode> </Address> </Shipper> <ShipTo> <Address> <City>Frederick</City> <StateProvinceCode>MD</StateProvinceCode> <CountryCode>US</CountryCode> <PostalCode>21702</PostalCode> <ResidentialAddressIndicator/> </Address> </ShipTo> <Package> <PackagingType> <Code>02</Code> </PackagingType> <PackageWeight> <UnitOfMeasurement> <Code>LBS</Code> </UnitOfMeasurement> <Weight>1.8</Weight> </PackageWeight> <PackageServiceOptions> <InsuredValue> <CurrencyCode>USD</CurrencyCode> <MonetaryValue>100</MonetaryValue> </InsuredValue> </PackageServiceOptions> </Package> <RateInformation> <NegotiatedRatesIndicator/> </RateInformation> </Shipment> <CustomerClassification> <Code>01</Code> </CustomerClassification> </RatingServiceSelectionRequest> UPS RESPONSE using exec(): <?xml version="1.0"?> Quote Link to comment Share on other sites More sharing options...
Jan Zonjee Posted July 15, 2009 Share Posted July 15, 2009 I'm using UPS XML v 1.3.4 dated 2008/02/03 UPS released an update to their API servers this past weekend OK, didn't know about that. But in fact, the problem is more serious because the UPS response to the rates request is simply empty! That's hard to debug.... If there was an error on the upsxml side you would expect an error message from the UPS servers that would give you something to work with. But with just an empty header.... I would suspect (and hope) the problem is on the UPS side. Quote Link to comment Share on other sites More sharing options...
twdorris Posted July 16, 2009 Author Share Posted July 16, 2009 OK, didn't know about that. Yeah, it's impossible to find any news about it on their website. Supposedly it wasn't supposed to break anything. I have an e-mail stored away that they sent me about it a few weeks back. I ignored it because they claimed the API wasn't changing. And I think they're right. I don't think the API changed. I think they simply changed formatting and that broke the UPS XML module...at least the one I'm using. According to 3rd level UPS tech support, they added a line break/carriage return after the XML header in the rates request. And I guess (haven't had a chance to confirm or figure out a fix) that the UPS XML module is only expecting a single line back with all the XML data in it like it used to be and like the time in transit response still is. So I need to confirm this and see if there's some way to get the UPS XML osCommerce module to read all the data across multiple lines instead of just reading one line and stopping. Quote Link to comment Share on other sites More sharing options...
twdorris Posted July 16, 2009 Author Share Posted July 16, 2009 OK, here's the deal...the UPS tech was correct. They added a single line feed/carriage return after the initial <?xml version="1.0"?> string on the rates response. Not a big deal, really, except that apparently on my system PHP does *not* have curl compiled into it. So the UPS XML module was exec'ing out to curl which returns the response as an array of strings. The default behavior was to return the first string in the array: return $xmlResponse[0]; // $xmlResponse is an array in this case Bad code, bad. :) I have absolutely zero PHP experience, so I have no idea if my solution is clean or elegant or whatever. But here's what I did to correc this: return implode("", $xmlResponse); // $xmlResponse is an array in this case Anybody wanna tell me how bad this is? It's not like this is called a million times a second or anything. It's more like 10-20 times per *day* at most. I can't imagine this is going to bring our server to its knees. :) Anyway, that has restored UPS XML rates functionality on my box. Quote Link to comment Share on other sites More sharing options...
Guest Posted July 16, 2009 Share Posted July 16, 2009 I'm using UPS XML v 1.3.4 dated 2008/02/03 Hunh, I'm using 1.2.6 and it took my entire cart down. People could still browse but got an XML error when they tried to get too the shipping page of the checkout process. I had to turn off UPS entirely to get running again. I hate shipping everything via US Post. Quote Link to comment Share on other sites More sharing options...
Guest Posted July 18, 2009 Share Posted July 18, 2009 Okay, so I tried this in UPSXML 1.2.6 and still got the following error when I entered the checkout process. "Fatal error: Call to undefined function: _parseresult() in /home/bearclaw/html/catalog/includes/modules/shipping/upsxml.php on line 814" (which is where the parsed xml gets returned.) OK, here's the deal...the UPS tech was correct. They added a single line feed/carriage return after the initial <?xml version="1.0"?> string on the rates response. Not a big deal, really, except that apparently on my system PHP does *not* have curl compiled into it. So the UPS XML module was exec'ing out to curl which returns the response as an array of strings. The default behavior was to return the first string in the array: return $xmlResponse[0]; // $xmlResponse is an array in this case Bad code, bad. :) I have absolutely zero PHP experience, so I have no idea if my solution is clean or elegant or whatever. But here's what I did to correc this: return implode("", $xmlResponse); // $xmlResponse is an array in this case Anybody wanna tell me how bad this is? It's not like this is called a million times a second or anything. It's more like 10-20 times per *day* at most. I can't imagine this is going to bring our server to its knees. :) Anyway, that has restored UPS XML rates functionality on my box. Quote Link to comment Share on other sites More sharing options...
Guest Posted July 18, 2009 Share Posted July 18, 2009 Okay, so I tried this in UPSXML 1.2.6 and still got the following error when I entered the checkout process."Fatal error: Call to undefined function: _parseresult() in /home/bearclaw/html/catalog/includes/modules/shipping/upsxml.php on line 814" (which is where the parsed xml gets returned.) Upgraded to 1.3.5 (about time, eh?) and everything looks fine now. Groovalicious. Quote Link to comment Share on other sites More sharing options...
Jan Zonjee Posted July 18, 2009 Share Posted July 18, 2009 Upgraded to 1.3.5 (about time, eh?) and everything looks fine now. Groovalicious. And then 1.3.6 is around the corner :) (just bug fixing the above exec issue and some other small things). Crazy error anyway because in 1.2.6 the function _parseResult is on line 915-984. Perhaps your upsxml.php file got damaged? alax 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.