Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Interface by Example
Let's say that we are attempting to integrate an ERP system that was just configured and installed at the site of our supplier and our long-running, custom COBOL system. Both systems exist on their own processor at their respective sites, connected by the Internet. To further complicate our task, let's assume that a data-oriented B2B application integration solution won't work in this problem domain because of the complexity of the databases and the binding of logic to the data. As a result, any attempt to integrate the old and new applications should take place at the application interface.
In our example, we are fortunate that the ERP vendor understood and anticipated the need to integrate business processes and data with the outside world. The vendor provided an API that works within C++, C, and Java environments, with the libraries that drive the API downloadable from the company's Web site.
For example, from a C application with the appropriate API libraries existing, the function GetInvoiceInformation(“12345”) would produce the following:
<BOM> John Smith 222 Main Street Smalltown, VA 88888 Invoice Number: 12345 001 Red Bricks 1000 .50 500.00 <EOM>
The information returned from the API call is generated by invoking an API and passing an invoice number as an argument. For processing, this information would have to be placed within the application program in an array or in another memory location. From this point, the information may be placed within a middleware layer—such as a message broker—or within XML, for transmission to other systems. Of note is that the database itself was never accessed. Furthermore, the data is already bound to a business entity—namely, an invoice.
Using this same interface, we can also get at customer information—with GetCustomerInformation(“cust_no”)—or inventory information—with QuantityAvailable(“product_no”).
Our example might not be so straightforward in COBOL. Here, the developer and application architect who built the application failed to build in an API to access encapsulated business processes. Therefore, the application must be redesigned and rebuilt to expose an API so that the processes of the application may be bound with the processes of the remote ERP application.
The generally high cost of development and testing makes building interfaces into existing applications an unattractive option. However, let's assume in our current example that application interface-oriented B2B application integration is the best solution. After we've gone ahead and built an interface into the COBOL application, our next move is simple: Select the right middleware to bind to the ERP API within the supplier and the custom application API locally. The middleware then allows the B2B application integration developer to extract business information (such as credit information) from one and place it in another. Middleware that will work in this scenario might include message brokers, message-queuing middleware, and application servers.
Unlike data-oriented B2B application integration, the interfaces in this example can provide access to both data and business processes. This is precisely the reason that we go to the trouble to employ an application interface-oriented API. Unfortunately, the type of business information that we will be able to access is limited by the features and functions of the interface. That's the unfortunate trade-off with application interface-oriented B2B application integration.