Database Reference
In-Depth Information
these include the Java classes and interfaces, image files for icons, or SAP-specific metadata or
Web Dynpro files. All development components can be stored as versioned resources in DTR (see
Section 11.2.1.2.1 “Design Time Repository (DTR)”). DCs can be nested, that is, one DC can
contain other DCs, just as software components can also be nested. But, for a product, a develop-
ment object can occur only within one development component, just as a development component
can occur only within one software component. DCs are containers for the corresponding devel-
opment objects, which are invisible outside of this DC. This achieves perfect decoupling of the all
DCs; however, to enable DCs to use one another, they define interfaces called
public
parts that
publish the development objects termed as
public part entities
that can be accessed and used by the
other DCs. There are two types of public parts: compilation types can be used for the development
of other DCs and are used accordingly during a compilation, and assembly types provide a build
result that can be wrapped by other DCs. The later types are required when DC type does not
produce a deployable build result, like in the case of Java DC mentioned in the following; part of
such a DC is wrapped in an assembly-type public part to be uploaded to the server in the form of
(say) a J2EE Java library file.
SAP Component Model supports the important concept of
use dependency
between DCs,
whereby for using development objects of another DC, their usage has to be declared in the meta-
data of the concerned DC and must also be included in its public parts. The new build process in
the CBS checks this information on dependencies to enable build of individual DCs. Thus, the use
of external DCs is limited by the attachment to the SC and nesting of DCs. Access Control Lists
(ACLs) explicitly list the DCs that are enabled unrestricted but exclusive access to a particular
DC. ACLs consist of Access Control Entities (ACEs) that assign one or more privileges to a user
or a group. Cyclic dependencies are detected and disallowed.
The DC type controls the build process required to create the corresponding DC structure
along with the relevant settings. The various DCs are listed as follows:
1. Composite Application Service DC contains all of the corresponding elements required,
namely, Dictionary objects, metadata, and Java classes. Each Composite Application Service
DC is associated with Dictionary, Metadata, EJB Module, and enterprise projects. Build
outcome is a combination of Software Deployment Archive (SDA) and Enterprise Archive
(EAR) files.
2. Dictionary DCs define the global structures. Build outcome is an SDA file.
3. J2EE DCs correspond to various DCs like the following:
a. Java Enterprise Application DC, which is a combination of Web Module DCs and EJB
Module DCs. Build outcome is an EAR file.
b. EJB Module DC contains the Message-Driven Bean, Container-Managed Persistence
(CMP) Bean, Bean-Managed Persistence (BMP) Bean, Stateful Session Bean, and
Stateless Session Bean for an Enterprise Application DC. The build outcome is a set of
compiled classes.
c. Web Module DC contains JSPs, Servlets, and Proxy classes for beans defined in an EJB
project. The build outcome is a Web Archive file.
d. J2EE Server Component Library DC is an add-on for the SAP's J2EE Engine; the build
outcome is an SDA file.
e. Java DC contains Java code. The build outcome is a JAR file.
f. Web Dynpro DC: The build outcome is an EAR file containing a Web Dynpro Archive
(WDA) file.
