Development environments and interfaces

Multi-system landscape

Concept

There are several system types. Typically, there are 3 systems, but sometimes 2 or 4 are possible:

• Development system (DEV): This is where new applications are developed, changes are made, and testing is performed.
• Quality assurance system (QAS): Used to test developments and changes under real conditions before they are transferred to the production system.
• Production system (PRD): The live system in which the company's daily business processes are executed.

For very small customers, the QAS system is sometimes replaced by another client on the DEV system.

For large installations, there is sometimes another system on which the consistency of transports can be tested before importing them into PRD.

Transports

Concept

• So-called transports bundle changes
• The transports consist of an object list
• When development objects are changed, automatic change recording takes place. The developer can select a suitable transport request.
• As soon as a development object is included in a transport in the object list, it is locked for other transports
• Once all changes for a transport have been made, it can be released.
• The following happens when a transport is released:
• The transport files are generated from the objects' active status at that point in time
• The objects are unlocked again, meaning they can end up in another transport
• If necessary, the import into a subsequent system is triggered

Client concept

Challenge

One system for multiple business units in ERP

• Data isolation
• Sharing of resources
• Clear separation of permissions and users
• Low administrative effort
• Flexibly scalable and expandable to include additional business units

Authorizations (roles & authorization objects)

The authorization and role concept in an SAP system is central to security and the efficient management of access rights.

1. Authorization objects: Consist of an activity and fields.

2. Authorizations: Concrete manifestations of authorization objects. They define which activity a user is allowed to perform on a specific object.

3. Roles: Collections of authorizations that are grouped together to enable specific work tasks. Roles simplify the management of authorizations.

4. Simple roles: Contain authorizations for a specific area or process. They are geared toward specific tasks or functions.

5. Collective roles: Bundle several simple roles. They are used to cover more complex areas of responsibility.

6. User assignment: Users are granted access to system functions by assigning roles to them.

Namespaces

Z and Y namespace

Customers may create development objects that begin with Z and Y. You are responsible for ensuring that there are no name collisions within your own company.

Prefix namespaces /ABC/

Partners and some SAP modules/components use a so-called partner namespace. This consists of a 3-5 digit abbreviation between two slashes. All development objects must begin with this.

Namespaces are assigned by SAP.

SAP namespace

SAP uses everything else for its own developments.

Packages and local objects

All development objects are located in a package (aka. development class). The package is primarily a classification criterion.
The package

• can be local or define a transport channel
• is not a namespace
• can be changed later

The package $TMP is always local. Here, the objects are assigned to the respective user.

Saving and activating

The definitions of development objects in SAP are stored in a repository in database tables. Only when they are activated are runtime objects generated from them. This means that there may be two versions of an object:

• the active version - corresponds to the runtime object, and
• the modified version - contains all changes that may have been made but have not yet been activated.