“Real Simple Integration (RSI)” is a term introduced to promote an easy-to-use integration pattern for system-to-system interconnectivity.
System integration is a costly and complex task. The goal of RSI is to make system integration as easy as possible. The RSI integration pattern is based on
- simple XML files (i.e. human-readable with zero overhead)
- which are written to output file directories and
- read from inbound file diretcories
- by business applications
RSI considers system integration as a strict sequence of “Input-Process-Output” (IPO) units. The processing unit is the business application. Input and output management is standardized by RSI.
Simple Integration Scenario
The basic concept of RSI can be explained with a simple integration scenario: A company uses a CRM system and an ERP system. All incoming orders are first entered manually into the CRM system but need to be sent to the ERP system as well. Three things are required to make integration work in with RSI as architectural style:
- OUTPUT: A CRM system that supports RSI would provide a mechanism that automatically writes the newly entered order as XML documents to an outbound file-directory.
- ROUTING & TRANSFORMATION: Anything from a simple scripting program to a sophisticated mapping tool or message-oriented-middleware (MOM) does the transformation to an XML file that fits the requirements of the target system and writes the resulting XML to a inbound-file directory of another RSI-enabled system. The transformation program may synchronously access data required for the transformation via REST interfaces of other back-end systems or e.g. mapping tables.
If both systems share the same business semantics, i.e. that the structure of the XML document as well as relevant master data (e.g. customer number) are common, the chances are high that no intermediate is required. - INPUT: The ERP system checks the inbound file directory for newly created XML-files on a regular basis. If an XML file is written to this directory, it need to be read automatically into the system and appropriate steps are taken (e. g. check consistency, internal creation of an order, calculation of a proposed delivery date, and finally creation of a shipping notification).
RSI complements REST for asynchronous, message-oriented integration. To begin with RSI, little and simple additional software is required. However it requires software companies do add “the RSI-feature” to their products.
One important thing to note: RSI does not standardize
- the structure of business documents (e.g. sales orders)
- the transport mechanism used to move XML-documents from one system’s outbound file directory to the other systems' inbound file directories:
There are a magnitude of approaches and tools available that solve this problem (e.g. file copy tools, FTP, SMTP, HTTP, Message Oriented Middleware) and different integration processes may have different requirements (e.g. regarding security).
Integration Scenario using a MOM or BPM engine
In a more sophisticated scenario, the transformation, the routing to inbound directories and more sophisticated business process management tasks could be done by a dedicated BPM engine like in the picture given below.
Following this approach, companies implement a pure Event-driven-Architecture.
Business-to-business integration
The RSI approach scales very well to business-to-business scenarios, where proven messaging mechanisms may be used, e.g. HTTP, FTP or SMTP.
The advantage of RSI is that the core integration task is as easy as thinkable and the functional requirements of “Transformer & Router”-engines are very little. This allows business integration for even the smallest company.
Imagine a scenario where a big wholesaler wants to seamlessly integrate a small supplier of packaged goods.
- The wholesaler places its orders in a specific directory on his own FTP server. The directory is access protected so that only the supplier has access to it.
- The supplier needs a simple program to monitor the FTP server for incoming XML-orders. The program would read the new XML files and transforms it in the format that its own business application needs. This program could be easily and fast written in a scripting language like Perl or Groovy.
- The transformed XML file is stored in a directory that the supplier’s business application is configured to read. The RSI-enabled business application would automatically read the XML file and generate the internal order.
Additionally to the integration scenarios mentioned above, RSI could be easily used for mass-upload of data.
Standards for building the XML file
The guideline how to build XML messages can be taken over form REST as described in Roy Fielding’s dissertation or - if already specified - according to OAGIS' Business Object Document (BOD) definitions. It is important for the success of RSI that the XML documents are easy to read and understand.
The naming convention for XML filenames should follow a simple rule:
e. g. SalesOrder_(SAP_R3_46C_SO5)_MIP_2007-07-19_23:12_23455.xml
XML documents that could not be processed should be placed in a dedicated error directory and the name of the XML file should have an error code as prefix.
e. g. E0013_SalesOrder_(SAP_R3_46C_SO5)_MIP_2007-07-19_23:12_23455.xml
The error codes are not standardized yet.
Advantages of RSI
The biggest advantage of RSI is that system integration becomes very easy. Most of the existing approaches require detailed integration knowledge, e.g.
- which protocol to use,
- understanding of the Integration-API and the programming language (e.g. Java, C#),
- knowledge of very extensive integration frameworks (e.g. COM, CORBA, EJB)
Comparison to SOAP
RSI is relatively similar to SOAP as it is based on XML standards and focuses on simplicity. Though some differences are important:
- RSI is not a protocol
- RSI standardizes the “inbound transport layer" to be a file directory
- RSI-style XML files don’t carry any overhead and should be human-readable
- RSI is asynchronous by definition
But most importantly: none of the involved systems need to know each other. This is very different from SOAP. SOAP requires an application to know which service to use and service contracts need to be established. This is not the case with RSI. RSI is based on the concept that each system or component is completly self-sufficient and does not need to know other parts of the (internal or external) system landscape. The "business logic" to control the data flow is managed in dedicated components, e.g. a simple routing tool or a sophisticated BPM engine.
Similar approaches
SAP - One of the largest business application vendors, SAP, provides since several years a mechanism that is pretty similar to RSI. This mechanism is called ALE with IDOCs. IDOCs are “Intermediate documents” that are sent from one SAP application to another. However IDOCs follow an EDI-style-format that is not easy to understand. Therefore ALE and IDOCs are used mostly in SAP-to-SAP communication and rarely used for SAP-to-Non-SAP-integration tasks. The following picture shows a sample IDOC. It is obvious to see, that IDOCs are not self-explanatory.
Infor - Infor became the third largest business application software provider in the world through massive aquisitions. Infor decided to implement an RSI-like approach to integrate their heterogenious software solutions. Infor is using Sonic ESB as BPM Engine (more info in German can be found at http://www.computerzeitung.de/article.html?thes=&art=/articles/2007013/31030959_ha_CZ.html).
Summary
RSI is in general nothing new. However it is not a general accepted approach and therefore it is not yet supported out-of-the-box by most software vendors. Some provide:
- proprietary APIs, e.g. in Java
- interface tables in relational databases
- proprietary, non XML-based message formats
RSI does not require much from a technical point of view. However it requires support of each individual software vendor. RSI requires software vendors is to provide:
- an easy to configure mechanism
- to automatically write to and read from
- a file directory
- business documents (e.g. orders, master data)
- as simple, human-readable XML documents
- if certain customizable rules apply (e.g. new order created or order changed)
No comments:
Post a Comment