How many ESR's in your landscape

[petr_solberg]

Hi Services Repository Experts,

we have CE and ECC and PI.

PI is our Services Repository.

Question, in our landscape, if we have

Development Line (for CE, ECC, PI etc)

Quality Line (for CE, ECC, PI etc)

Regression Line (for CE, ECC, PI etc)

Production Line (for CE, ECC, PI etc)

How many Services Repositorys is it good practice to have ?

eg, All non-Prod systems use the DEV PI as SR

and

Prod systems use the Prod PI as SR

or

every line, Dev, Quality, Regression, Production, every line has its own unique SR serving

only that layer of the landscape ?

Does anybody have any insight into good practices in this design.

Thank you and kind regards,

Petr.

[Former Member · Accepted solution]

Hi Petr,

Firstly, I must admit, I'm struggling to understand your question...

Let's rather use the acronym ESR for the Enterprise Service Repository. The acronym SR is normally used for Service Registry.

If you have a PI installation for each of your lines (Dev, QA, Regression & Prod) then surely there would be a PI ESR available for each unique line. So you would do your Dev work on PI Dev & then tranport your development through the different lines as required.

In your first scenario (i.e. one ESR for non-prod systems), you would then need to transport your PI development from PI Dev straight to PI Prod, that won't be best practice at all. So one ESR per line would be my answer.

Now: If you meant Service Registry (SR) instead of Enterprise Service Repository (ESR), then you'll have a totally different answer. This would vary on you use cases for the SR. If it's only being used during development (which is how it is in most cases) then only one SR for all non-prod systems would suffice. If you are (or plan to) use the SR in a much more comprehensive manner (e.g. Dynamic routing at runtime, policy enforcement at runtime or Service Registry Synchronisation with another UDDI compliant non-SAP SR for additional runtime governance requirements), then it would make sense to have an SR in the PI Productive landscape as well.

So there isn't a best practice guide on the subject (or I haven't seen one) because it will vary according to use cases per customer.

Regards, Trevor

[petr_solberg · Accepted solution]

Hi Trevor,

great academic answer thank you.

Ok, to be precise, I am talking about the Services Registry, ServicesRegistrySi which we setup in Customer Proxies in CE.

Currently we have set this configuration up in our Development CE and connected it to the Development PI system.

My question is,

for each layer of the landscape:

Dev CE -> ServicesRegistrySi -> Dev PI

Quality CE -> ServicesRegistrySi ->

Regression CE -> ServicesRegistrySi ->

Production CE -> ServicesRegistrySi -> Production PI

Are you saying for the CE Services Registry config in CE Consumer Proxies ServicesRegistrySi do we have one PI as Services Registry for all Non-Prod Landscape all Non-Prod CE's connect to the same PI for Services Registry and then use Prod PI as the Services Registry for Prod CE ?

Many thanks for your very detailed answer.

Kind regards,

Petr.

[Former Member · Accepted solution]

Hi Petr,

I'm saying I would adopt that route more because of a personal preference than anything else. I haven't come across any SAP (or any other software vendor) best practice guide on the subject.

There's nothing stopping you from having a Service Registry for each environment too & it will look a lot cleaner. It again boils down to user cases per customer I guess.

You should probably solicit more feedback from other forum members on more suggestions.

Regards, Trevor

[petr_solberg · Accepted solution]

Hi Trevor,

in the absence of feedback from others experienced in this area.

If we went for configuring each CE in the landscape to use their respective PI system as Services Registry, will we need to transport anything for Services Registry from PI to PI as we move developments and configurations up through the landscape ?

eg, if we go for:

Dev CE -> ServicesRegistrySi -> Dev PI

Quality CE -> ServicesRegistrySi -> Quality PI

Regression CE -> ServicesRegistrySi -> Regression PI

Prod CE -> ServicesRegistrySi -> Prod PI

If we went for this (which isn't your preferred choice) would we need to transport anything SR related

from PI to PI as we move project developments and configurations up through the landscape ?

[ this thread could become a useful blog ]

Thank you for your feedback.

Petr.

[Former Member · Accepted solution]

Hi Petr,

That's the other issue & a very valid point...I remember having to re-do configuration & SR related content (publishing) as I moved up the environment chain because the content was not transportable...

Regards, Trevor

[petr_solberg · Accepted solution]

Hi Trevor,

thank you.

I think for us, I will setup each CE to use the respective PI SR in the respective layer of the landscape.

Motivation being, that if there are any differences between layers and special configurations or SR publishing to be done, we will experience this in each layer and therefore be 100% prepared when we move to Prod - which is the reason the Customer invests in the different layers of the landscape to ease the movement of changes to Prod.

Question though, if we have CE connected to SR on PI in the respective layer of the landscape, do you foresee the need for SR publishing / transporting from PI layer to PI layer to enable the CE applications to work as they are transported from layer to layer ?

Thank you and kind regards, your insight is much appreciated.

Petr.

[Former Member · Accepted solution]

Hi Petr,

 Question though, if we have CE connected to SR on PI in the respective layer of the landscape, do you foresee the need for SR publishing / transporting from PI layer to PI layer to enable the CE applications to work as they are transported from layer to layer ? 

It all depends on how you're using the SR in the customer environment. For example, if you CE apps are using the SR at runtime for dynamic routing or policy enforcement, then I would foresee the need for it. If the SR is only used at design-time in the CE environment then you won't need to publish first to get the CE apps working. You may however need to do some configuration changes depending on how you're using PI, e.g. If you're routing your service calls from CE through SAP PI to an SAP backend - OR - you may be just using the PI ESR for service modeling & this service interface is then used further in CE.

Regards, Trevor

[petr_solberg · Accepted solution]

Hi Trevor,

thank you very much for all of your insight and answers.

Kind regards,

Petr.