Jump to content
Sign in to follow this  
twdorris

UPS XML module broken?

Recommended Posts

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"?>

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.


Tedward

Share this post


Link to post
Share on other sites

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.


Tedward

Share this post


Link to post
Share on other sites
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.


Tedward

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×