Introduction
When you implement process integration scenarios there are three important things to consider. The first is the list of technical capabilities provided by the components involved (i.e. application systems, middleware, etc.). Another thing to consider is the project team knowledge of process integration design, and finally the third, and more generic, is related to general software development and implementation knowledge. Considering these three things you can get rid of a large number of problems that might arise either during the implementation project, or (what is worse) once in productive operation.
It is not enough to discover a way to, for example, transfer one document from one place to another in development environment to consider that this same solution is going to work in production environment as expected. There is a list of other requirements to comply with. Is it the best way to do it? What happens if the process fails? Will it support the required throughput? Is the response time sufficient? What is the required quality of service? Is the service level agreement of every component enough for the business needs? What if we want to develop new versions later? Etc… Etc…
Also, beyond the scope of process integration, it is necessary to comply with a methodology during the implementation project (and also in continuous improvement, even when it is not considered here…).
Process Integration Design in General
Process Integration Architecture - Typical replication requirements :This document will show you the different requirements you usually need to meet when you replicate information among systems. It will show you the differences between synchronous and asynchronous business level replications. Also this information will help you decide how to implement a process integration scenario and recognize the issues and needs that each technique should provide.
Process Integration Architecture - Common Design Issue in Synchronous Replications This document shows a typical design issue that appears when you replicate information using synchronous methods in SAP application systems. It also provides some possible solutions.
SAP Technology Specific
Process Integration Architecture - Replication Layers in SAP Application Systems : This document shows you the different layers used for information replication in SAP application systems based on SAP NetWeaver technology. It provides a detail of each layer and shows how they interact.
SAP NetWeaver Exchange Infrastructure Specific: Methodology, Software Structuring, Naming and Design Patterns.
Methodology
Roles & Procedures in Integration Projects: This document is an XI methodology document. It provides a list of involved roles and the sequence of steps that you typically perform when implement a process integration scenario. You can use it as a basis to develop or enhance your existing methodology.
Naming
Another interesting document is the first version of the naming guide (Best Practices for Naming Conventions). This guide gives you interesting patterns to consider in terms of names and software structuring for reusability.
Best Practices and Design Patterns
Need to get a SAP NetWeaver component implemented quickly? Try SAP Best Practices: It is a nice presentation of SAP Best Practices written by Marian Maravilla. Also you can find in several documents on SDN and SAP Help portal that provide tips regarding how to use XI (or not…).
The SAP Help Portal also provides some very interesting scenarios ( SAP Best Practices for Business Process Management-> Business Information -> Preconfigured Scenarios) you can take into account.
Additionally, you can find the best compiled list of best practices and design patterns in the SAPTechEd presentation: EPI204- Design Patterns for SAP NetWeaver Exchange Infrastructure.
Conclusion
I encourage you to take a look at these documents prior to start your process integration project, because they will provide you interesting information that could help you prevent design errors, improve the solution robustness and simplify future maintenance resulting in higher quality software.
