An Integration Story

on

My current project has me building a system to allow an external partner to integrate with our order application.  Right now, the end users have to go out to the partner’s site, get a list of new orders and manually enter them into our system.  The entire process is inefficient and distracts people away from their normal duties.  When complete, the integration will allow the partner to send orders directly to our system without human intervention (in most cases).

There are several ways to do integration.  Enterprise Integration Patterns outlines 4 at the start of the book: File Transfer, Shared Database, Remote Procedure Invocation (RPC), and Messaging.  We chose a mix of RPC and messaging.  The RPC via web services was selected as the way we communicate with the partner mainly because the partner already has an infrastructure built around web services.  Internally, we use a mix of web services and pub/sub messaging via MassTransit.

The architecture for the solution has four main parts: an external facing web service that the partner calls, a windows service for workflow (MassTransit saga) and integration business logic, a web service into our primary application, and a web service the external partner hosts for us to send updates to. There are many benefits to this architecture.  The external facing web service can be placed in a DMZ which only allows inbound calls to be routed to MSMQ, the windows service can be taken offline for maintenance without affecting the partner’s ability to send orders, loosely coupled components with clear and distinct responsibilities, and each part can be scaled independent of the other parts.

The order process is kicked off by the partner calling our web service and sending over a message for a new order.  In addition, the partner calls the web service once for each line item on the order.  Our web services takes data from these calls, transforms it into an object model, validates the data, and publishes messages via MassTransit.  The windows service has a saga that consumes the messages from the web service.  When the saga determines all the pars of an order have arrived (the order  and its line items), it calls a web service in our primary application to create the order.  At this point, the users can go in and do what they do with the orders.  As the orders progress thru the order application, messages are published about state changes.  The saga in the windows service consumes these messages and sends updates back to the partner’s web service.

In the end, the integration should add significant business value by increasing the overall efficiency of our employees and reducing errors caused by manual data entry.

No comments:

Post a Comment