Content Server technical design:

The following design represents the structure of the content server systems.
The BASIS team will perform all setup (mapping of Business Objects to repositories.
This is done in OAC2 and OAC3.) for the content server systems. There may be some
functional configuration required. This will be performed by the functional team.
The content server landscape will follow SEu’s traditional development (CSD), QA
(CSQ) and production (CSP).

Each Content Server system may be attached to multiple “target” systems.

The target systems may have the same logical system name.

Each content server system will be segmented to represent each of the SAP modules.
Even modules not currently being used by SEu will have a segment to facilitate future
use.
Similar modules in the target systems will point to the same segment in the attached
content server. I.E. The PM attachments from NW7 and the PM attachments from DEV
will both point to the PM segment in CSD.

Refresh co-ordinations:
A refresh of CSP to CSQ MUST occur at the same time as a refresh from PRD to QAS to
ensure all of the attachment connections are retained.

If a system, such as NW9, is not refreshed at the same time then any attempt to “call” old
attachments will fail as there is no link. Any new attachments created in NW9 will be
retained.

Once a refresh occurs the key will have PRD in it. The NW9 and QAS systems are both
refreshes of PRD. Therefore they both will point to the same business documents. If
NW9 deletes an attachment then the document will be deleted for QAS as well. This will
not be the case for new data/attachments only refreshed data.

Other notes:
All “attachments” must be “stored as business documents” for Content server to accept
them. Regular “attachments” will reside on the SAP database. A decision will need to be
made if we can/want to lock down the regular attachments.