BO Server Architecture

[Former Member]

Hi everybody.

I've got a question about the recommended architecture of the BO Installation.

In SAP exists in most of the cases a development system, a test system and a productive system.

But what about Business Objects?

Does there exist a guidance for this?

Is it recommended to built up a testsystem and a productive system, as well?

Just to make myself clear. I don't want to know how to relocate the BO services on different server.

Thats explained in the manuals very detailed.

Maybe an other technique is used to ensure the system. A version control, e.g.

I just don't know.

An hints or explanations would be nice.

Imagine I would be a customer with maybe 4000 people working with the BO frontend tools or viewing reports with it.

Thanks in advance.

Sebastian

[Former Member · Accepted solution]

I don't recall if BO has any documentation on this.

The principles of content promotion are essentially the same.

Note that the following may not be entirely relevant to your specific requirement. You could use this as a set of (rather) broad guidelines.

You would ideally have a Dev, QA, UAT and Production.

Dev: The development environment contains a full stack on one server. This is used only by report developers and universe designers and Administrators.. This is the only environment where changes should be allowed. Also, content must be created only on this server. End users should not have access to this server.

Note that folder and group structure should ideally be the same across all environments.

QA: The QA environment architecture is similar to that of dev (single server). The QA environment can only have content promoted from Dev. In QA, all content is tested. If changes are required, they are made in Dev and re-promoted to QA. Content is not changed in QA. Content in QA that is deemed satisfactory is promoted to UAT.

UAT (User Acceptance Testing): All content in UAT is ready for testing by end users. UAT data sources are similar/close to Production data sources. Dev/QA data sources are more limited. In QA, reports, universes, object packages etc are checked for errors. In UAT, the data in the reports is checked for errors. Also, UAT architecture is more robust that the Dev/QA architecture. Content is promoted from UAT to Production. ontent that does not pass the UAT process has to go back to Development.

Production: The Production environment contains data promoted from UAT and is accessed by end users. No testing takes place in production and only content that has been validated and has passed UAT is allowed in production.

Like I said before, this is subjective. Not everyone requires all four environments. Smaller deployments could do away with separate QA and UAT environments or even merge Dev, QA and UAT, separate them on the same server via access restrictions etc.