Using Local and Central Enterprise Services Repositories 
In a federated landscape design, you can choose between the following constellations with regard to the Enterprise Services Repository (ES Repository):
Using a separate “local” ES Repository for each PI instance
In this setup, on each PI instance within the landscape, one ES Repository is hosted and directly connected to the “local” Integration Directory and runtime engines (Advanced Adapter Engine, Integration Engine in case of dual-stack installation).
One disadvantage of this setup is that ESR content needs to be synchronized between different local ES Repositories and transport scenarios have to be scheduled accordingly.
Using one “central” ES Repository and connecting each local PI instance to the central ES Repository
In this setup, only one ES Repository is hosted on the central PI instance. The Integration Directory and the runtime engines (Advanced Adapter Engine, Integration Engine in case of dual-stack installation) of the local PI instance are directly connected to the central ES Repository.
The advantage of this option is that you can minimize total cost of ownership as the number of ES Repositories is minimized. You can minimize the need for transport scenarios and administration tasks like user management.
The following figure illustrates for the dual-stack installation option how the most relevant PI components interact in a central ES Repository landscape design.
Constellation of PI Components when a Central ES Repository Is Used (for Dual-Stack Installation)
When you use a central ES Repository, the involved PI components communicate with each other in the following ways:
Integration Directory (local and central one) calls central ES Repository in order to access design objects for input helps.
This communication is needed in order to enable an Integration Directory user to open a (central) ES Repository object from the (local or central) Integration Directory. In the following, examples for this kind of access are given:
Creating any configuration object (for example, integrated configuration) with a service interface as key element: select service interface from ES Repository (for example, to specify the receiver interface key field in an integrated configuration).
Editing integrated configuration: select operation mapping from ES Repository.
Creating communication component (type integration process): Select integration process from ES Repository.
Central ES Repository sends cache notification to the central Integration Directory after a design object in ES Repository has been activated or after an import. As indicated in figure above, the central Integration Directory then sends a cache notification to the relevant local Integration Directories (as necessary).
NoteLocal Integration Directories cannot be notified directly be the central ES Repository.
End of the note.Central ES Repository calls central Integration Directory in order to access a list of communication channels in case mappings with mapping look-ups are tested.
In order to perform cache connectivity tests, the central ES Repository calls the central Integration Directory in order to obtain cache connectivity test data. Central Integration Directory calls the local Integration Directories to obtain the relevant test data (to be forwarded to the ES Repository).
Caution
It is mandatory to use a central System Landscape Directory (SLD) in case you configure your PI instance to use a central ES Repository. All PI systems sharing the same central ES Repository must be registered in the same (central) SLD.
Recommendation
Be careful when switching a PI landscape with a lot of existing content to central ES Repository usage. It is recommended to configure usage of central ES Repository once when the PI landscape is set up and not during productive usage. Note that switching to a central ES Repository can invalidate existing configurations in the Integration Directory (because ESR objects might be missing in the central ES Repository).