ESR strategy for complex landscapes
By Julia Doll, SAP NetWeaver Product Management - SOA Middleware
When businesses move to SOA they have to take different approaches into consideration depending on their landscapes. The landscape can be grouped into domains according to different criteria. Complex landscapes can be divided into three domains: development, test and production. In that case, the services are developed in the Development system, tested in the Test system and after quality assurance(QA), they will be used in the production system.
All domains use different registries because the services' endpoints refer to different systems. It is recommended that every domain has also its own repository, but the same content to guarantee the integrity and consistency of the whole business. The repository contains all the governance guidelines and rules. It also assures that those are followed. The landscape can run one local Enterprise Service Bus (ESB) in each domain, but one central global ESB is needed that controls the flow between the different domains.
There are various challenges regarding the integration of different systems. We are going to discuss only a few complex scenarios in this blog.
Complex Scenario 1: Service enabling legacy applications
A landscape incorporates old legacy systems in all domains, which do not support the Web Service protocol. These systems should be Service enabled with SAP NetWeaver PI 7.1 (SAP NW SOA Middleware - PI 7.1). First, the legacy system applications in the development system are service enabled and stored in the Enterprise Services Repository and the configuration objects are stored in the Integration Directory. Then the quality of the new services is assured in the test system before they will be moved into the production system.
Follow up Complex Scenario: Consumption with SAP NetWeaver Composition Environment
SAP NetWeaver CE (SAP NW CE) is going to be integrated into the landscape as well. In that case, the repository of SAP NW CE should be connected to the repository of SAP NW PI, which is then used as central and exclusive one in order to reduce traffic and to keep the repository central. The content should be replicated from the development to the QA and finally to the production system.
Complex scenario 2:
SAP NW CE 7.1 is integrated into a landscape that runs an old version of SAP NW PI (SAP NW PI 7.0 or XI 3.0 and still uses the old message interfaces). The old message interfaces are stored in the interface repository of the previous SAP NW PI version (PI 7.0 or XI 3.0). To use them with SAP NW CE, you can either store them as message interfaces or service enable and save them as Web Services.
Follow up scenario A:
After upgrade to SAP NW PI 7.1, all old message interfaces are service enabled and stored in the SAP NW CE 7.1 Repository. Then the content of the repository of SAP NW CE is just copied to the new SAP NW PI 7.1 repository. The strategy followed then onwards is the same as mentioned in the previous scenario that is using the SAP NW PI7.1 Repository as exclusive and central one.
Follow up scenario B:
After upgrade to SAP NW PI 7.1, all old interfaces, which are stored in the SAP NW CE 7.1 repository, are also moved to the repository of PI 7.1. Therefore, the contents from both repositories will be merged into the repository of SAP NW PI 7.1. The services in the repository of SAP NW CE are just copied to the repository of SAP NW PI7.1, where they are merged with the services from the integration repository. Then onwards, the repository strategy is the same: the repository of SAP NW PI 7.1 will be used as central and exclusive one.
