Using UPS shipping API from withing OpenEdge 11.x ?

If OE and UPS both state they're working to spec (and it sounds like UPS should, sorry MUST, be returning a 500) then it may be worth looking at something else (like your own SOAP client).

What version of OE are you working with?

Using oe11.3 but I don't mind going tot 11.5.1.

I'll try to get the exact error and reply from UPS, as far as I understand it they refer to a more recent standard where it is allowed to return a 200 if the service is working and still return a SOAP fault to return an application error.

This is the response we got from UPS

According to our corporate support, our API is properly working. 

The API is working as intended. You will receive a 500 error if the envelope is a Fault. 
In the example provided by the customer, the envelope is not at fault, the information passed in it is. 
The following link the customer provided also states:

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529
A 2xx status code indicates that the client's request including the SOAP component 
was successfully received, understood, and accepted etc.

The SOAP envelope is successfully received, understood and accepted. 
However, the information in the envelope is not correct. 
Could you please share this information to the Progress Developer. 

Best Regards

Juan Manuel Saiz Ortiz | EDI SME
UPS Customer Solutions SSTI Deployment Group

This can be interpreted in several ways. The SOAP 1.1 standard (which I believe the UPS Web Service is based on) as partially quoted by you states the following (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529):

-------------------------

6.2 SOAP HTTP Response

SOAP HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client's request including the SOAP component was successfully received, understood, and accepted etc.

In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error.

-------------------------

The last part states that when a "SOAP error" occurs, an HTTP Status 500 should be returned. We can of course discuss all day long what falls under a "SOAP error" since that is also open to interpretation.

To help with such misunderstanding the WS-I was put in place and their latest SOAP 1.1 recommendation (Basic Profile 1.2) states the following (http://ws-i.org/profiles/basicprofile-1.2-2010-11-09.html#HTTP_Server_Error_Status_Codes):

-------------------------

3.5.7 HTTP Server Error Status Codes

HTTP uses the 5xx series of status codes to indicate failure due to a server error.

R1126 An INSTANCE MUST return a "500 Internal Server Error" HTTP status code if the response envelope is a Fault.

-------------------------

I am assuming UPS is sending back a SOAP Fault within the SOAP Envelope, so to me they are not following the standard.

If they are using SOAP 1.2, then they have a point. Those requirements have been removed in the WS-I Basic Profile 2.0 which is based on SOAP 1.2.

Quite  a few companies take the approach that a 500 status represents a garbage soap message and not an application error. Including Sonic when it was owned by PSC :-)

knowledgebase.progress.com/.../S11871

Here is a link (and relevant text) from WS-I 1.1 (2006)

www.ws-i.org/.../BasicProfile-1.1.html

3.3.1 Identifying SOAP Faults

Some consumer implementations erroneously use only the HTTP status code to determine the presence of a Fault. Because there are situations where the Web infrastructure changes the HTTP status code, and for general reliability, the Profile requires that they examine the envelope. A Fault is an envelope that has a single child element of the soap:Body element, that element being a soap:Fault element.

R1107 A RECEIVER MUST interpret a SOAP message as a Fault when the soap:Body of the message has a single soap:Fault child.

All that being said you are kind of stuck with the way that OpenEdge currently works. So you need to use CURL or the HTTP classes or some other option to actually use the UPS service reliably.

Short term fix is to have the developer fix the issues with the SOAP content (likely missing or invalid values) and put in validation that matches what UPS expects.

I know all bout it, I logged a bug with Sonic Development back in the days for that, since I believe the OE way to be the correct way. I was overruled by Sonic Development back then :-)

Like I said, it's open to interpretation since one could argue in this case that OE is not following recommendation R1107 and that UPS is not following recommendation R1126 of the Basic Profile 1.2.

We (cverbiest + Support) are already working on a workaround by using the new HTTP client, but we have hit some issues there as well unfortunately.

Standards are wonderful aren't they :-)

I personally feel that the UPS way is better, but I can understand both sides. The reality is that so many places are using non 500 HTTP status codes so at some point changing the OE side to just look at the SOAP fault seems to make a lot of sense.

From what I found the debate about returning status code 200 or 500 dates back to 2001 lists.w3.org/.../0015.html .

I don't know if anybody actually won the debate.

From the point of an ABL developer trying to call a webservice this doesn't really help though. If a company like UPS thinks their API is correct,  chances that they'll make changes because an ISV using OpenEdge says they should are extremely slim.

ABL is supposed to take the hard work out of calling webservices. Now we have to either code it ourselves on a low level using httpclient and dealing with the soap messages ourselves or we have to use a different programming language.

Neither of those options are ideal.

Two thumbs up for that approach. I think it makes the most sense because it helps to split the issues into the "proper" categories.

When do we get that for the ABL ;-)

Thanks Peter, I re-opened case  00320651 "Problem getting errors from UPS webservice"

A defect has been logged and the KBase article has been updated:

knowledgebase.progress.com/.../P125009

Just an update on this issue:  We were able to confirm what the customer is

seeing and it looks like this is the third part library issue, where no

SOAP FAULT information or any error status is being issues if HTTP status

is 200. We have opened a case with the third part library support team.

Also, if this issue is addressed, SOAP engine has to take a

performance hit of having to check for SOAP fault element for EVERY SOAP

responses. This is probably why other vendors are still relaying on HTTP

status code to issue SOAP faults -especially when the application is excepted

to run normal at > 90% of the time.

FYI, the fix will be included in the upcoming 11.6 release.