In part 3, I described our application integration framework pattern at the level of BusinessFlows.  A BusinessFlow contains 2 or more Applications and 1 or more Connections.  I described how the framework pattern works with Applications and in this post we discuss Connections between Applications.

 

A Connection represents a logical connection to each Application, and physically to each Applications Adapter.  A Connection contains 1 or more DataFlows.  A DataFlow is a collection object that contains other objects, which we will describe in a minute, but its construct allows us to contain one to many DataFlow rows.  Each DataFlow row specifies the direction in which the communication of messages (i.e. data) flow.  It also specifies which Application in the integration scenario has initiated the event in the communication, either in real-time or on a scheduled (i.e. batch) basis. 

 

For example, if I have MS Great Plains on one end of the connection and the Corporate HQ Financial Application on the other end of the connection, I can specify that MS Great Plains will be the initiator of the business event and the messages (i.e. financial data) will flow from MS Great Plains to the HQ Financial Application.  Further, I can specify the DataFlow row type of communication.  For example, one-way asynchronous, one-way asynchronous, two-way request response synchronous, and two-way request with delayed response (i.e. synch on aysnch).

 

As mentioned above, a DataFlow contains a collection of objects, specifically, 1 to 4 schemas (i.e. XSDs), 0 or more rules, and 0 to 2 maps.  A map is an XSL transformation, using a visual editor that allows a BA to map from one schema format to another.  Anyone familiar with the BizTalk Mapper tool will recognize our visual editor as the same representation, except we expose our Mapper tool over the internet in our Rich Internet Application (RIA) Visual Designer.

The reason for 1 to 4 schemas is that depending on the communication type and whether it is a pass-thru or not with respect to message flow.  For example, in our MS Great Plains to Corporate HQ Financial Application, we have specified 2 message schemas, one for the Great Plains format and the other for the HQ Financial Application, in a one-way asynchronous dataflow.  We also have 1 XSL map that transforms the source Great Plains message format into the destination HQ Financial Application format.  Further we may have specified certain rules to be executed either before and/or after the mapping transformation.

 

As mentioned above, our DSL Visual Designer is exposed over the internet as a Rich Internet Application (RIA).  We also provide a facility for a BA to upload any custom message schemas that have developed.

 

In my next post, we will discuss the Rules Designer, which is important to BAs and their business as this is where any data processing of the data occurs.