Coldfusion RETS Authentication

As I mentioned in an earlier post, when my client signed up for RETS access the MLS sent them essentially only three bits of information, the username, password and login url. This is just about all we need. I setup application vars for the username and password. Here is the rather simple login code.

<cfhttp 

url="http://mredllc-

rets.connectmls.com/rets/server/login" 

method="get" 

username="#application.retsUsername#" 

password="#application.retsPassword#">

        <cfhttpparam name="Accept" type="header" value="text/xml,text/plain;q=0.5">

        <cfhttpparam name="User-Agent" type="header" value="Mozilla/4.0">

        <cfhttpparam name="RETS-Version" type="header" value="RETS/1.5">

cfhttp>

<cfset application.RetsCookie = cfhttp.Responseheader["Set-Cookie"]> 

Nothing to fancy here, as per the RETS 1.5 Specification I set the required ACCEPT value to allow for xml or text, and the the q=0.5 is a response quality value between 0 and 1. Don't really know much about that yet, but seems to be the accepted value to pass. User-Agent is for server logging, but required. RETS-Version was a little tricky, seems different servers like that in different format, this one works for me (I have seen other comments using the format "RETS_1_5"). Note that I am setting the returned cookie to the application (maybe set to the session for a production application), this is critical, you will need to pass that value with all of your requests to maintain you session on the server. Dumping the cfhttp.filecontent should get you something like this...

Note that the filecontent contains the path to the other resources on the server such as Search, GetMetadata, Logout and GetObject. The returned Set-Cookie struct has a JSESSIONID, we will pass that entire string back with each future request. Well, we are logged in, now it is time to find out what we can do and what the schema is. For this, we need the MetaData...

RETs Project Basics

RETS, (Real Estate Transaction Standard) is a way for real estate applications and MLS systems to communicate in a standardized fashion. A MLS (Multiple Listing Service) is essenitially a database of listed properties for a particular region that real estate agents use to list thier clients properties and/or find properties for thier buyers. Here in Chicago, we have one of the largest MLS's in the country, the entire northern part of Illinois is covered, It is called MRED (Formally MLSNI). MLS systems historically have been very propietary in nature, they had no real need for the systems to be compatible with other MLS systems, and some might argue that they were, to some extent, kept that way to increase their own value. So the familier story kicks in, the Internet comes along, sites like Realtor.com want to list all of the different MLS listings and have to deal with thousands of different systems. The real estate agencies don't really care initially, until, wait a minute, we can sell more properties this way. So, to make a long story short, NAR (National Association of Realtors) get's behind the RETS standard and all of the MLS systems have to get on board. 

As a developer that has focused on the real estate and financial industries for most of my career, I can't even express just how good it is to have a standard in place. I have spent many months of my life stringing code to try and pull listing data from uncooperative MLS systems. From the research I have done on RETS it is obvious that its not perfect, but it has to be an improvement.

So here is how the ball got rolling. My client, and Realtor and member of MRED wants a research application that will require running queries on current and closed MLS listings. I instruct her to contact the MLS and acquire RETS access. She has to have her broker fill out a form and send it off, along with a check for $500 (per year). After a few days an email comes from the board with a username, password, login url and a link to http://www.rets.org, and the Center for Realtor Technology (CRT) if we have any questions. I guess there is something to be said for not getting overwhelmed with information.

MRED runs a Variman 1.0 & 1.5 compliant RETS server. The server seems to be the most popular, it is open source and was developed by CRT. A quick browse of the Variman documentation reveals really nothing of value for the client developer, it is all geared toward setting up the server and mapping it to your current database on the MLS side of the equation. Here is am important reality regarding RETS; they have not defined a standardized set of fields that every MLS uses for properties. This is really born of the fact that local MLS systems require very localized fields. There is little use for fields describing the amount of ocean beachfront a property has that is located in central Montana. Each MLS still has their own fields, though there are some standard names. The idea here is that you connect to the RETS server and initally download the METADATA files that describe the data within that MLS. But first we must login...

Coldfusion RETs Kickoff

And so it begins. The goal is to create a pure Coldfusion application to access and update real estate listings via a RETS server. I have managed to find a shockingly limited amount of information about accomplishing this with Coldfusion. The fact that you can usually find someone else posting up code for a similar project is one of the things I like best about Coldfusion. I can't even count the number of times I have embarked on a new project only to quickly discover a similar project in it's final stages, free for download, (Yeah, I am talking about you Camden, haha). This one seems to be different though, and maybe I will soon find out why there is so little out there. I should make a mention that I am going to use this blog almost as a journal during development, so I fully expect it to be a bit "all over the road". Maybe at some point, if all goes well I will drop back and clean it up to produce an easier read.