Delphi 6 to XE3: SOAP and IP*Works SSL

Although we have not officially begun the migration phase yet from Delphi 6 to XE3, I have started installing our third-party component packs to ensure they are all working.

One of our products requires communication with the HMRC, the UK's tax man (equivalent of the IRS in the United States). This communication is done using SOAP, using a secure address. Originally, I had planned on writing this using the native SOAP components introduced in Delphi 6. However, the specification from HMRC showed that the SOAP envelope had to contain a SOAP header.

The HTTPRIO in D6 did not have a SOAPHeaders property, and so we made the decision (rightly or wrongly) to buy the IP*Works SSL component pack (version 6) from /n Software. Although expensive for the one component we needed it for (TipsSOAPS), this contained everything we needed and we were able to complete the project.

This component pack is now up to version 9, and the only upgrade path is for the prior version (i.e. version 8). Given that we have Version 6 which doesn't work in Delphi XE3, it looked like we would need to purchase it again. But at $899, I wanted to see if there was another way!

Now don't get me wrong, it is a sophisticated and well supported component suite and I have no issue with the company or the product itself. But I am not prepared to pay full price for a product I already bought once, when that price is about the same as I paid for Delphi.

My first thought was to try to the Delphi Edition of IP*Works that is available to registered users of Delphi XE3. So I downloaded and installed it. I had a sneaking suspicion that this would not allow me to do what I needed, because there is a separate component pack for non-secure and secure communications. And indeed, the TipwSOAP component would not allow me to consume a web service over https:

Personally I think charging $899 to handle SSL URLs is a bit of a con.

So, knowing that Delphi introduced support for SOAP headers in Delphi 7, I knew that the only reason we had bought this product in the first place was no longer a problem. So I set about writing a prototype to see if I could implement the same functionality using native Delphi components.

And I have! So +1 for Delphi XE3. I just saved the company $899, and shed another third-party component pack at the same time (and that makes me very happy).

I should also point out that this is the first time I have really, properly used a Delphi IDE other than Delphi 6, and it was an huge pleasure. Very fast and productive. So far, so good!

Real-world tools #5: IP*Works! SSL

It's been a while and for that I apologise, although perhaps many of you are grateful that it's taken 2 months for me to post. Usual stuff, I know you're all up against the same things. Deadlines, massive development schedules, testing, meetings... you know, real-world stuff.

I wanted to get back into this by explaining briefly why I chose IP*Works! from /n software. It came about because part of our payroll product needed to consume a web service written by (or for) the UK's revenue department, HMRC.

Version 1 of this web service was more basic than its successor, and as a result the standard SOAP Web Services tools that came with Delphi 6 were sufficient to do the job. Good old Delphi does the trick again, out of the box.

A year or so after version 1, the whole HMRC service was redesigned and so version 2 of the web service was born. Whilst it remained on the SOAP platform (due to a unanimous decision from the software developers that had to ultimately consume it), they introduced an element into version 2 that Delphi 6 did not handle: SOAP headers.

At this point, I had 3 options. Option 1 was to move to Delphi 7 in which support for SOAP headers was introduced as standard. Option 2 was to try the Indy Soap which also claimed to support SOAP headers. Option 3 was to buy a third-party product.

My preferred option was number 2, not least because it enabled me to stay with the version of Delphi I was on and we were already using the awesome Indy components for other HTTP, FTP and SMTP work. However, I failed 100% to even get this code to compile despite the help of the indy-soap-public Yahoo group. I decided this was going to be too much of a battle to even get started and so investigated option 1, upgrading Delphi.

This was a tricky decision, because although Delphi 7 would have given me what I needed, Delphi 2005 had been released by then. I felt that it would be ridiculous to spend all the time and effort moving from D6 to D7, along with upgrading all the third-party tools, etc, when it wasn't even the latest release. But I couldn't justify at that time a move to D2005 because it was taking a knock amongst its users, the cost was much higher and, crucially, I couldn't get a definitive answer on whether the SOAP stuff from D6/7 would work in D2005.

After coming to the disappointing decision that I wasn't going to upgrade from Delphi 6 at this time, and with development time running out, option 3 remained: a third-party tool. This was my least preferred for reasons I have explained in earlier posts: I don't like tabs and tabs of third-party components when I could have used a standard one. However, sometimes the guys who write these third-party tools are experts and sell stacks of their product for good reason, and IP*Works! fell under this category.

I had to buy the more expensive SSL version because the HMRC web service was run on a secure server but this wasn't a real issue. It essentially meant that I got all of the same components as with the non-SSL version but with the option to use secure communications or not.

IP*Works! SSL V6 Delphi Edition (still the current release) is a terrific product and I got the secure web service running within days, including all the extra SOAP header bits that I'd not been able to do with D6. If I hadn't have had such success with the other Indy components (HTTP, FTP, SMTP, etc) then I would have used the IP*Works! ones. It turns out that it was an expensive suite for just using 1 component for one utility, but it is a killer utility that pushed us ahead of the competition for a while.

When (not if) I finally do makr the jump to D2007 or RAD Studio 2007, it's likely I'll try and redo this utility to use Delphi's in-built SOAP objects because that it always my goal, to get back to as few third-party ties as possible. But for now the IP*Works! components are solid, robust, well designed and well documented and this is a purchase I didn't regret.

Although, an asterisk and an exclamation mark in a product's name drives me crazy!

Tools of the real world

I should explain what it is I do with Delphi every day, which will maybe give a background as to why I've become what I consider a conservative developer. Conservative, that is, in terms of what software we use. The company I have worked for for the past 9 years develops three main products (payroll, HR and Time & Attendance, combined as a suite), written for Windows using Delphi.

Although we sell that product, maintain it and enhance it, we also write a lot of bespoke plug-ins and utilities to complement it, for the particular organisation that it is going into.

Given that very simple overview, I'll go on in coming posts to what third-party tools we are using, why we selected them, and maybe why we are still using them even though there might be a better or more up to date alternative.

I think the key point to make is that this is real life. This isn't the ideal world of (the fantastic) Coding Horror, these are real-world, business-oriented decisions that are made because we are under tremendous pressure to deliver, we have a 9 year old project and literally dozens of plug-ins and utilities that rely on consistency throughout.

It also doesn't help that this was only my second job which I started at the age of 23. It turns out I didn't know it all then like I thought I did, and God knows I don't know it all now. So there are some mistakes of youth that are still embedded in the product that occassionally we have to work around. The company have been very good in the past in allowing me an extra month or so to refactor some of the big ones out, even though the end result to the user is no change. Which in the long run is time well spent because future work can then be written a lot faster, neater and cleverer.

It may come as a shock now to learn that, as a base product, we are still using Delphi 6. I will come to why at another time, but it may explain why we're using some of the third-party component sets that we are. I will go through each of these individually over the coming posts, exalting them, damning them or just saying why on earth we're using that one instead of another one. They are:

• ReportBuilder 10 (Digital Metaphors)
• ODBCExpress (Korbitec)
• TMS Component Pack (TMS Software)
• IP*Works! SSL (/n Software)
• Indy 9 (Nevrona)
• JEDI VCL
• Crystal Reports VCL