Overview of New Technical Features

Information

• This topic provides an overview of the most important changes in PLANTA server version S 39.5.0.
• For those responsible for the operation of the PLANTA server, changes to the architecture, the new installation procedure and the PLANTA service are particularly important since changes in environment, configuration, and operation may result from them.
• Application developers, who develop individual solutions on the basis of the PLANTA software and know the structure of the previous releases, are supposed to gain an understanding for new possibilities and necessary adjustments to the mode of operation and customizing.

Release Procedure

A split of the previous complete software packet enables you to shape the development in a component schedulewise independently from the other components. Through the release planning for one component (instead of all components at once), faster cycles can be complied with and a more focused planning can take place. Here, the compatibility with older versions is maintained where possible. That way, subcomponents can be refreshed as well, which helps to keep the risk of getting unwanted changes additionally to the desired ones at a minimum.

This procedure has been used for all client versions from C 39.5.0 as well as for server S 39.5.0 which is described here. This server can be used with database version 39.4.4.0 and client version 39.5.2.

Architecture

In the course of further development of the PLANTA server, different problems have become apparent, that could not be solved on the technical basis used by then. Thus, along with this new architectural concept, the basis for future developments was set, benefiting PLANTA server users directly.

By using a 32bit architecture, previous releases had huge problems to deal with great amount of data and comprehensive calculation. In 32bit architecture, depending on the operating system, only 2-3 GB of addressable memory are available to processes. This may cause the system not to allow any further reservation, even though there is enough memory available. As a result, the process could not be continued. After changing to the 64bit architecture, you can theoretically address 16 EiB. Thus, in practice, the only limiting factors are the complete available physical memory or a configured memory limit.

In the previous architecture of the PLANTA servers, a new server process has been started for each client connection. The server start was administered by an individual component named ppmsd and the functionality of the OS, like xinetd in Linux and Services in Windows. Each process maintained an own data connection via client libraries like OCI and ODBC.

In the new Java based multithreaded architecture, each session (≙ client connection) that used to run in an isolated process will now be processed in the context of a thread. Therefore, no new process is created during a client connection. Hence, only the PLANTA server process in the JVM is visible from outside. That is why there no longer is an additional service that starts the server during a client connection. Instead, the PLANTA server is synonymous to this service ("PLANTA service"). Additionally, we have realized a data base layer, via which connections can be split for a better resource utilization.

By the use of Java and a stronger division into components, the directory structure has changed significantly. The py directory, in which the Python customizing is stored, still exists. However, the internal structure of this directory has reordered. For further information on this, please click here. Furthermore, the conf directory is important for the configuration of the PLANTA server since here, settings can be made that are thematically divided into several files. For further information, click here.

Database

With the database abstraction layer, PLANTA has taken a significant step towards data independence and is therefore able to versionize customizing data for PLANTA internal development. Furthermore, comprehensive and partially optionally employable mechanisms for secure record identification, data protection against corruption and against customizing errors, have been developed.

The use of a database abstraction layer named Hibernate, enables the following:

1. Common use of connections (connection pooling)
2. Identification of database connection problems
3. Use of a standardized database client (JDBC)

Furthermore, hibernate enables the future establishment of database independence as well as an object relational representation. As of now, the interface does not show any differences for users and application developers, compared to the previous version. Hence, SQL scripts are encoded in the native DBMS dialect. An advantage for users results from the configurability of the connection pooling, which can help to restrict the database server load.

An advantage of the use of Hibernate is the historization of customizing tables. For each table of the Q1B and Q2B schemas, another table exists, in which every change is recorded. Previous customizing statuses can therefore be restored or changes can be reproduced. For the time being, this feature is only accessible for PLANTA.

Since for each of these tables, a class in the PLANTA server exists, schema changes (adding or deleting DIs) cannot be performed any longer, except in DT400. Tables of the Q1B and Q2B schemas can no longer be deleted or added. Changes of this type have previously been reserved for PLANTA.

UUIDs (Universally Unique Identifier) serve as key fields of record identification. As a result, key changes, as required for drag&drop, can be made. In the Work Areas module, you can, e.g., move modules from one work area to another, which was not possible before. Currently, the UUIDs are only available in Q1B and Q2B Therefore, drag&drop moving with key changes is only possible in data tables of both of these schemas. Optionally, other (individual) tables can be equipped with UUIDs and therefore benefit from the advantages mentioned.

While starting the server, a "customizing validation" is performed, checking the data structure (DIs, DTs and relations) for correct customizing. When logging in, errors detected are presented to a user with customizing rights in a dialog message. As a result, the application developer has the option to note and correct customizing errors not only after the occurrence of error statuses through analysis, user complaint or log messages but beforehand.

Python

Some of the errors and performance problems contained in Python, have been solved by a Python update. A new directory structure for Python customizing is to facilitate adjustments and updates.

The previously used Python Version 3.0 has been upgraded to version 3.2. Details on improvements can be found on the Python website.

The organization of the Python files has been changed in order to achieve better update safety. For this purpose, there are the new system, planta_de, planta_ch and customer directories in the py subdirectory. The structure in these directories is identical. system contains all files that are available in the remaining directories. However, these files are generated (like the directory structure). They serve to embed Python modules as a wrapper via import, enabling overwriting of functionalities. If new Python source files or packets are to be added and not only overwritten, the Python structure has to be generated anew. For further information, please click here.

Other than before the architecture change, there is now only one Python interpreter for all instances. This leads to architectural limitations with regard to the Python customizing. Hence, we advise you against using session data via __builtins__, modules and class variables since these storage locations are available for all sessions now. E.g., a module object which can be accessed via __builtins__['my_module'], can be closed via __builtins__['my_module'].menu(49) from every session.

In order to provide you with storage throughout a session, there is the get_session_dict() function, returning a dictionary to be used instead of __builtins__ or other global storage options.

Installation, Migration, and Operation

A new installation procedure facilitates the setup of the PLANTA server significantly. It allows you to set up the program via both a graphical surface as well as via the console. Since the installer is based on Java, the setup procedure does not variate significantly on different platforms. The Client and server update with automatic installer topic describes use and installation requirements.

Furthermore, Migration Process are now used to import a hotfix instead of the previously used update scripts. Migration packets can and should now be used for indivdual application development as well.

There are scripts for the installation of the PLANTA server as a Hotfix on an existing PLANTA 39.4.4.0 installation which are required to use release S 39.5.0. They also retrofit the infrastructure for the use of migration packets. A detailed description of the required migration steps can be found here.

The installer also sets up the platform-independent PLANTA service. Via the PLANTA service, the server can be started, reloaded, and stopped in a standardized manner.

Authentication

Besides the known authentication mechanisms, the authentication can now be done by a Kerebos service. This enables single sign-on in PLANTA project. A connection to Microsoft's Active Directory can be done via the Kerberos authentication. The configuration of PLANTA server and PLANTA client is described here.

---

See also: Release Notes