Database Reference
In-Depth Information
In the DTR, while authentication determines only the access to a DTR, authorization deter-
mines further if that DTR can be changed by an authenticated developer.
In summation, DTR addresses the following tasks:
◾
Ensures availability of all versions of files.
◾
Restricts access to only those objects required by the project.
◾
Maintains versioning information even after they have been transported to other instances
of DTR at other development locations or at customer locations.
11.2.1.2.2 Component Build Service (CBS)
Component Build Service (CBS), which is the central build environment of the SAP JDI, is also a
database-supported J2EE application based on the SAP component model. CBS saves Java archives
(runtime objects) and builds packages based on relevant information available in the DTR; it creates
a
buildspace
for each software component. For each configuration, CBS maintains the build environ-
ment (libraries, generators, and build scripts) and corresponding results in a central archive pool in
the CBS that ensures that only the latest version will be used by all concerned. The centralized stor-
age in DTR makes centralized build processes possible. Older versions are not overwritten; rather
a global version history is created. For the communication, the HTTP is used. CBS build process
is based on the SAP Component Model with development components (DCs) as the build units;
during the build, all dependent DCs are checked. Cyclic dependencies are detected and disallowed.
Buildspace
is the logical storage locations used to access the archives and serves as logical build
servers. Every product release creates one development and consolidation state, both of which are
represented by one buildspace. As mentioned earlier, for every buildspace, there is a pair of DTR
workspaces in the DTR, namely, inactive and active workspaces that are closely connected with
the build process in the CBS. New objects are always created in the inactive workspace; after these
objects within an activity have been built successfully, the source files are automatically integrated
into the active DTR workspace. Using source files exclusively from this workspace ensures that
the state is consistent with the latest version of the entire software. This achieves synchronization
of all development efforts encompassing both the source and archive files.
11.2.1.2.3 System Landscape Directory (SLD)
System Landscape Directory (SLD) stores information on the system landscape and the System
Catalog, which contains the list of all products and software components available. Each product
release of a product is defined separately in the SLD; different products can share SCs. The devel-
opment environment is created for a product based on the information in the SLD.
11.2.1.2.4 Software Logistics
Software Logistics (SL) enables handling of tasks like application deployment, corrections, and
hand-off to the customer or maintenance. SL component consists primarily of two components:
Change Management Service (CMS) and Software Delivery Manager (SDM).
CMS manages the software versioning and the transportation of the software changes within
the development landscape. SDM is responsible for the deployment of the Java applications.
All requisite descriptions of the system landscape are maintained centrally in the SAP System
Landscape Directory (SLD).
