Database Reference
In-Depth Information
5. NWDS Local Build Environment:
a. Start the local build in NWDS.
b. Build new archives.
c. Store archives locally subsequent to a successful build.
6. Deploy the archives for testing into the local J2EE Engine.
7. Check in new versions (stored in activities) into the DTR, subsequent to a successful test.
8. Central Build Environment:
a. Activate the activity.
b. Retrieve new objects from the inactive workspace and prebuilt source files from the
active workspace.
c. Start the build with source files from DTR (i.e., in sync with the global version history)
and archives from CBS, which ascertains that only the latest versions of all objects have
been used in the build.
d. Activate the source files subsequent to a successful build.
9. Change Management Environment:
a. Deploy new activities into test systems.
b. Release activities for the next step in the CMS, subsequent to a successful central test.
c. Import objects into the consolidation system.
d. Assemble subsequent to successful test of the objects.
e. Approve for release subsequent to successful assembly.
10. Repeat the release cycle with the definition of next release in SLD.
11.2.1.2 SAP Component Model
SAP Component Model helps to structure the applications and their architecture. It makes appli-
cations easy to reuse and maintain by breaking them down into components that can be changed
independent of each another. This entails, on one hand, the individual components to be uncou-
pled, and, on the other hand, paradoxically they need to have well-defined interfaces to enable the
essential interaction between components. This is also the basis for the success of the build process
described later.
SAP Component Model structure applications at four levels, namely, product, software com-
ponents, development components, and development objects
. Products
are the solutions in the
business environment and are defined in the Software Landscape Directory (SLD) in terms of the
information on name, owner, constituting software components, etc. Each product is defined in
the Software Landscape Directory.
Software components
(SCs) are group of related functions and are implemented in development
components. General and specific software components are the basis for the reusability demon-
strated by this model. SCs developed specifically for a product can be changed for this product,
whereas general SCs used by the product usually cannot be changed in this context by the product
directly. An SC is a structure of folders and files. All folders are stored in one common folder that
also contains a folder
TopLevelDCs
with all top-level DCs that are not contained in other DCs along
with the corresponding .dcref files. The build result of an SC is a deployable Software Component
Archive (SCA).
Software components
(SCs) are constituted of the development components that are the
basis for the independence demonstrated by this model. Development component (DC) con-
tains and encapsulates the development objects that are actually programmed by the developers;
