Introduction to Vertec customizing
Cloud Suite
On-Premises
Customizing is about adapting Vertec to individual customer needs.
Vertec is highly customizable, so there is a wide range in the complexity of customization. From creating a folder structure and customizing list settings to fully automated workflows, anything is possible. But how do you decide when and what customization is needed? This article will help you make that decision.
Basically, the less customizing, the better.
This is very simple, of course, but it is important to keep in mind that any customization also requires maintenance and can carry risks in terms of clarity and performance. See also point 6 of our 10-Point Plan for a Sustainable Vertec Installation.
The first consideration should therefore always be: what is out-of-the-box and can we live with it? And if not, how can we make it what we need with as few steps as possible?
The Vertec software knows its object model at run time and can also be navigated via OCL. To be able to customize Vertec, you must know the model and know how to navigate it. It can be found in the Vertec Model Browser and can also be accessed via the Vertec python module “vtcmodel”.
Vertec customizing takes place in the full-featured Apps (Cloud App, Web App and Desktop App). Specialized apps such as the Phone App or the Outlook App cannot be customized.
The full-featured apps all have the same user interface – so customizing automatically works the same everywhere.
The different ways to customize Vertec are listed below. The order says something about the complexity of customizing with these elements. The higher the list, the more straightforward; the lower the list, the more complex and potentially riskier.
Often there are different ways to achieve a result. Then you should choose the simplest option possible.
The user interface of Vertec (we always talk about the full-featured Apps here) consists of a tree view on the left, and what is selected in the tree is shown on the right – either a single object or a list of objects.
The least invasive (and risky) method of customizing the Vertec user interface is to add new Folder, which must be subfolders of existing parent folders (root folders) or new root folders.
These folders can contain objects that are manually linked to the folder itself, or they can be defined as Keyword Folder, in which case the subfolders are the keywords that can be shown and selected on the pages of a single object.
These folders can also contain other folders such as Sql folder or Expression Folder.
An Expression folder is a folder whose contents are calculated using an Ocl expression.
This is a very powerful and risk-free thing, but can lead to significant performance issues if not configured wisely. For a good description of this, see the article Performance of ocl queries.
As a better performing alternative, a SQL folder can be used instead.
An SQL folder calculates its contents like the Expression folder, but the objects are retrieved via SQL.
This has the advantage that the objects in the database are filtered and only the result list is loaded into memory. For a good overview of this topic, see the article Performance-optimized access to vertec objects.
If you want to show intersections or subsets from other folders, you can select a Query Folder.
The principles for performance-optimized access to Vertec objects also apply here.
How the list of objects in the folders and containers (containers are folders containing the objects linked via link types) are shown can be parameterized via the List Settings.
These columns are defined by Ocl expressions and Renderer. Again, as long as only attributes of the objects loaded in the list are accessed, there is no impact on performance.
As soon as calculations are made that access objects that are not in the list, they have to be loaded – for each row individually. The more, the slower. In particular, global accesses are absolutely to be avoided. In such cases, it is worthwhile to use a List Controller, which only pre-computes this data once, and show the results via Custom Renderer.
Associations, i.e. links between Vertec objects located in the Model, can be brought to the user interface via Wrapper Link Types. Their objects on both sides are computed via OCL. The simplest form of an expression is the association itself: rechnungen for all invoices of a project. But you can also use more complex OCL expressions, for example rechnungen->select(not bezahlt) for all unpaid invoices of a project.
Each link type creates two folders on each page in which the linked objects are displayed. These are called containers. How these lists are displayed can be set in the List Settings.
a variety of wrapper link types are already included – examples are the services on users, the own projects on project leaders, etc.
If links are required between Vertec objects that are not in the model, Custom Link Types can be created.
Custom link types are individual associations between Vertec classes. The objects are linked via the user interface (Drag & Drop) or can also be set via a Script.
Tags are suitable for marking Vertec objects in order to be able to search for them efficiently (yes/no marking).
Keys are designed to buffer customer-specific values, which can then be queried via OCL in a performant manner.
These values can be set either via Scripts or via the user interface with a Custom Renderer.
Custom Fields can be defined for all classes that inherit from Entry (i.e. are subclasses of Entry, see Model).
Custom field items appear automatically on each object on the More Information page and can also be shown in lists via List Settings. It is also possible to place them on other Pages of a single object and access them via Scripts.
It is a powerful feature, but not a powerful one: the values in the custom field items are not saved directly on the object, but on a separate additional field object. This list of objects has to be loaded first, if you want to load it e.g. via ->select() wants to filter.
Here, it can be worthwhile to rely on powerful alternatives such as Keys and Tags instead of an additional custom field item. Their handling is a bit more complicated at first glance, but with the help of Custom Renderers, very simple applications can be achieved for the end user.
Vertec has 50 “empty” classes, the Custom Classes. These have no members (except those inherited from their superclass User Entry, see Model) and no functionality. They are used to create objects of an individual kind that is not included in the model.
In order to be able to use an additional class, it must be defined in the Class Settings and create additional Custom Fields items for it. Then they are linked to other objects via Custom Link Types in order to appear on the interface. In these containers, the individual objects are then created either manually (tick the new link type) or via Script.
The custom field items appear automatically on the first page (not under More information), sorted according to their order on the additional field definition. If you want to influence the appearance of this page, this can be done via Customizing of pages.
Individual objects such as projects or invoices are displayed in pages, so-called Pages They are defined in XML, and via page Customizing of pages you can overwrite existing parts of pages, insert or remove elements from them, or add new pages. The XML of the pages is saved in the Class Settings.
Vertec includes a Python Runtime Engine (2.7 for backward compatibility and 3.12). In Scripts, Vertec objects and business logic can be accessed via the Module “vtcapp”. They are registered and can be shown as menu items on Vertec objects or in lists so that users can trigger appropriate actions.
The creation of Office reports (word, excel, pdf) in Vertec is done via a script that generates the structure to be printed and a Word or Excel template to define the visual appearance.
A variety of Office reports are included as standard, see All vertec reports at a glance.
To customize the standard reports to suit your look and feel, you can download, customize and re-upload existing templates. To incorporate logic, you can extend the existing scripts. You can also create entirely new templates. For more information, see the article Register reports.
Validity conditions, so-called Constraints, are OCL expressions that are evaluated on objects and define whether the object is valid or not.
Invalid objects are shown in red in Vertec, and new objects that were never valid are automatically deleted when you leave Vertec. See also the article Validity / status of entries.
Since the validity check always takes place, i.e. even if an object is only shown (individually or in lists), it is imperative to pay attention to the performance.
Python scripts can be registered not only as Menu Items, but also as Scripts on events that are triggered automatically when certain events occur, such as when a new object is created or a member is changed.
This interferes with Vertec’s business logic, and care must be taken to ensure that no invalid states can arise as a result.
This must also be documented very well, so that it is clear why and how such processes take place in the background.
The Vertec Business Intelligence (BI) module creates the raw data in Bi generators using Python code, which are saved in a BI cube and displayed on the Vertec user interface by means of Bi measures and Bi views.
It is possible to create new generators with user-defined measures. It is also possible to create customer-specific BI shows using the already existing measures and to store them as String representations in folders.
The numbers can also be shown in Vertec lists via Ocl operators for querying bi data or further processed via Python feature for querying bi data.
A List Controller is a Python script that can be assigned to a folder or link container and executed after a folder has calculated its contents. It can be used to preload objects for performance reasons and to pre-calculate values to be shown in the list. The values are then accessed and displayed in the list via Custom Renderer.
Custom Renderer are defined in Python and are used to show values in lists or detail pages. Most are used in conjunction with List Controllers to show pre-computed values.
Custom renderers can also be used to render values differently and to make it easier to enter Keys and Tags through the user interface.
For Cusom renderers, it is especially important to pay attention to the subscriptions so that the displayed values automatically update when the underlying values are changed.
With the Resource Planning module, special list controllers can be used to define the behavior of Vertec Resource Planning. The displayed graphics (and values) are defined via utilization dimensions and views. The area is complex and performance-relevant, as complicated calculations can significantly slow down the handling. You can find an overview in the article Ocl, python, custom renderer and list controller for resource planning.
Vertec provides a web service with the Vertec rest api as standard.
You can also create Custom Web Services to access Vertec from the outside.
To do this, a script is created that defines a Python class that WebService by the Vertec python module “vtcweb”.
The deployment as the endpoint of the URL is done via the Web Service object.
Using some examples, we would like to guide you through possible ways of thinking when choosing an adaptation.
As an example, we would like to assign addresses to one of the following states: PersonalAcc, K, IOK, or Internal.
To achieve this goal, there are the following options:
If we look at the List, which of the variants is as high as possible, our choice clearly falls on the Keyword Folder.
This variant is particularly suitable for root data such as projects, addresses or users, in order to categorize them. The advantage is that you can also immediately view the assigned objects in the keyword folders.
As an example, we want to target addresses. So we want to be able to identify whether an address has already been targeted or not.
There are the following variants:
a Boolean additional field is easier to create at first glance, but it performs poorly especially for yes/no searches, since the value is located in an auxiliary object, which has to be loaded separately for all objects.
That’s why we select the Day and set it up so that the user can also simply put a check mark. You can find instructions on how to do this here: Set a day.