views:

117

answers:

2

I keep seeing vacancies for software developers that require EAI experience.

From what I can figure, this means someone with experience developing with one of the large commercial off the shelf (COTS) packages (SAP, Oracle, SalesForce etc).

As I'm not working in a company that doesn't have any of these systems, how can I gain EAI skills?

For the people that have developed SAP/Oracle/SalesForce ERP/CRM systems, what kind of coding work is involved? Is it developing classes (and is this Java or some other technology)? Do they have web service endpoints that you can hook into? Can the UI be customized?

Are there any books that I can learn from? I have heard a lot about this one, but it looks quite dated now (no mention of web services and all just messaging).

Is EAI just about design patterns? Is it just another buzzword for SOA?

Lots of questions I know, but I'm really stuck! Thanks community! :)

+1  A: 

Is EAI just about design patterns? Is it just another buzzword for SOA?

Design patterns are various ways (used in the relevant scenarios) in which you can do a particular task (in this case enterprise integration). Using messaging queues is one of them.

It is related to SOA in the sense that if you expose your functionality in the form of web services, other systems would be able to "integrate" your functionalities into theirs, using calls to your web services. Since most of these requests are executed asynchronously, they are implemented using Queues.

I have worked on customizing oracle applications before and it needs good knowledge of the Oracle applications framework, the data model that it is built in addition to any other technoogy that you want to build your own components/extensions on. As you suspected, many of them provide pluggable end points that you can hook into to either invoke their services.

I believe the same is true for SAP and other ERP systems. they expose APIs, web services which can then be invoked. Take a look at this for some basic overview of SAP interface design.

http://help.sap.com/saphelp_nw04//helpdata/en/ba/d4c23b95c8466ce10000000a114084/content.htm

Apart from the relevant technologies, XML, XSLT (and related tools) would probably be the most important skills you'll need to understand message Queues and the integration process.

Hopefully, that answers one of your qestions.. I am looking forward to the answers from the otehr gurus out there.

Rajesh
Great stuff, thanks!
Lance
This site from "Gregor Hohpe" may also be helpful. It is from http://www.eaipatterns.com/.Not specific to a particular ERP tool though.
Rajesh
+3  A: 

I am certainly not a guru - to use Rajesh's term :) - but here's my 2 cents...

I've always looked at EAI at a higher level - meaning, I don't think having experience with ERP systems (sAP, ORACLE, etc..) is a requirement. What is required, I think, is the ability to understand how one system can talk to another (within the enterprise) and thereby "integrate" each other's functionality. Of course, having experience with ERP systems won't hurt you in these situations.

SOA is part of EAI - probably a pretty big part since in many cases the only way some of these systems can talk to each other is through services (i.e. web services).

This might be a very simplistic approach but as a point to start at, you could create a web service that retrieves data from one system and gets called from another system where the data is shown or is used in a calculation.

You see, the basic idea - IMHO - is to have data accessible among systems; whether the data is coming from an EPR system or some in-house app that you developed is irrelevant.

Hope this might help a bit; I, too, look forward to reading other replies...an interesting question.

E.W.

TheSiteMan
Great thanks - what is the difference between enterprise application integration and just application integration though? What does the enterprise bit mean?
Lance
In a word, scale - application integration is application integration - at whatever level. The "enterprise", in my view, means - across an entire organization. Interestingly enough, it could be integration between two applications or among 10 of them. To some degree, processes come into play here as well; but that's a another matter.
TheSiteMan