Achieving the original aim?

Five favourite parts of IMan

If you’re working with a single product day-in day-out for three and a half years you can sometimes lose sight of what you’re trying to achieve: tunnel vision! My aim in creating IMan is to create a general purpose integration platform with a strong focus on usability and one which is flexible enough to cover 95% of all integration requirements.

Have these been achieved? I would like to share some insights on the development process, the goals, and some of the problems I encountered along the way.

The Preview

The preview grid, situated at the right half of each transform setup interface, is populated with the results of the transformation each time the ‘Refresh’ button is pressed. It is one of the key pieces to facilitate easy and rapid integration design and, as one user put it, with the preview area ‘you’re not working blind’. Development, however, was not easy! Several weeks were spent, several calls made to Microsoft developer support, and many grey hairs grew! The end product involves a multi-threaded WCF windows service with out-of-process COM Interop (I learnt a lot)! The end result is that multiple designers can be working simultaneously on a single instance of IMan.

Common Connector Interface

The same interface is used for mapping Sage300 as Sage200 as SageCRM. This has been an evolutionary development, but it results in a common interface for every application, especially helping those consultants working with multiple products.

Hierarchical Support & Associated Transforms:

There was no point in producing another integration product where hierarchical data support was shoe-horned, so IMan has been built from the ground up to support hierarchical data. The goal is to make the design process as intuitive as possible, whilst increasing the software’s flexibility.

Free Form Designer

To achieve the ‘95% integration coverage’ IMan is designed so that each transform/node within the integration can be linked to the previous transform ad infinitum, permitting multiple transforms to be linked or branched to build complex integration logic.

The major challenge was to provide a design surface which allowed interactive diagram creation similar to that of a flowchart i.e. to visualise the underlying implementation. Also, it needed to be in a web environment.

To achieve this, the only real choice was to use an off-the-shelf diagramming component (not an easy task as it needed to conform to web 2.0; it was 3.5 years ago). In-house development of such a component would have been sheer lunacy.

The result is the design surface we have today. We believe it facilitates everything from simple dataflows through to more complex integrations. Further, due to the flexibility, we’ve seen several of our customers use IMan for complex process automation, far beyond my original intention of IMan as a general integration tool.

Drop In Connectors & SDK

As a general integration tool, IMan required a means to connect other applications through their APIs, particularly with the marked increase of hosted applications where a webservice connection is the only choice. The initial thought was to create a generic webservice connector, but the different protocols, implementation and necessary logic, plus a UI to configure it was just too complex (just look at SData for example), and out-of-step with IMan’s focus on usability.

To facilitate this, we’ve taken a low level approach and added the ability for third parties to develop their own connectors for external applications, web services, etc.

I believe we’ve taken the correct approach as IMan gives you the ability to connect to any application, not just webservices; further, it enables the developer to add ‘smarts’ into any connector.

From a developer’s perspective, I think the thought of connector add-ins is awesome!

Our partner, EC Internet, has already developed the Magento connector, with two more on the way for Vortex ASP.Net Storefront eCommerce platform and Sage Pro.