Introduction

Intershop 7 provides two kinds of adaptability of standard applications:

• Customization: existing code artifacts should be replaced, because other requirements should be met. This can be done by defining your own application types (Concept - Application Framework) with another set of cartridges that override existing code artifacts of provided standard cartridges.
• Extension: existing code artifacts explicitly define extension points where code artifacts of other cartridges are plugged in. Depending on the type of the extension point these code artifacts are called when the code artifact defining the extension point is executed:

The same extension point may call a different list of extensions depending on the execution context (cartridge list of executed application type). Hence, particular extensions can be reused in different application types.

The extension engine is responsible to load the extension model files (suffix " .extension"), that are responsible to register the particular code artifacts at the defined extension points. Such a file contains an extension model with a name, which binds one or more extensions of different types to the particular extension points. The integer value in the extension bindings is used to sort the overall extension list:

Related Documents

• Concept - Application Framework (valid to 7.9)
• Cookbook - Extension Points and Cookbook - Extension Points

Glossary

Extension Point Types

The following sub-chapters explain the existing extension types in more detail.

Pipeline Extension Points and Extensions

General

Extension point nodes are used to define extension points within pipelines. The node requires the extension point identifier, which needs to be unique within the pipeline. Further, (since Intershop 7.3), it is possible to define the parameters and return values that are delivered to and returned from the extension pipelines. An extension pipeline is of type "extension" and needs to be finished with an end node. Interaction nodes are not supported and do not make sense. If the name of end node is empty or is "next" or has any other name than "error" (case insensitive), then the extension point continues calling other extension pipelines. Error end nodes interrupt the execution of the extension point node. Thus, the extension point node has two out connectors, one is the error connector and one "next" connector.

The extension model files reference an extension point within a pipeline by using the pipeline name and the extension point identifier (e.g. "ProcessProduct-ProductUpdated").

The process of creating pipeline extension points and extension pipelines is explained in the corresponding cookbook .

Error Handling

Usage of the error connector

Here is an example of using the error connector:
Assuming a business object creation is extensible by providing an appropriate pipeline extension point. If one of the extension pipeline calls ends with an error end node, the business object creation basically failed. Using the error connector of the extension point node the pipeline developer has the ability to produce an appropriate business error message. Additionally, controlling a transaction is easier - it can begin before the extension point node; the commit will be placed somewhere in the branch of the next connector and the rollback is performed in the branch of the error connector.

Exception handling

If an exception is thrown within the execution of the extension pipeline, this exception is handled as in any other pipeline:

• If there is no pipeline branch with an error start node in the extension pipeline, the exception handling is delegated to the caller pipeline (which contains the extension point node).
• If there is a pipeline branch with an error start node in the extension pipeline:
  • If this branch ends with an error end node, the extension point node of the caller pipeline stops the execution and exits to the error connector.
  • If this branch ends with another end node, the extension point continues processing subsequent extensions.

ISML Template Extension Points and Extensions

ISML templates define extension points by using the isinclude tag with the attribute extensionpoint, e.g.:

<ul>
<isinclude extensionpoint="Tabs">
</ul>

The ISML template processor includes every ISML template which is registered in current execution contexts to this extension point. The extension model files reference an extension point in an ISML template via template name and extension point identifier (e.g. "product/TabBar-Tabs");

The process of creating ISML template extension points and appropriate template extensions is explained in the corresponding cookbook .

Java Extension Points and Extensions

Java class extension points provide the ability to plug custom code snippets into an existing functionality written in Java. To define an extension point, the method in Java which processes the extensions must be annotated appropriately.

The process of creating Java extension points and extensions which plug into this extension point is explained in the corresponding cookbook .

Defining New Extension Types

It is possible to create new extension point types for other artifacts existing in Enfinity or developed later. To understand how a new extension point type is added, some knowledge about the extension API is required.

The diagram shows two packages:

• the cartridge pf_extension and
• the cartridge pipeline.

The cartridge pipeline is just part of the diagram to show how the integration of a "real" extension works. The cartridge pf_extension basically defines the infrastructure to work with extensions: an engine, a context and an extension point type.

• The extension engine is responsible to register extension point types and look up extensions. The extension engine uses the capabilities of the EMF engine to perform the registration and lookup of extensions. Extension point types must be registered explicitly at the engine.

• The context must be provided to look up extensions. The context provides a list of extension set IDs, which are basically cartridge names, sorted according to the lookup order.

• The class ExtensionPointType is used to declare an extension point type. Extension point types are registered at the extension engine. One extension point type instance corresponds to the type attribute used in extension point bindings created in Intershop Studio. A new extension point type must be introduced by implementing the corresponding extension point type class and register it at the extension engine. The extension engine can look up extensions of registered extension point types only. The extension point type is also responsible to create an extension instance of a given class. When the extension engine determines all extensions of a given extension point, it invokes the corresponding method to create the extension instances. For that purpose, the implementation of an extension point type instance is parametrized with the extension interface class.

• The class diagram contains the classes of the pipeline extension to illustrate an implementation case. The interface PipelineExtension obviously defines methods to get a pipeline name and a start node name. The PipelineExtensionPoint creates an instance of PipelineExtension; that is why this class is parametrized accordingly. The instance implementing the interface PipelineExtension is created by the pipeline extension point type when requested.

An example of the implementation of a custom extension point type is given in the cookbook .