Over the course of years I’ve been confronted with more than one integration. The worst one of all was web service based integration. That was a big surprize. At the end I had to use soap logger and pin point every little thing that went wrong including null integers which is okay in Java but not in .NET. Not to mention that I had to spoon feed web service so it would work ( things like: “only at this time of a day”, “never with that parameter”… ). It was a big messy pile of disbelief and despair. We ended up spending 200 hours on this (we’ve planned for 40 hours).

For queing we used IBM MQUE, it was a lot less pain than I thought it would be. I have to admit I was a bit sceptical at first. There is something nice about fixed length message format that is commonly used when using QUE. I can’t put my finger on it but it just feels elegant and easy to modify. We never loosed a single message in more than two years so I am more than pleased with that.

Database integration is also OK. Make sure you can repeat process, and that you deliver a meaningful error messages.

To summarize:

• Whatever your estimate is – double it
• Log,log,log – you need to cover you behind when it is time to point fingers (and you need to know what went wrong if you want to look at this from constructive point of view)
• Don’t use .xml – it’s lame standard for integration – contrary to popular belief
• Use web services only as your last resort
• For bulk integration DB is the best option
• For message integration, answer is obvious – use QUE or suffer the consequences
• For something in between even fixed delimited file beats .xml any day
• Make sure your integration is repeatable – you can bet on mistakes happening during bulk integrations, and a general need to repeat integration