It is remarkable how similar the middleware on the market is at the moment.  Working with Bharath Yadla, I evaluated WebMethods, Oracle’s BEPL engine, and BizTalk 2006 and was amazed at how similar they were.  Even the screens look similar.  It is as though the same people wrote them simply using a different technology (Java or .NET).  In the end, the reason BizTalk one out was entirely because of cost.   
Generally, the middleware products have a set of line-of-business (LOB) adapters for calling into LOB applications like PeopleSoft, JDE, Oracle eBuisiness Suite (EBS), and Siebel.  (This just happens to be the list of applications I have to integrate at Itron.)  The common problem with all the adapters, however, is that they call the LOB APIs and it appears these APIs are very ugly for doing integration… the very task you would think they were designed for.  Consider an example:
Subscribing to the Data
Imagine that you want to have all new employee records extracted from PeopleSoft into EBS.  (Pushed would be preferable to extracted but lets ignore that complexity.)  The first step of course is to extract the data from PeopleSoft.  Fortunately, there is a component interface for doing this type of thing.  Unfortunately, it requires that you pass in the ID of the employee you wish to retrieve.  Now how the heck is the middleware going to know what the employee ID is of the new employee you want to extract?  There are several approaches but essentially you have to write custom code within PeopleSoft that publishes out (into a file or a web service call) the new employee ID so that it is then possible to call the API.  Alternatively, you have to connect to the underlying PeopleSoft database using a database adapter (DB2 in my installation) to retrieve the employee ids, cross reference it against a list of previous employees, and then call the component interface to retrieve the details on the employee.   Okay, so now you have the employee record in BizTalk.  The next step is
Publishing the Data
Now it is necessary to push the data into EBS.  This involves calling the EBS APIs.  The problem is that the APIs have lots of parameters that are flex fields or foreign key references.  How does the middleware know what the primary key value is for the employee’s position that it is are inserting?  Instead, the middleware needs to call a different API, pass the position name as a string, and then get back the position’s ID so that it can then call the employee API for inserting the data, now using the position ID value.  Yuck!  And this has to happen for each flex field/foreign key and each call is over the network.  Why on earth don’t these APIs support a lookup directly on the original APIs?  In other words, why can’t I call the employee insert API and pass the name of the position?  That way the API would do the lookup directly within EBS rather than the middleware making a distributed call to retrieve it. 
The frustrating thing is that this appears to be true for virtually all the LOB APIs that I encounter and, as a result, all the LOB adapters that I attempt.  It just seems ludicrous.

Wednesday, May 03, 2006 3:25:17 PM (Pacific Standard Time, UTC-08:00)      Comments [1]  Computer Related | .Net