WHAT IS EAI?
Over the course of time, a given company will tend to accumulate an enormous amount of software: inventory management, order processing, an ERP system, and much more besides. Often, the individual programs are introduced bit by bit, with the application that seems most suitable for the task at hand being chosen each time. This almost inevitably results in each program coming from a different manufacturer. And that means each of them works with its own file formats, databases, and so on.
Now, it would make a lot of sense to connect these different programs with each other, since they actually work on the same data – at least within the logic of the business. For example, it would be great if a program for registering orders could check with the inventory management software whether a particular item that has just been ordered is in stock, or if it needs to be reordered. That would make it possible to give the customer a reasonable idea of the delivery time straight away without the account manager having to phone the warehouse manager first to check. A fully automated process.
That’s where EAI comes into play. After all, inventory management and order entry aren’t the only two systems that need to be able to talk to each other. In the final analysis, every single IT system will probably need to be able to talk to at least half the others in the company. But instead of teaching each of them the dialects (or interfaces) used by all of the other systems, we handle all this communication centrally via a single system that acts as a kind of interpreter. This the EAI system.
A simple example:
Of course, the example we looked at just now was a very small-scale one, but it will do as an introduction. With that in mind, let’s assume that an account manager wants to input a new order into the order entry system. This system is capable of generating an order confirmation that can be sent to the customer. The fact that both of these processes should run in a largely automated manner nowadays falls under a different topic (EDI).
For now, however, this order confirmation should also display the delivery time – or at least an approximation of it. To do that, it is important to know whether all the items ordered are in stock, or whether any of them need to be ordered in. And if they do need to be ordered in, their delivery times should also be determined. But one thing at a time.
First of all, the order comes in. That means the order entry system – which we will call the OES here – receives a list of items. This list includes two copies of the item numbered 4711. The question is: do we have two copies of that items in stock? The EAI system checks this for us.
Conveniently, the inventory management system works with a normal SQL database. Yet it wouldn’t matter if it were an Oracle, a MySQL or even an MSSQL database. All we need to do is fire off a statement to the database, which then provides us with the current stock of the item in question. Anyone who knows SQL will understand it straight away:
SELECT stock FROM inventories WHERE itemnumber = “4711“
For everyone else, here is the translation: From the table “inventories”, give me the value of “stock” in the row with item number “4711”. The database now returns a number – let’s say 543. That means we have more than enough stock. As a result, we can offer a very quick delivery time for this item, as we can send two copies on their way before the end of the day.
That’s EAI. Simple, isn’t it?
The key points are: The OES doesn’t know anything about the IMS (inventory management system) or its database. It simply informs the EAI system somehow (or the EAI system finds out for itself) that there is a new order. The EAI system then runs a check against the IMS and hands the information back to the OES so that it can issue an order confirmation with appropriate delivery times.
OK, we admit, it’s almost too simple! It’s perfectly possible that the inventory data can’t be retrieved from the database in such a straightforward way. Or the database might report that there are no longer enough copies in stock. Let’s say that item 4711 has run out and needs to be ordered in. Now, things get more complicated.
A more complex example:
Item 4711 has run out. That means we need to order it from our supplier. Unfortunately, the supplier holds that product under its own item number, which our OES doesn’t recognise. As a result, after getting the red light from our IMS, the OES needs to find out the supplier’s item number for this particular item – as well as who will deliver it to us, of course.
Let’s keep things simple again and take a database that contains both the internal item number and the supplier’s number. The database is different this time, but the principle is the same. I’ll spare you the statement – this isn’t an SQL course, after all. The answer comes back: item number “A08/15” and supplier “Hardware Provider”, since this particular item is a piece of hardware. This information could just as easily be obtained from SAP, in which case the request would be made via an RFC call.
However, we now find ourselves in a tricky situation, since we really wanted to write about EAI – i.e. the integration of internal systems – but we now need to make a request to the company Hardware Provider which will cross the boundaries of the business, and thus falls under the category of EDI. That’s the problem with these things – they aren’t always so easy to separate. Of course, we can now do the following things: Let’s assume that we have an EDI package to go with our EAI software, so we can now make a request to that. We want the EDI system to ask Hardware Provider when item 4711 – aka A08/15 – can be delivered to us. Our EDI software is equipped with a SOAP interface for this purpose, which can be called up as a web service. So let’s put together a quick request:
<?xml version=“1.0“ encoding=“UTF-8“?>
<soapenv:Envelope
xmlns:soapenv=“http://www.w3.org/2003/05/soap-envelope“
xmlns:xsd=“http://www.w3.org/2001/XMLSchema“
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“>
<soapenv:Header />
<soapenv:Body>
<requestdeliverytime>
<supplier>Hardware Provider</supplier>
<ItemNo>A08/15</ItemNo>
</requestdeliverytime>
</soapenv:Body>
</soapenv:Envelope>
The EDI software forwards the query – if possible as a web service call – to Hardware Provider’s system, and then delivers the result back to us. But first it needs to check what kind of business Hardware Provider is, how to get in touch with it, and so on. And then it might need to retrieve the information from a database, which in turn… Argh! We could just have easily gone and knocked at their door ourselves!
If you’re currently thinking, “What rubbish – why have two systems when the work could easily be done by one?” then you’re quite right. So now it turns out that our EDI system can query databases in the same way as the EAI system? And the EAI system can query web services in the same way as an EDI system? If that’s the case, it’s completely pointless to have two different systems.
Everything should really be brought together in a single system for precisely that reason. However, what we are doing here is providing an initial explanation of the different concepts, which distinguishes between the integration of systems within a single company and communication between systems owned by different companies. The theory isn’t interested in the fact that these two things are closely related, and that it is often complete nonsense to suggest that there is a separation between different systems.
To quickly finish up our example: Once stock levels have been queried in our own IMS or in the supplier’s system, the order can be processed by entering the appropriate delivery time and sending an order confirmation with a predicted delivery time to the person submitting the order. Oh, but wait – now we’re back to EDI!
TO SUM UP
EAI can be defined as the interconnection of multiple internal IT systems – not in a number of 1:1 relationships, but in a star-shaped or daisy-chain configuration. In this context, people often talk about a “hub and spoke” architecture, in which the EAI system forms a hub that communicates with the different systems in its IT landscape via a series of spokes.