This document describes the technical architecture of Intershop 7. It provides a high-level overview about the most important terms, concepts and practices. For more details about a certain topic, refer to the design specifications, concept documents or cookbooks.
An Intershop 7 system is never used stand-alone and self-sufficient. Instead, it is always integrated into a bigger e-commerce landscape. The exact architecture of this landscape is customer-specific, but typically, the IS7 system is integrated with dozens to hundreds of external systems. Such systems include:
The possibilities are endless.
How IS7 is integrated, which subprocesses of the overall e-commerce process are to be covered by IS7, and which processes are provided by external systems depends on the business model and the existing IT and service environment of the customer.
In addition to the integration with external systems, multiple IS7 systems are often integrated with each other. Typically, larger installations consist of:
For increasing availability and performance, large customers often operate multiple IS7 instances in different data centers that are geographically distributed. There are several ways how IS7 can operate in such scenarios:
IS7 comes with a 3-tier architecture, which consists of:
Here the term tier refers to the physical distribution of the software installation. Typically, each tier is deployed on a separate server machine for a production environment. For development and test installations, all tiers of IS7 can also be deployed on a single machine.
The web tier consists of the web servers (Apache) with the additional IS7 web adapter. In an IS7 cluster, there are usually multiple web servers (1..100) that get their load from a hardware load-balancer in front of them. The web adapter, which is plugged into the Apache web server, has multiple tasks:
The web adapter comes with a separate web adapter agent that is responsible for background maintenance tasks:
The application tier consists of the IS7 application servers. In a production cluster, there are usually multiple application servers (1..several hundreds) for performance and availability reasons.
An application server is a J2EE servlet container (Apache Tomcat) that hosts multiple J2EE applications. The main application is represented by the IS7 application, which receives the load from the web adapter and performs the business functions.
Each application server process is controlled by a so-called node manager. The node manager is another process that is able to start or shutdown an associated application server. It can also automatically restart an application server in case of failure, i.e., it acts like a watchdog process. The node managers in a cluster can be controlled using the JMX protocol. The Tomcat Cluster Management Console (TCC) provides a web user interface for doing so. It also runs within the application server process as a separate J2EE application.
An application server can be assigned to a server group. The server group is an identifier that is used by the web adapter for adjusting the load balancing. For every request, the server group is determined that should handle the request, and the requests are only forwarded to application servers that belong to such a group. Using server groups, it is possible to route traffic to dedicated application servers (like for separating storefront traffic and Commerce-Management-related traffic), or to run application servers for doing background operations that would not get any web traffic at all.
For historic reasons, the IS7 web application comes with its own embedded servlet engine. This means, the "outer" Tomcat process that hosts the IS7 web application does not actually get any load. Instead, all requests are handled by this "inner" servlet engine, which also opens its own HTTP ports.
The data tier consists of the database and a shared file system (a central network drive), which is accessed by all application servers. The database is used for storing all mass data and all transactional data, like product information, customer accounts, their orders etc. The shared file system holds static files that are needed by the business applications, like product images, style sheets, PDF documents, configuration files and so on.
As a database, currently Oracle is supported.
The group of the several instances of web servers, application servers and database servers that are working together is called a cluster. A minimum IS7 cluster would consist of a single web server with the web adapter, a single application server with the IS7 application, a shared file system and an Oracle database.
Each cluster has a unique identifier in order to distinguish it from other clusters.
The web adapters that forward dynamic requests to the application servers must know about the structure of the cluster. To this end, they are configured with a list of so-called configuration services that are provided by each application server and that they poll at a regular base. The several application servers communicate with each other using an event channel that is based on multicast events. Each server regularly sends an event about its presence (like their ID, their IP addresses, their ports etc.) and its operational state as a broadcast message to the local network, which is received by the other application servers. Consequently, every application servers knows about the others and can provide this information to the web adapters.
IS7 application servers are subject to licensing. With the current license model, the number of application server CPUs in a cluster can be limited. If the active CPU count exceeds the limit, an additional application server cannot participate in the cluster anymore, i.e., its registration attempts will be declined and it therefore will not get any load. However, if another active application server is removed from the cluster (like by shutting it down), the active CPU count may fall below the limit, so the application server that is waiting would jump in, like in a hot stand-by mode.
The structure of an IS7 application server can be visualized as a set of architectural layers and cross-cutting concerns. A layer here describes the logical view on the application, in contrast to tiers, which describe the physical (deployment) view.
Every layer is supported by numerous frameworks that can be used to implement the functionality of the layer. The picture below shows which frameworks and concepts can be used for the several layers.
An IS7 application server forms a runtime environment for cartridges. Cartridges are deployment containers for all kinds of elements that exist in an IS7 system, like Java jar files, pipelines, ISML templates, web services, query files, images, XML files, and so on. A cartridge has a well-defined structure in the file system. At runtime, it is represented by an instance of a cartridge class, which can have initialization hooks that are called during server startup.
A cartridge has a version number and a build number. It defines dependencies to other cartridges that are needed during the build/deployment process and/or at runtime. The version number indicates the API stability contract, i.e., it consists of a major version, a minor version and a patch version number. However, this API stability contract is currently not fully supported, so it cannot be guaranteed that a version 7.4.0 is compatible to a version 7.3.0, for example.
The cartridges that must be loaded by an application server are specified in the cartridge list. This list defines which cartridges should be initialized, and it also defines a loading order. The cartridge order is important for the fallback lookup of many IS7 elements like pipelines or ISML templates, which can be overridden in customer projects. When a cartridge is loaded, its cartridge class is instantiated and its initialization hooks are called. Any necessary registration/initialization steps can be triggered in such hook methods.
Cartridges can be associated with an architectural layer to which they belong. The layer is expressed in the naming of the cartridges by a prefix. There are strict conventions which prefixes can be used. Depending on the layer, different elements are allowed as contents of the cartridge. Examples:
Cartridges may depend on each other. All dependencies must be declared. There are strict conventions about which dependencies are allowed. For example, a business cartridge may depend on a platform cartridge, but a platform cartridge must not depend on a business cartridge.
IS7 comes with a so-called component framework that allows to initialize a graph of Java objects that represent the running application types. The component files are XML files with instructions that define which Java classes must be instantiated and how the members of the instances must be initialized/connected with each other. Component files allow to hide the internal implementations. In contrast to existing IOC frameworks like Spring or Guice, instances that are created by the component framework can be application-specific, i.e., different wirings can be achieved per application type.
In addition to the instantiation of Java objects in component files, dependency injection with standard JSR 330 annotations can be used in IS7 at certain objects, such as managers, business objects and pipelets. For injections, the Google Guice framework is used. So-called object graph files configure which Guice modules must be used for an application server.
IS7 comes with several standard implementations for business features that often must be enhanced in customer projects. To this end, there are extension points at several points in the processing logic, into which extensions can be plugged in. Extension points can be provided in pipelines, templates or in Java code. The kind of extension that is to be plugged into an existing extension point is defined in an extension binding file, which is an XML file. The visibility of extensions is application-specific. For example, it is possible to apply an extension to a standard pipeline within one application, but not in another application that executes the same pipeline.
IS7 supports Oracle as a database for all business objects and transactional data. An application server is connected to a single Oracle account that contains all data for all IS7 applications running on that server.
For higher performance and better data integrity, several database features are used:
All requests to the database go through the ORM engine or through the Query engine via JDBC.
The ORM engine is responsible for the object-relational mapping of persistent Java objects to relational database tables. The ORM engine forms an object cache that communicates with the database via JDBC. It is written in pure Java. It consists of multiple sub-systems that perform tasks like loading and parsing deployment descriptors, providing meta-information about persistent objects, generating and executing SQL statements or switching between different transactional and non-transactional states of an object.
An ORM bean (i.e., a persistent object) consists of 4 files:
The code for persistent objects that are managed by the ORM engine can be generated from EDL models using the Enfinity Studio code generator. EDL (Enfinity Definition Language) is a textual DSL for modeling persistent objects.
The ORM factories allow to do SQL queries on persistent objects, but sometimes it is necessary to query the database for other information that do not belong to a persistent object. Such queries can be expressed in Query files. IS7 query files are XML files with control elements that allow to dynamically construct SQL queries and to execute them in the database. The response from the database can be mapped to various Java objects, like primitives or ORM objects.
Again, query files are application-specific and are subject to the cartridge fallback lookup. They can be overridden for customization.
IS7 is always integrated into a bigger environment with other various systems from which business data originate or which consume business data. To support this, IS7 provides import and export capabilities for several business objects. Depending on the kind of object, the import/export feature is capable of handling mass data and long-running asynchronous and/or parallel import processes. Usually, XML files are used as a transfer format, but other formats like CSV or custom formats are common, too. When objects are imported, they can be checked for consistency with validators. The import of persistent objects is mostly done through the ORM engine, though other solutions like JDBC import or Oracle SQLLoader import can be used, too.
Export of data relies on XML frameworks like JAXB, or in some cases on ISML templates for formatting the text.
Data replication is used in IS7 installations with separate instances for edit and live systems. An edit system is used by business operators to create/prepare content like product and catalog information, web content etc. The live system is hosting the active web shop application and is holding the active content that must be shown to the customers, while the edit system is holding the "future" data and has less traffic to handle (only operators). With data replication, it is possible to transfer the database content from the edit system to the live system when it has been completed, tested and approved. Data replication is able to synchronize groups of persistent objects that belong together at once (so-called replication groups), or to synchronize single objects. Switching from old content to new content in the live system can be done in an atomic step by importing the content into a shadow table first and by renaming synonyms in the database second.
With the channel concept, IS7 can model large enterprises and their organizational structures and responsibilities for managing business content. Often, the same data (like product data) must be "rolled out" to different sales channels and applications, while still managing them at a central place. For example, a large company may chose to manage their product and catalog portfolio at the global headquarter, but all sales activity and order processing is done locally in several countries/regions. The distribution of such centrally managed content can be controlled with the sharing concept.
Syndication is also about reusing centrally managed data in sub-divisions, but instead of linking to shared objects this is achieved by creating copies. Consequently, it is easier to perform local adjustments (like changing single attributes) of business objects and to support complex data distribution scenarios. But as a tradeoff, the amount of data in the database is much higher and the import performance is degraded.
Several business objects like products and content of the WCM must be searchable in the storefront or Commerce Management applications. To this end, external search services can be employed. IS7 comes with Apache Solr as an integrated search engine for full-text searches, other engines like FactFinder can be supported if there is a business demand.
The index for searchable objects can be built after import/replication processes. It can also be updated on changes of single objects in the Commerce Management application.
The business object layer provides an explicit business-oriented domain model as a Java API. The business objects usually form an abstraction over an underlying persistence layer (or data layer), which in IS7 is provided by the ORM objects. The business object API is accessed from the various business applications in IS7, like web shop or management applications. The business objects provide for an object-oriented view on the data that is optimized for representing domain concepts and for "programming usability", while the underlying persistence model is optimized for the database mapping and storage/query performance. The business object layer comes with concepts to change and extend the behavior of business objects without breaking the API. The business object API hides the underlying internal implementation that can still be based on the existing ORM model or on any other back end. There may be multiple implementations of the same business object API, each accessing and holding the data in another back end.
The business object concepts defines various types of objects:
The business object API is visible globally, but the extensions can be made application-specific. This means, they would only be visible for certain applications.
Pipelines are executable flowchart models that are used to implement the IS7 business functionality. They can be edited using the Visual Pipeline Manager, which is part of the Intershop Studio IDE. For execution, the pipelines are loaded by the application servers first and are interpreted for every request.
A pipeline consists of nodes and transitions. Nodes can be control nodes, like decision nodes, start nodes, end nodes, call nodes, or pipelets. Transitions are the links between two nodes and represent the execution flow. Pipelets are small Java classes that form small processing steps. They usually operate on business objects and their repositories or on other underlying Java APIs. Pipelets are written for maximum reusability in different business scenarios. Consequently, they can be arranged to different flows in other business applications. Data exchange in pipelines is done using a pipeline dictionary. All input parameters of the pipeline calls are put into the dictionary, from which pipelets or other nodes read their input values and into which they put their output values. Dictionary objects can also be accessed with Object Path expressions, in order to map them as input parameter for a node.
In IS7, two major types of pipelines are distinguished:
Beside these major types, there are a number of other areas in web applications where pipelines are used:
IS7 pipelines can also control the database transactions. To this end, a pipelet can declare that it is transactional, i.e., that it will change data in the database. Transaction boundaries can be adjusted at the pipeline transitions. Their transactions can be started, committed or rolled back. All changes of the pipelets that are executed within such a transaction frame will be atomic.
The term application has already been used several times in this document, so it is necessary to clarify what it actually means. Applications in IS7 are instances of application types and represent the binding of the application type to the data. An application type combines implementation elements (like Java code, pipelines, templates, ...) to meaningful bundles. As an example, there may be an application type B2C Web Shop, which consists of all code elements that make up a web shop. This application type can be instantiated multiple times (that is, there can be multiple applications of the type B2C Web Shop), with each web shop application operating on a different set of products or other content, and with separate or shared customer and order data.
Application types consist of cartridges, which are a subset of the global cartridge list in the application server.
Business objects like products and customer data are stored in repositories, which are assigned to applications. In IS7, there are two kinds of repositories: master repositories and channel repositories. A master repository belongs to a parent organization, while channel repositories represent sub-divisions that run their own sales applications (like web shops). Between master repositories and channel repositories, there may be sharing or syndication relations for distributing and reusing the data among them. Typically, the exact layout of the repository structure and the way of the data flow is different for each customer project.
The Intershop Markup Language (ISML) is a template language that can be used to render dynamic HTML pages. The syntax is similar to XML, but it does not represent strict XML. The language consists of ISML tags and Object Path expressions. ISML tags implement general functions like loops, includes, formatting etc., while Object Path expressions are uses to retrieve dynamic values from business objects. ISML also comes with some ISML functions that can be used for frequently needed tasks like string concatenation, comparison of values etc.
<isloop iterator="Category:Products" alias="p"> <isif condition="#p:Online#"> <isprint value="#p:SKU#"> </isif> </isloop>
ISML is based on JSP. Before execution, an ISML template is compiled into a JSP template, which again is compiled into an executable form by the JSP compiler of the JSP container. Since the ISML grammar defines the available tags, it is not possible to add own custom tags. However, it is possible to use JSP taglibs within ISML templates. With taglibs, the system can be enhanced with additional tags and functions. However, ISML uses different variable scopes and spaces than JSP/JSP expressions, so mixing the ISML world with the JSP world is not straightforward.
ISML templates are contained in cartridges and are executed in the scope of an IS7 application. When a template is looked up, a fallback approach is used: all cartridges that are assigned to the application are checked in the reverse order of the cartridge list whether they contain the wanted template. Consequently, it is possible to override existing templates of other cartridges for customization.
For translating static texts within templates to other languages, there are two approaches:
In special cases, ISML templates may not only be used for rendering HTML responses, but also for exporting files and for rendering e-mails.
The Object Path expression language is an expression language for navigation on Java objects and for accessing their properties. Originally, it was implemented as part of ISML, but later other uses were introduced. Object Path expressions can be used in ISML tags for resolving their parameters, in pipelines for mapping pipeline dictionary values to pipelet input parameters, and in query files for mapping query parameters.
The Web Form Framework allows to define forms for web pages. A web form consists of various input fields and validation rules to check if the input is valid. The web form definitions are stored in XML files and are subject to the application-specific cartridge fallback lookup.
IS7 comes with a complex web content management system (WCM), which allows to design and assemble dynamic web pages at runtime by the business user. Pages are composed from pagelets, which are the basic building blocks and can be developed in Intershop Studio. Pages can be arranged in a kind of "inheritance" hierarchy in order to reuse existing layouts and looks. "Super pages" can have multiple page variants that contain so-called slots, which are to be filled with components that hold the actual content. As the content model must be changeable at runtime, it is stored in the database. The several pagelets can invoke pipelines for determining their content data for rendering, and they are rendered using ISML templates. WCM pages can be displayed as the result of a view pipeline.
In IS7, the whole web shop storefront application is built using the WCM technology.
Of course, e-commerce shops are designed for humans. Apart from the user experience , Search Engin Optimization (SEO) is tremendously important for the business success of a web shop storefront. This is precisely why IS7 supports various techniques of search engine optimization , e.g., XML sitemaps or URL re-writing.
IS7 comes with the Apache Axis framework for implementing web services based on the SOAP protocol. There is a direct integration of pipelines and the web service engine, i.e., pipelines can directly be published as web service. Existing web services can be described using WSDL. In Axis, a request chain and a response chain can be defined with additional handlers that must be executed. This mechanism is used for performing authentication and authorization for web services.
Like ISML templates, IS7 web services are executed in the context of an IS7 application and are subject to the cartridge fallback approach. It is possible to override existing web services with custom implementations and to restrict available web services to dedicated applications only.
As an alternative to SOAP, providing remote APIs as RESTful web services has become popular recently. IS7 supports the Jersey framework for implementing REST services. The behavior of such services can be adjusted using Java annotations on the service classes. It is possible to invoke a pipeline from within a service implementation, or to implement the functionality directly in Java. Authentication and authorization is done using Jersey means.
For the integration of external services like payment services, personalization services, mail services etc. into IS7, the managed service framework provides a common infrastructure. Often-needed things like configuration of services, enabling/disabling services for certain applications, monitoring of services and so on are provided by the framework, into which the several service adapters can be plugged.
The application server startup is controlled by the node manager. When the "outer" Tomcat starts the IS7 web application, this triggers the initialization of the embedded servlet engine, several important subsystems and the cartridge engine. All cartridges from the cartridge list are loaded and initialized by calling their initialization hooks for the various initialization states. In the hooks, a cartridge registers its contained elements like pipelets, persistent objects and so on at the responsible engines. Depending on the runtime mode, the loading of elements like pipelines and pipelets can be done lazy (i.e., on first access, good for development because short startup times are needed) or eager (good for production, because the system must be fully initialized and responsive immediately when it is loaded).
All requests from web users go to the web server with the IS7 web adapter. The web adapter checks the page cache for a cached response for this URL from previous requests. If a page was found there and is still valid (i.e., it is not expired), it will be prepared for the client and served immediately. If no cached page was found, an application server is selected and its request handler servlet is called to handle the request. Which application server will be called depends on session affinity (i.e., all requests from the same session go to the same application server), server group configurations and load conditions in the cluster. For initial requests (i.e., new sessions or session-less requests), the load-balancing algorithm selects a server so that the overall average response times are minimized.
If the request is a pipeline URL, the request handler servlet triggers the execution of the pipeline. Depending on the requested operation, the pipeline consists of pipelets that operate on business objects with underlying persistent objects from the database. The pipeline ends with an interaction node, which usually links to an ISML template. This template will be rendered by the JSP engine after succesful compilation of the template. The response is returned to the web adapter, which optionally stores it in the page cache, if it is cacheable. Finally, the response is returned by the web adapter to the web client (the browser).
In addition to the request handler servlet for pipeline requests, there are some more servlets running in the application server, which are responsible for handling other request types:
The general flow is the same.
IS7 has the capability to execute scheduled pipelines in regular intervals as background jobs. Typically, this feature is used to implement reoccurring tasks like scheduled order exports, import processes or database cleanup operations. When and how often a job is to be executed can be configured by the business operator in the SMC. The number of jobs that may run concurrently on a single machine can be limited via configuration to avoid overload situations with computationally intensive tasks. Some customers chose a setup with dedicated server(s) in a separate server group, which is exclusively responsible for job processing and does not get any storefront traffic. This separates the load by background jobs from the storefront load.
Under certain circumstances, the execution of multiple jobs must be synchronized, because they depend on each other. For example, a job for rebuilding the search index should be started right after the job for the import of product data has finished. In this example, having fixed time slots is not a good solution, because the runtime of the import job may vary and there would be a gap with an invalid index before the index builder is started. To solve this, IS7 supports the definition of process chains, which synchronize the execution of multiple depending jobs.
The job framework is also used for scheduling non-repeating background tasks, like long-running actions that are started via the user interface. Such actions must be decoupled from the UI response.
IS7 comes with set of preconfigured jobs to support the administrative staff. See the document Intershop 7 Preconfigured Jobs available on the product DVD under docs/pdf/is7_admin_jobs.pdf.
Many parts of IS7 are configurable by system administrators, developers or others. The configuration can be stored in different file formats, like XML files, property files or even in the database, depending on the particular subsystem. The access to such configuration values by the implementation is simplified by the configuration framework.
IS7 uses various logging systems for writing different kinds of information to log files. In the application server, the SLF4J library is used as the logging API. This library allows a flexible configuration of log targets, log scopes, log levels and so on. Typically, the following information is logged:
The scope, detail etc. of information to be logged to which log target can be specified in configuration files or at runtime in the SMC.
The web adapter access logs are packaged and transferred to the application servers via the web adapter agent. They can be analyzed by the Intershop Commerce Insight service (ICI), which is a reporting service that is provided by Intershop to its customers as an SaaS.
The IS7 locking framework allows to lock/unlock resources (e.g., objects, processes) that are potentially subject to concurrent modifications or executions by multiple users in order to serialize modifications and to avoid conflicts. Several business features support locking in the user interface. For example, the pages of the Commerce Management application for managing product data allow to lock the product that is currently being edited. Consequently, other business users cannot edit the same product at the same time. They have to wait until the lock has been released by the current owner after the modifications are done.
There are various kinds of lock implementations with different lifespans and conflict resolution strategies.
User authentication can be done at the web server and/or in the application servers. For web server authentication, the Apache web servers can be integrated with authentication back ends like LDAP. For the authentication of users in application servers, IS7 supports the Java Authentication and Authorization Service(JAAS). Usually, all users and their credentials are stored in the IS7 database, which is integrated into JAAS by a special plugin. Authentication via LDAP or other mechanisms like Single Sign-On across different applications is also possible in the application servers by employing another JAAS back end.
The authentication state of web users is represented by a secure cookie containing an authentication token. This cookie is only transmitted in HTTPS connections, therefore all protected views and actions must be invoked via HTTPS. For REST, authentication can be done on every request and/or also using token-based authentication.
Besides the user management within the IS7 application, there are various other user accounts involved:
As with authentication, authorization can be done on several levels. Besides file permissions for the OS users, database permissions for database users and web permissions for web server users (controlled by Apache), IS7 can perform permission checks for the execution of pipelines. The permissions that a user must have in order to execute a pipeline can be specified in a pipeline ACL file. Usually, all back office pipelines are protected, while all storefront (web shop) pipelines are open for anonymous users.
Pipeline permissions can be managed for groups of users rather than for individual users. Assigning users to groups/roles can be done in the Commerce Management application.
Auditing is the logging of actions that are done by users in the system, i.e., who did what and when. It is required by the PA-DSS certification that all administrative actions (like those done by the business operators) must be logged. IS7 comes with an auditing framework that allows to audit operations on business objects/processes.
For improving performance, caching is employed at several places and architectural levels. In the web adapter, complete HTML pages and/or fragments of HTML pages or similar documents can be cached in the page cache. This cache stores the cached text documents in the file system of the web servers. With the page cache, the load on the application servers can be reduced drastically, since only dynamic pages like the basket or user registration pages must be rendered by the application servers. Many other pages that contain relatively static content like product details or catalog pages can be cached and be directly delivered to the clients without accessing the application servers.
Within the application servers, the ORM engine caches all persistent objects that are stored in the database. This cache helps to minimize the load on the database. ORM caches of different application servers can be synchronized with each other.
For several other business features, specialized caches have been implemented to solve performance problems.
A common caching API allows to register existing caches and to trigger operations like cache clearing, which are often necessary after import processes or other changes of the underlying business data.
Technical application parameters like memory consumption, CPU utilization, database connections or cache hit ratios of the application servers can be monitored using JMX. With performance sensors, it is also possible to measure the runtimes of pipelines, SQL statements or other processing elements. The runtime behavior can be inspected in the SMC.
The Intershop Commerce Insight (ICI) allows a detailed offline analysis of the execution times in order to find performance bottlenecks or to detect technical problems.
In addition to the built-in monitoring capabilities, the OS, the web servers and the database provides information that can be visualized in monitoring software, like via SNMP.
Internationalization (i18n) is more than just the translation of texts into different languages, it also includes topics like formatting values, unit systems, regional settings, time zone handling and so on.
Most content in IS7 can be localized. For the web shop application, static texts in templates can be externalized to resource bundles that map the keys to translated texts for the supported languages. Back office pages are currently translated by translating complete templates using the tLoc tool. For business objects that are stored in the database, texts like names, descriptions and so on can be stored in multiple languages in the database. Which locale must be presented to a user is decided using a locale fallback. Several fallback stages are supported, like session locale, application locale, system locale etc.
IS7 is able to handle prices and price calculations in multiple currencies.
Development of the IS7 product itself and of customer projects must be done in Intershop Studio, which is an IDE based on Eclipse. Intershop Studio provides editors and views for all implementation elements, like a graphical editors for pipelines, text-based editors for ISML templates, and so on. It also comes with the code generator that can generate the Java code for persistent objects and other elements from EDL models. Running applications can be debugged with an integrated pipeline debugger, or with the common Eclipse debugging facilities.
Beside the IDE, a version control system (VCS) is needed, such as Subversion or similar.
For all elements that make up IS7, naming conventions and programming style guides exist. Intershop Studio can (partly) validate implementation elements for their compliance.
Starting with version 7.4 CI, Intershop uses a Gradle-based framework for build and deployment. Thus, Intershop supports setting up various environments for development, testing, production etc.
Building the system is done locally by the developers to test their code before submitting it to the central VCS of the project. Building a release from the source code is then done by a central build system. Recently, CI systems have become popular. IS7 comes with a standard build procedure for a CI-based build.
The binaries from the build system are published in a repository, from which they can be deployed to the working environments using the IS7 setup procedure. There may be different deployment scenarios, like single machine deployments, or complex landscapes with multiple edit systems and live systems that make up separate clusters. The exact layout of such deployments is customer-specific.
In addition to setting up the server installations, the population of the database with initial content, demo content or even production-ready content is necessary. To support this, IS7 provides the DBInit/DBMigrate tools.
Automated testing of IS7 applications can be done on multiple levels:
For all kinds of tests, supporting test frameworks are used, which are usually based on JUnit.
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.