Exploring the Development Infrastructure

The software component model combines software components (development components, or DCs) for delivery and deployment into larger units.

The figure, SAP Component Model, Built, shows the build of the SAP component model.

The product version is defined in the SLD. The following parameters apply to the product version:

• Provides business solutions.

• Gets defined by management.

The software component version (SC) is defined in the SLD. The following parameters apply to the software component version:

• Groups DCs without overlapping.
• Gets defined by the team leader or planning team.

In the SLD, products and software components are defined. The product itself belongs to the SLD, whereas the software component belongs to the component model.

Products provide business solutions. New products are decided upon by the management of a software company. Products are created as new items in the Software Landscape Directory (SLD) Software Catalog, with new software components.

Units of delivery and installation as SCA (software component archives) are delivered in the following ways:

• New installations
• Support packages

For group DCs without overlapping, each DC only belongs to one software component at a given moment (the software component may change over time).

Software components can be used in more than one product (typically some basic components will be part of every product). Software components get a release number when shipped. Technically the release of a software component is defined by the state of the DC it contains.

Combining components into a single model does not effect the visibility of the individual components.

A DC can only use another DC from a third party software component when its own software component defines a corresponding dependency.  DCs can restrict their use by Access Control Lists (ACLs) to specific software components.

Therefore, software components can be used for the implementation of software layers.

Software components have globally unique names that are constructed according to the same rules as the names of DCs. The name must be defined when the software component is created and cannot be changed later. Names of software components are usually only a vendor identification and a single segment, for example, sap.com/crm.

Development components are the central element of the SAP component model.

The public part of a development component groups elements that may be used by other development components and packages components of the programming language (for example, Java).

Public parts define the development component interfaces: All objects inside a development component that may be used by other development components. Most development components define one or more public parts (otherwise they can only use other development components, but cannot be used themselves).

The following types of public parts are available:

• A type that provides an API for developing or compiling other development components (compilation)

  This can contain one to all objects of a development component.

• A type that can be packaged into other build results (assembly)

  This can contain one to all objects of a development component, too. However it’s not useful to put everything in a development component into its public parts: The application would lose structure by doing so.

In the example shown in the figure, Development Components, Public Parts, DC1 contains five objects (C1 to C5):

• C1 and C2 are provided for compilation: The build result is the API.jar.

  This is needed in typical interaction between Java classes, where one class uses the other.

• C1 to C5 are all included in the DC1 public part: The build result is an DC1.sda.

  This is needed, for instance, if DC1 is an Java development component, which does not provide a deployable build result by itself.

Objects in public parts can be everything from single class files to package folder trees.

Public part definitions go to the metadata of each development component to be read during the build process: If a class C11 from another development component tries to use an object of DC1, only those in PP API are allowed to be used during compilation (such errors are indicated by the SAP NetWeaver developer Studio even before the build process).

Advanced control option: ACL can further restrict component (PP) usage: If an ACL is defined only those named in it are allowed to use a development component.

Use dependences declare that a development component uses parts of other development components. Objects from other development components can only be used if the following conditions exist:

• The used object is an element of a public part.
• A usage dependency exists.

Violations of these rules are detected during the component build process.

The example shown in the figure, Use Dependencies, illustrates which objects of DC2 can be accessed by other development components and which can not:

• DC2 contains the objects (for example, Java classes) C3, C4, C5, C6, and C7. C3 and C4 are put into the public part of DC2.
• DC1 has declared a use dependency to DC2. DC3 has not declared a use dependency to DC2.

These rules are checked automatically as follows:

1. The developer of DC1 attempts to call C6 of DC2; this fails because C6 is not in the public part of DC2.
2. The developer of DC3 attempts to call C4 of DC2; this fails (even though C4 is in the public part of DC2) because DC3 has no use dependency to DC2.
3. The error that is shown in the SAP NetWeaver Developer Studio disappears as soon as the use dependency is declared.
4. The developer of DC1 attempts to call C3 of DC2: this is allowed because both public part and use dependency rules are fulfilled.

Without the SAP extensions in SAP NWDS, the projects would be built by using different project types, like Eclipse does in the standard delivery. If necessary, these projects would be assigned by using dependencies. These individual projects are connected by dependencies. The Java code is then written and build scripts are created according to the organization of each project. SAP NWDS supports each of these recurring tasks using a standardized project structure supplied by the SAP component model and the given toolset.

Because of this, the internal structure of Java, projects needs to be standardized. These standardized Java components are referred to as development components (DCs).

There are several types of DCs available. For the BPMN model, there is the Process Composer DC.  For Rules Management, there is the Rules Composer DC.  All DC types are supported by prospects and editors. This allows standardized build scripts to be created.

Development components are allocated to software components. Therefore, a .ear archive usually corresponds to a software component that can be installed on a J2EE server.

In the figure, Deployment Components in a Software Component, the right pane displays the individual projects already standardized. The left side of the screen displays the same projects integrated into the SAP development infrastructure as a component of the software development components below SC_BIT800_xx.  As part of the SAP development infrastructure, SAP provides a considerable number of software components.

The figure shows the integration between the different perspectives.

The result of a development, whether local or central, is always an executable application on the J2EE server. The standard J2EE format required for this is called the Enterprise Archive.

Enterprise Archive, or Enterprise Application Archive (EAR) is a term used in Java programming.

In general, an EAR is a file in a *jar, or *.zip format, containing a complete application, according to the Standard Java Platform, Enterprise Edition (Java EE). These files own the extension *.ear.

EAR files allow the delivery of complex business solutions in one file. This format can be processed by any Java-application server, which fulfills the Java-EE standard.

The figure illustrates the built of the "Enterprise Application Archive Format".

The application architecture used has been designed for maximum flexibility and security.

The business layer of the architecture maps the business process and is user-centric. That is, users interact with the business layer/BPMN process using input masks. In certain circumstances, storage of local data is implemented using JavaBeans.