I see most of the integrations happening with in an enterprise as following. A sample scenario is processing a EDI purchase order from the VAN. An internal enterprise application(App1) gets the EDI PO from VAN and does a HTTP POST to IS. The code in IS transforms that EDI PO to another format(say canonical) and FTPs it to a location where another internal enterprise application(App2) picks that up for further processing. I would like to know whether this is a real integration solution ?.
Eventhough there is an integration accomplished between App1 and App2 thru IS, I dont really know whether HTTP posting/FTPing between applications is really an integration. I prefer to have wM IS directly connect to VAN, do the transforming and directly send the information/talk(use a custom adapter?) to the application App2.
FTP/HTTP are merely transport protocols. By integrating “VAN” (I assume this is a legacy app) directly into WM via custom adapter would probably work faster, but would be more expensive to develop (especially if it’s a one-off requirement). Furthermore, your interface would be more brittle introducing a point of failure in the system.
Unless there is a compelling reason to develop a custom adapter and tightly integrate systems, I’d vote fro FTP/HTTP approach.
By the way, I assume you mean tight coupling approach by “real integraton”.
In my eyes, anytime two things that didn’t talk before start talking, that is a ‘real integration’.
How much work is done inside IS is very implementation specific, but it is reasonable to want to get rid of App1 in your example.
fewer moving parts.
cut out a network hop and serialization/deserialization.
possible leverage IS EDI Adapter VAN features, so App1 code is no longer needed.
App1 is reasonably straightforward Get-From-VAN-POST logic that can be re-implemented, tested and rolled out easily.
don’t have to worry about admin, clustering, etc of the App1 ‘server’ or maintenance of the hardware/OS it is running on.
That all said, you can re-architect forever to make an implementation feel ‘realer’, but I recommend concentrating on the 20% of the effort that gets the biggest ROI. Sometimes that means ignoring components like App1 if maintenance and admin is low and the machine its running on will be around for a while. Writeup ideas on how to best deal with App1 if the environment changes, and move on to automating some error prone manual process.
Hello,
Hido and Fred probably take care of everything you may question in your current (sample scenario) environment. You probably don’t want to spend a lot of time re-inventing the wheel or filling a good wheel with too much hot air. I could only see consolidating apps to one computer or over coming a bottle neck in throughput as a reason to bother with your current setup. I would only consider this also only if management the current approach unreasonably too slow (and only if it is slower than it had previously been in some cases).
I don’t know if you have been considering adding more intelligent features like resend on failure or update party/sender on receipt of document as improving the reliability to be a reason for possible change. I still think Fred and Hido are on point and I only see superficial reasons to change that have not all ready been said.