If your company, like many others, is conducting an R/3 integration project that focuses on bringing not only R/3...
data, but also R/3 processes to the Web and combining them with external systems, what considerations do you need to keep in mind? These tips, based on real-world experiences, will help you to avoid some of the common pitfalls many companies fall into.
If you are going to build an alternative Java-based frontend to R/3, be prepared to:� Analyze your processes and determine which BAPIs fit your needs � if you cannot find any, search for RFMs, or, worst case, write your own RFMs or BAPIs.
� Wrestle with multilingual field descriptions
� Wrestle with conversion problems
� Perform multiple BAPI and RFM calls in a transactional context
� Visualize complex and hierarchical data
If you are going to build a cross-platform Java integration layer that will connect existing (legacy) systems to your R/3 system, you will need to have answers to the following questions:
� Does platform independence play a role?
� How easy is it to modify processes inside R/3, and do you have the appropriate resources to do it?
� Does it make sense to transport or connect processes inside and outside R/3?
� Is it required to maintain an open standard for connecting other systems in the future?
� Is support for a transactional context necessary?
� What skills are available in your company?
When starting an integration project, first describe the integration scenario with all its business processes, then start your architecture discussions. Determine all important project parameters and how best to use a distributed environment, across which you will need:� Applets
� JavaServer Pages (JSPs)
� Remote Method Invocation (RMI)
� Enterprise JavaBeans (EJBs)
When talking about Enterprise Java applications (servlets and EJBs), you also have to consider an application server. It ensures that your application will scale and that you have a transactional environment.