Skip to Content

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.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Daniel Bianchin Post author
      Hi David, Thanks for your comments.

        I think you have been able to summarize the spirit of the weblog in one paragraph.

        Regarding process integration matters the “solution-set” changed a lot in latest years. I mean, the evolution of technology and standardization of protocols, languages, etc. nowadays allow us to concentrate more on business level issues and not waste time on the underlying technical details (I remember myself writing APPC level sockets or RFC programs in C…). Even the -in other moments- most strange platforms, now support open standards.

         If you take a look at the requirements article, and you have been implementing PI project in the past using technology from different vendors, you can tell how nice is to work with SAP technology and how many of these usual customer requirement are automatically addressed nearly without development on SAP side.

      (0) 
  1. Dries Guth
    Hi Daniel,

    very very nice considerations you did in your blog.

    Im am currently working on the same level in developing design approches with the process integration and have a lot of approaches, solutions and design aspects in mind (regarding SWC Design, Object reusability, Template developments etc etc…).

    Im am highly interested in your Naming Conventions but the link seems to be not available. I have worked out many of our company wide used Naming Conventions and Development Aproaches as well and I want to discuss some main issues (if you want) with you. Can you repair the link to your naming convesntions? Are you also available at Xing?

    Best regards,
    Dries

    (0) 

Leave a Reply