If you work with Flex remoting and WebORB, you are probably familiar with the following errors:

  • NetConnection.Call.Failed: HTTP: Status 500
  • Channel Disconnected

You may have tried directing your browser to weborb.php only to get this message: “WebORB v3.5.0 Fatal error: Call to a member function getServiceURI()”

The getServiceURI message is actually a red herring error message.  This simply occurs because weborb.php is expecting the raw headers to contain Flash remoting AMF message data.  Your browser is just making a normal HTTP GET and doesn’t know anything about AMF.   So weborb.php winds up with a null object on which it tries to call getServiceURI().  I wouldn’t be surprised to see a future release of WebORB that catches this error, even though it isn’t the purpose of this particular file to run inside a browser.

So, you are probably frustrated because you were trying to figure out what is wrong with your install and why you are getting the connection and/or channel errors.  These errors are almost always the result of a PHP compile-time error.  PHP5 itself is rather inconsistent in the way it handles different types of errors.  You may have noticed that it’s impossible to catch a syntax error or a bad path in a require_once() statement, for example.  If an include file is missing, PHP craps out before you have a chance to do any error handling.  You can only catch and handle run-time errors within your PHP code.  You may be tempted to think that WebORB should be able to catch these errors and return a more useful message to Flex, however the PHP engine stops executing before it even gives your code or WebORB a chance to handle anything.  It’s kinda the equivelant of having a syntax error in Java or C code that causes your app to not compile.  It doesn’t matter what type of error trapping code you write – if you code doesnt’ even compile, it doesn’t even get the chance to run.

When any part of either your service or WebORB encounters a compile-time error, it instantly dies and, depending on your server config, will write out the error details to STDOUT (which shows in a browser) but what it does not do is return a proper AMF message to the client.  If you were to look at the output of the PHP page, most likely you would instantly see cause of the error.  However Flex/Flash seemingly ignores the output of the page and it only processes the headers returned by the server (ie 500 error).  So PHP is outputing the details of the error but Flex blocks you from reading it.

UPDATE: I now use App Puncher to view error messages now.  A network proxy or packet inspector would probably work as well.  My original info below is still here in case you want to trace down errors by hand.

To figure these errors out, I try to start debugging with a simple function that doesn’t do anything.  Slowly, step-by-step I start re-enabling code until I locate the source of the channel disconnect by process of elimination.  Other times I write a debug page in PHP and call the function in question directly.  (This isn’t always easy if Flex is passing in complex structures, however, it can be worth the effort sometimes).

I’ve noticed these things to be sure-fire causes:

  • require_once statement with file missing (or PHP include path not set right).  Note that if you are dynamically calculating the abolute path of the current working directory that it will be different when you are running via the “Management Console” than if you call your service directly from Flex.  This is a dead giveaway if it runs in one, but not the other.
  • passing in an argument to a method that does not match the declared PHP type.  You can detect this by simply removing your type declaration in your methods and see if the data comes through.  This could indicate a mapping problem or an unsupported type.
  • syntax error that causes PHP compile-time error.  This can be any type of silly syntax error.  These are usually easy to see if you create a server-side page that calls your service method.
  • If the WebORB examples work, but not your own services, it’s pretty much a giveaway that PHP is crashing somewhere inside your own service code and not the WebORB installation.
  • If you can’t even get the WebORB examples to work, then there is a good chance that editing PHP.ini will be required.  If that’s the case, hitting weborb.php with your browser can sometimes show you what’s wrong – just realize that any errors mentioning either getServiceURI() and FlashorbBinaryReader are due to the missing AMF headers that your browser didn’t send and are not the problem.

If you have a better way of debugging, please post a reply.  This can be an extremely frustrating error to chase down and I would welcome any suggestions.