Concept - EDL Modeling

Introduction to Enfinity Definition Language

The Enfinity Definition Language (EDL) is a textual DSL for modeling business objects for Enfinity Suite 6 and Intershop 7. It was developed using the openArchitectureWare Xtext Framework, which creates the complete Eclipse-compliant implementation for the language parser, editor, model classes etc.

Figure 1: EDL Files and EDL Models

An EDL file is a text file in the EDL syntax.

The syntax for each language element is described using railroad diagrams. See for more information.

The EDL file can be parsed by the EDL parser, which instantiates an EDL Model. The EDL Model represents an instance of the EDL Grammar, which defines the language constructs. The EDL models are based on the Eclipse Modeling Framework. After parsing, an EDL model can be subject to further processing, e.g., model validation, model transformation or code generation.
The parser creates a separate EDL Model for each EDL file. Dependencies between files (e.g., relationships such as inheritance from a superclass) are resolved by a linker after parsing.

Language Modules

EDL consists of a core language, which is extended by multiple sub-domain languages. The core language provides common concepts like namespaces, primitive types etc that are shared by all sub-languages, while the sub-languages provide additional language features for expressing a certain ES6/IS7 subsystem. For example, the ORM sublanguage provides means to model ES6/IS7 ORM classes with EDL. The sublanguages rely on the core type system and they can depend on each other.

Figure 2: EDL Language Structure

EDL Files

EDL models are stored in text files with the ending .edl. They can be edited with a simple text editor or with a specialized EDL text editor in Intershop Studio that provides additional features such as syntax highlighting, code completion etc.
An EDL file typically consists of:

  • Imports for other EDL files that contain referenced types
  • Primitive type declarations
  • External type declarations
  • Namespace declarations
  • Complex type declarations

Typically, each complex type (such as an ORM class) is defined in its own EDL file, which should have the same name as the contained type (similar to Java conventions). However, this is not a restriction of the language but a design recommendation. Basically, an EDL file can have any name and it would be possible to define all types of an ES6/IS7 system in a single EDL file.


EDL is a modeling language, not a programming language. Therefore, it only consists of declarations, but does not define how they are actually implemented. EDL is intended to be used in conjunction with a code generator that can create the implementation code from the EDL declarations.

Intershop Studio Integration

EDL files can be created and edited with Intershop Studio. There are special text editors, outline views etc. EDL supports the JGen code generator.

Code Generator Integration

The EDL files are supposed to serve as input for a code generator, like the ES6/IS7 code generator JGen, which creates the Java implementation for the artifacts that are described in the EDL files. JGen provides a generic API against which the existing code templates were developed. Intershop Studio comes with multiple different code generators. Which generator must be used depends on the chosen target platform. For older ES6/IS7 versions prior 6.5, an adapter implementation of the JGen-API exists which adapts it to the underlying EDL-EMF-API. With this, the existing code generation infrastructure can be reused with EDL. For newer ES6/IS7 versions, starting with 6.5, the code generator templates have been migrated to openArchitectureWare, so the old JGen templates are not needed anymore.

Regardless of the underlying implementation, the code generator can be started from the context menu. This operation is now available on EDL file selections, too. When selected, the EDL parser loads and parses the EDL file, creates the EDL adapter for the model and invokes the code generator on it, which is configured in the project preferences. The code generator traverses the model and generates the content according to the generation templates.

Figure 3: Classic EDL JGen Integration

Migration of UML Models

Currently, UML models serve as input models for the code generator. In the future, we do not want to use UML anymore because it comes with problems regarding the versioning and branching of models and only rely on EDL models instead. Therefore, a migration tool has been implemented which can convert the existing UML models into EDL files.

Figure 4: UML Model Migration

The migration consists of a model-to-model-transformation, which transforms an UML model into an EDL model. After that the EDL model is written into an EDL file using an EDL code formatter. The EDL file is a well-formed and "beautified" text file which basically can contain the same information that are contained in the UML models today.
The migration tool is implemented as an exporter, e.g., in Intershop Studio, select "Export..." on an UML model file to open the migration wizard.

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to if you experience login issues,
or if you want to register as customer.