As we approach year end, I believe it is important to get back to the roots of my column: JD Edwards integration. I am uncomfortable calling myself an expert, I feel more like an observer of experts, but people come to me frequently with questions about how-to integrate JD Edwards ERP systems to XYZ. In fact, I am often asked what it takes to learn the Magic xpi Integration Platform, or to put it another way, I am asked what people need to learn about the Magic xpi Integration Platform in order to be prepared to do JD Edwards Integration.

Someone with ambitions towards JD Edwards integration needs to learn the development principles and fundamental techniques of creating an integration project using Magic xpi, including testing, deploying, and maintaining the project in runtime. Prior to tackling such a project, you should already be familiar with database concepts such as tables, rows, fields, indexes and the relationships between these objects. In addition, you should take a referesher on XML and related terms such as XSD, element, compound, and even namespaces. It is also very useful but not mandatory to already know something about SQL statements; HTML technology and tags; Web services concepts such as knowledge of UDDI and WSDL.

The next step in learning Magic xpi Integration Platform after moving beyond these prerequisites is to become familiar with the integration concepts, development environment, and components of Magic xpi.

Integration projects have a methodology. You will need to learn how to approach the development of a Magic xpi project and appreciate the importance of following a standardized methodology to optimize the development process and then begin designing the integration in that project. This involves documenting the design of the project according to the business logic and the topology. Defining the topology is fairly simple as you are simply describing the world as it is. Defining the integration itself, is designing the world as it will become.

To do this, you will need to learn to populate the resource repository which contains the various external sources for the project. In many respects, this is an extension of the topology definition but with the level of physical details necessary for execution (such as server names and IP addresses).

Once the project resources have been defined and arranged in a topology, the business processes in the project are known. It is now possible to actually begin writing the executable integration flows of a project, however, it may be desireable to define the business processes at a high level first because you can take the business process model and turn the logical flows into actual flows. You can start using some basic components and the Magic xpi Debugger, which is used to test flows.

Some name

Glenn Johnson is Founder and Principal Consultant at Cumulus Marketing. He's been a popular speaker at COMMON, Collaborate, Quest Regional Users Groups and many other conferences and has appeared as a Tech Expert on NBC Today, Discovery Channel and E!