I was tasked with incorporating our system with a 3rd party credit card processing company called Lecayla. Initially this was written using PHP which was extremely easy, but now I needed to do it with Ruby. Lecayla had examples written in PHP but it seemed that no one was using Ruby. This created all kinds of issues all of them dealing with Soap4r. Hopefully this will help some people out there using Lecayla and Ruby and other people who are fighting with getting Ruby and Soap to work together.
- Documentation (or lack there of)
Soap4r is an implementation of Soap 1.1 for Ruby. One of the major problems is the complete lack of documentation. There are documentation entries for all the various classes but there isn’t any sort of explanation as to what does what. The only real way to figure all this stuff out is to use google and search other forums.
Soap isn’t very speedy and neither is Ruby. Soap4r doesn’t support caching of the wsdl and xsd files so every time you initialize the driver it will go out and get a new copy of the wsdl. This slows down the system tremendously. I implemented a really basic caching check into my class that solved this problem. I think this should be a part of Soap4r but it isn’t.
t_wsdl = 'config/lecayla.wsdl'
if (! FileTest.exists?('config/lecayla.wsdl')) || (! FileTest.exists?('config/lecayla.xsd'))
File.open('config/lecayla.wsdl', 'w') do |f|
f.write(Net::HTTP.get(URI.parse(billing.wsdl)))
end
File.open('config/lecayla.xsd', 'w') do |f|
f.write(Net::HTTP.get(URI.parse(billing.xsd)))
end
end
This will store the wsdl and xsd files in your config directory for use in your driver setup. If you don’t cache them in some form you will have a huge speed hit.
- Multiple ports in the same wsdl file
In PHP soap you just tell php to use the wsdl and everything just works. It doesn’t matter if the calls you are making are designated within different ports or not. PHP just does its thing and you do yours. With Soap4r it isn’t quite as simple. For Lecayla there are 3 different ports in their wsdl file, ContractHttpPort, MeteringHttpPort, and SSOHttpPort. In your initialization of your class you need to specifically setup each one. I did this:
@contractDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'ContractHttpPort')
@meteringDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'MeteringHttpPort')
@ssoDriver = SOAP::WSDLDriverFactory.new(t_wsdl).create_rpc_driver(nil,'SSOHttpPort')
Now in your class if you for example want to add a user you simply do
@meteringDriver.registerUser(params)
This is another reason to cache your wsdl, otherwise for each of these it would go out and get the wsdl. You can guess as to how long just this process took.
For Lecayla the structure of your hashes can be complex for the calls that you need to make, and it isn’t completely clear as to what the format should be for some of them. In PHP this was easy because they provided a sample and it was quick to get it up and running. In Ruby this took a little work figuring out. Soap4r contains a script called wsdl2ruby.rb that takes a wsdl file and outputs a driver file and a script that you can use to test based upon the xsd and wsdl that you give it. I found it a lot easier though to just read the wsdl and xsd files myself. The code generated by wsdl2ruby seemed to be extreme overkill for what I wanted. With some help from the Soap4r maintainer and some sorting out by myself. Here are some of the structure formats.
Also make sure you wrap your calls in begin blocks so you can catch any exceptions that come across. The Lecayla documentation on their web site for developers is extremely helpful for what you will get in return and what the errors mean.
Thats about it. The above should be enough to get you started really quickly with implementing Lecayla in your system. Hopefully this is also some help to those folks out there that have been given a wsdl and don’t know what to do with it in Ruby. There is a Google group for Soap4r that I found useful for asking questions. The maintainer of it actually answers questions which is a lot better than what some other maintainers of Ruby projects do.
December 7th, 2007
Author: Mike Alletto
Before we moved from our own internally developed PHP framework to using Ruby on Rails, I had written a database migration library that mimics Rail’s with two key differences:
- It allowed for retroactive running of migrations with versions at or below the current database version.
- It allowed a developer to force run a migration, even if that migration had already been run before.
Point one solves the problem where you have multiple developers sharing the same development database and all writing migrations at the same time. For instance, you create a migration 002_blah, but before you run it and check it in, another developer created, ran and checked in migration 002_bleck. By default in Rail’s, your 002_blah migration will never be run because the database is already on version 002. My library instead says “ok, I’m on version 002, but lets see if there any new migrations at or below that version that have not been run yet.”
Point two is dangerous and indeed has lead our database to get all mucked up more than a few times, but hey, it’s a feature no one is forcing you to use. The “force run” feature lets you run a migration (either up or down) even if it has already been run before. This feature is nice for when you realize you made a mistake in an already run migration and instead of making a new migration, you just want to edit and fix the existing one. You “force down” it, edit/fix it, then “force up” it.
I made a plugin for Rails called Retroactive Migrations (r_migrations) that implements this behavior. For installation and documentation, please see my personal blog post about it.
October 22nd, 2007
Author: Christopher Bottaro
FineTooth will be at the AMIA 2006 Symposium for a poster presentation with the Fred Hutchinson Cancer Research Center. The presentation is on the use of our automated text extraction service to build a cancer tumor registry from pathology reports. The poster presentation is part of S13 Poster Session 1. If you are going to AMIA this year stop by and say hi. If you can’t make it here is a link to a PDF of the poster. Please note the real poster is 4 feet high and 8 feet wide, so the file is large.
November 8th, 2006
Author: ScottD
We are in the hunt for another UI developer for our contract management web application. If you are in the market or know someone who is, shoot them the job info. Here is a repost of the information from our corporate site:
Senior UI Developer
FineTooth is currently seeking a Senior UI Developer to join our team and contribute to the front end development of our web based, scalable, on demand applications. Working together with a small team of web and database developers in an agile environment, the Senior UI Developer will have the opportunity to develop and gain experience in a fun, fast-paced, and flexible environment.
Qualifications:
- 4+ years experience in UI development, preferably with scalable production web applications
- Strong experience with HTML, CSS, JavaScript and AJAX programming patterns
- Experience with PHP and XML
- Familiarity with graphic design and associated tools including Photoshop and Illustrator
- Good sense of usability in graphical UI design running on real time systems
- Ability to work both independently and as a member of a small team
- Desire to work in a fast-paced, fun, and flexible environment with great benefits, developing cutting edge technologies
- Undergraduate degree or equivalent years of industry work experience
Applicants are encouraged to provide examples of past UI development work or sample applications that demonstrate UI and software engineering skills.
For immediate consideration, please send a word doc resume to careers@finetooth.com with “Senior UI Developer” in the subject line.
November 6th, 2006
Author: ScottD
Last week was the second face-to-face meeting of the OpenAjax Alliance membership, fresh on the heels of the AJAXWorld conference in Santa Clara, CA. The meeting was two-days long, with day one focused on a mix of show-and-tell, group breakout discussions, and objective proposals. Day two focussed on the future of Ajax and mobile development. The result is that the group has solidified plans to produce an event and markup scanner component for developers to help ensure framework and code compatibility as well as toolkit interoperability - i.e. say you want to use a MooTools Accordion and a Dojo Fisheye together somehow. That might actually be perverse, but anyhow you get the drift. California was beautiful and Sun has a great layout and cafeteria. The Chinese Steamed Fish was superb!
October 14th, 2006
Author: Lindsey Simon
Despite a close call where the original venue pulled out at the last minute, BarCampTexas took place without a hitch at Club Elysium in Austin, TX. The goth bar scene + noon o’clock beer + many caffeinate barcampers was both fun and educational. I heard presentations on search engine optimization, programming in Cocoa, better ways at describing user interface interactions in Visio, and some unique ways to fund ideas. I even took a crack at my presentation on the XSLDataGrid. All in all, it was cozy, initimate, and the spirit of bar camp was in full effect. We attendants are forever in debt to the hard work that Lynn Bender, Whurley, Erica, and Wordlife Productions put in to set up such an awesome un-conference.
August 27th, 2006
Author: Lindsey Simon
Just a quick link to an article I’ve been working on for awhile that started off here as a post after playing with Google’s AJAXSLT - check out: The XSLDataGrid: XSLT Rocks Ajax over at XML.com. The source code and examples are hosted here on our site, so if you have any questions or find any bugs, I’d love to hear from you!
Demos:
August 23rd, 2006
Author: Lindsey Simon
See the demo and now download the code too! Goto A Better File Upload Progress Bar using Python, Ajax Prototype, & JSON
The basic idea for the File Uploader was borrowed from MegaUpload. That’s all that was borrowed really, except for the empirically derived sleep value in the read loop.
So here’s the gist of how this whole thing works…
The File Uploader allows for sending multiple files at once. We group these files by a session id which is just some unique number. The browser starts sending the files and the CGI starts handling them, one CGI process per file. Each session gets it’s own directory somewhere on the CGI server’s filesystem (/tmp). The directory name is derived from the session id which can be pulled out of the query string by the CGI process.
Within each session dir, each file get its own directory. The name of this dir is specified by the HTML form and can be pulled out of the query string by the CGI process. Within each file’s directory, four files are made: cgi_data, file, form_data, meta_data.
The first thing written is the meta_data file, which contains starttime, totalsize, and pid. The AJAX poller can read this file for bytes/sec calcuations and to cancel the upload by killing the process.
The next thing that’s written is the cgi_data file. That is all of stdin that the CGI process reads. The AJAX poller can read the size of cgi_data and from that, combined with what it reads in meta_data, can determine bytes/sec and time remaining, etc.
As stdin is being read and cgi_data is being written, we scan it for interesting data points such as mime type and file name. We write these to the meta_data file as we come across them. As the AJAX poller sees these, it can take appropriate action (display the name of the file being uploaded, and give you a nice little icon corresponding to your mime type).
Once all of stdin has been read, we can parse it and extract the actual file contents from it… which is stored in the file named file. Then we scan that file for viruses and write another meta data file called form_data, which contains stuff like name, filename, mimetype, hasVirus?, virusName. I think form_data is a little redundant and probably can be merged into the meta_data file.
The AJAX poller knows we are done by the existance of the form_data file (also because the size of cgi_data is equal to totalsize in the meta_data file), and it can redirect us to our PHP handler. Once in our PHP handler, we have inputs for the session id, as well as the sub dirs for each file uploaded in that session. From that, the PHP handler can read all the meta data files as well as the file contents.
August 22nd, 2006
Author: Christopher Bottaro
This year, the coordinators of SXSW Interactive are taking it to the streets, soliciting votes about what panel ideas seem most exciting and relevant for next year’s conference. When Shawn O’Keefe and Hugh Forrest of SXSW approached me with this concept, I got really excited about it. I put together what I hope folks will find to be an intuitive and simple user interface for choosing 10 panels and sorting them from top to bottom, using the scriptaculous Sortable. I’ve gotten feedback from some users so far and I’ve tried to implement as many of their suggestions as I could (thanks to Khoi Vinh, Gordon Montgomery, Michael Mahemoff, and some others). Head on over and pick your favorites!
I’ve got a Panel Proposal in the “browsers / web apps” category that will essentially be about a forthcoming article I’m working on regarding using XSLT in the browser and on the server for AJAX widgets. So if that sounds interesting to you, go vote for it!
On a side note, the folks working on BarCamp mentioned the panel picker on their listserve, which my friend whurley pointed out to me. It seems like maybe this thing might have some other uses and people are interested. Feel free to download it at http://www.commoner.com/~lsimon/PanelPicker.tgz
August 16th, 2006
Author: Lindsey Simon
FineTooth is proud to announce joining the OpenAjax Alliance. A big thanks goes out to Jon Ferraiolo at IBM for getting us involved as well as attempting to organize what is quickly becoming a fragmenting technology. With so many frameworks, so many libraries, and so many vendors - all with different goals and applications - now seems like a very opportune time to try to develop some standards. Hopefully, this will empower future developers to take advantage of the trials and tribulations when considering which patterns or libraries to use in their projects. At FineTooth, we hope to offer some contributions in the Markup and Interoperability Committees. Most of the major software players seem to be throwing some weight into this endeavor too - something that makes us want to have the voice of some smaller development shops heard as the Alliance moves forward..
June 19th, 2006
Author: Lindsey Simon
Previous Posts
