So, I'm going to be writing an application that uses the fedex adddress validation service.  Now this is one of their "advanced" services which means to use the production servers you need to get a production key, a vaguely explained process that seems to involve them wanting to take a peek at your app to make sure you're not going to open their systems to massive exploiting.  This means they have a dev server to test against.  

So Here i am writing a simple test to check that phpSoap, etc is going to get along with it and to get to know the system.  All I did was create a SoapClient instance with the wsdl provided, get my request all cleaned up and working and the response i get.

 Authentication Failure Error.

I scratch my head at this point because I had used the logon information they provided me, even went and rerequested it to double check.  Still no joy.  I pull the SOAP request out of the library to compare it to the documentation I have - looks fine.

 Ok, now I'm stumped.

 So I call Fedex's Web Services tech support.

"It's not documented, but Address Validation doesn't work with test.  You need to get a production key then call us back and we'll activate it."

I'm not sure what is the WTF here

1) They provide a dev server, it doesn't work

2) The supposedly want to vet your software, but due to #1 they'll bypass the vetting process

WTF's like this make me miss the change counting stories from a few weeks ago. 

BTDTGtTS.

The various correllaries are the ones that get my group at work frequently:

    1. "Our test environment isn't working right now, so can we just put our new code into production and hit your production servers."

    2. "Whenever we try running our test code against your development server, your development server crashes.  We need to test against your production server, so that we can actually run the test."  (Note: generally when this happens, the only recent development server crashes are right after their tests start.  That is, correllation = 100%.  Cause and effect, perchance?  Also note: in addition to our standard dev server, we have an internal dev server (normally our group only), a couple of QA servers, and a couple of project specific dev servers.  There's absolutely no reason to fail over directly to prod for testing.)

    3. "We tested with our test environment against your test environment, so now we're going to run completely new and unreviewed code against your production server."

    4. "We didn't change anything."

tgape:

BTDTGtTS.

The various correllaries are the ones that get my group at work frequently:

    1. "Our test environment isn't working right now, so can we just put our new code into production and hit your production servers."

    2. "Whenever we try running our test code against your development server, your development server crashes.  We need to test against your production server, so that we can actually run the test."  (Note: generally when this happens, the only recent development server crashes are right after their tests start.  That is, correllation = 100%.  Cause and effect, perchance?  Also note: in addition to our standard dev server, we have an internal dev server (normally our group only), a couple of QA servers, and a couple of project specific dev servers.  There's absolutely no reason to fail over directly to prod for testing.)

    3. "We tested with our test environment against your test environment, so now we're going to run completely new and unreviewed code against your production server."

    4. "We didn't change anything."

 

Some recent development I was doing used a Web Service that was inexplicably shut down before we went into production. Then some genious (sic) redirected the WSDL URL to the production server, so when the next test round began, chaos ensued.

Volmarias:

Whoever the "we" is here, I hope for your sake they don't have access to the production server themselves.

"We" can only access our production gear as non-local users (no shell access).  Unfortunately, "we" all run other servers elsewhere in the company.  Fortunately, there's only a couple of "we" that run company-wide servers; the vast majority are department-level functions.  Unfortunately, there's just of them that the term 'vast majority' applies.  Fortunately, few of them are category '2' (those few tend to get project-specific dev servers if they repeat the performance.  Not to give them the SLA on the test environment they want, but to protect the rest of our testers.)

I'd like to think that, overall, my group is fairly competent.  We try, at least.  "We", on the other hand, are very trying.

Oh, and I'm realizing it wasn't clear: my group runs a service on a large, geographically dispersed international cluster.  "We" apparently rarely realize this, so usually "we" refer to our servers as a single server.