When using the Novulo platform to implement or build Novulo web applications, you will come across a lot of Novulo terminology. While some terms may sound familiar, they often have a distinct Novulo-specific meaning and should not be confused with more general terms.
Application
In the Novulo context, an application is one instance of a Novulo web application that users can log in to do their work. Customers often have multiple applications, like a development application and a production application.
Component
A component is a piece of Novulo software that is built with the Novulo Architect to fulfil a specific business need or to solve a technical problem. Components can, but do not have to, contain the following types of information:
- User interface elements like grids, buttons and fields
- Processes to execute logic and manipulate data
- Functions that return data based on their context
- Data structure to create or extend SQL tables
- Documentation about processes or fields
Component revision
Each component has multiple revisions. When component changes are saved this leads to a new revision.
Produce
Producing is the way to make parts of Novulo components accessible for other components by adding them to the reference architecture. It is possible to produce concepts, features, enumerations and processes.
Consume
Components can have dependencies from other components by consuming concepts, features, enumerations or processes from the reference architecture. Most consumes create a mandatory dependency from a producer. Only consumes of processes can be set to be optional. This means that the component can still work as intended when the process logic of the other component is not available.
Expressions
Novulo has its own expression language. It is used for the development of components and for the configuration of applications. It allows for the retrieval of data and the calculation of values. Novulo expressions are parsed into SQL SELECT statements during their execution. Novulo expressions can be built/displayed visually in the architect or as plain text.
Reference architecture
The reference architecture exists to allow for the seamless integration of components. As all components use the same data model, they all speak the same language and can therefore be combined and reused. The reference architecture stores all produced concepts, features, enumerations and processes and can be found in the “app server”.
Concept (Data concept)
A concept refers to an entity that relates to a database table in an application. For example, “N_Sales” is a produced concept that relates to the SQL table “sales”. Concepts are a key part of the reference architecture and make sure that logic can be combined and reused as components all speak the same “language”.
Feature
A feature is a property of a concept and extends an existing record type. It can either be a field or a function.
-
Field: For example, the produced feature “N_Number” of the concept “N_Sales” refers to the field “number” of a sales. It can be related to an actual column in the database. The name of the database column is defined by the name of the “attribute” of the feature.
-
Function: A feature can also be a calculated value of a concept. For example, “N_Is delivered (fx)” returns the value yes or no for every sales record based on a calculation. In most cases functions are not columns in a database and are recalculated in realtime.
Enumeration
An enumeration is a list of options that is not supposed to change. It is often displayed in a dropdown field and can be used in expressions and processes. A popular enumeration is “yesno” with the value “Yes” and “No” or “HTTP Methods” with the values “GET”, “POST”, “PUT”, “PATCH”, “DELETE”.
Process component
A process component is a piece of logic that can be executed to manipulate data. Most process components have input parameters and return values. For example:
“N_Sales - Generate order confirmation PDF”
Input parameter: sales (record type N_Sales)
Return parameters: success (boolean), error (message), confirmation (file)
Model
Every component is also a model and has a unique model number. A component can also be referred to as “component model”.
Multiple component models can be merged into a large integrated model which also has its unique model number. Integrated models are also called “application models”.
Appserver
The app server stores the reference architecture, component model revisions, application model revisions, plugin revisions, icon pack revisions as well as model rights.
Architect
The architect is used to build new components and to improve existing ones. Depending on your right profile, you can view and/or edit components and save new revisions. With the architect, one can access the reference architecture to consume and produce.
Framework
The Novulo framework contains the default UI elements and basic logic of every Novulo application, regardless of the components that it consists of. The framework defines the basic look of the start screen, grids columns, tiles, fields, forms, buttons, tabs etc. It handles all user interactions in a Novulo application and provides default features like user rights, the expression debugger, performance analysis and more. The most recent framework version is 3.9.
Plugin
A plugin extends the capabilities of the architect and the framework. For example, with the calendar plugin, one can develop a component with some calendar UI, or with the Serialization plugin one can easily generate JSON strings to use them in processes.
Composition
A group of multiple component revisions can be combined to form a composition. The composer is used to form new compositions.
Composer
The composer is a Novulo application that helps to create new compositions where all dependencies between components are solved. It is possible for multiple components to produce the same concept, feature or process. This allows for the composer to let the developer choose between alternative producers. A composition is only valid if for every “mandatory consume” there is exactly one “produce”. Once a composition is valid, it can be sent to “Deployment” to start an order.
Integration
A composition that has been validated by the composer can be integrated into one large model. An integrated model has its own model number and is a merged version of multiple different components revisions. Integrated models can be viewed with the Novulo architect. Integrated models are used to generate code for applications.
Generation
Based on an integrated model, application code can be generated. This results in a bunch of C# files that can be deployed on a server to form a new instance or to update an existing application. Also, an SQL update script is generated based on the previous revision of the integrated model to ensure that the database of an application is updated correctly. These files are stored in a central repository (SVN).
Installation
The goal of an installation is to update an application. In an installation, the version to install can be chosen one of the generated one in the central SVN repository. An installation also requires a manual check of the update scripts to ensure that the application database will have the right structure and data after the installation. The installation files from the repository are bundled up into a .zip file. This .zip file can then be sent to an installer on another server, or it can be downloaded and installed locally.
Installer
An installer handles all application updates and the maintenance of one or multiple instances on a single server. It receives .zip files from deployment, extracts them and handles all required steps to finish an application update successfully. It is also used to configure a trace analysis for an application, for example.
Dataset
A dataset is an XML file that contains data about application configuration. They can be imported into an application to speed up the implementation process. For example, instead of manually copying settings in a development application to the production application, one can create and distribute a dataset. Datasets revisions can be maintained in deployment
Deployment
“Deployment” is a web application combines the integration, generation and installation for Novulo applications. It is used to maintain, update or create Novulo applications.
A deployment order is created when a developer choses to send a new composition. An order combines the steps for integration, generation and installation. A successful order results in an application update.
NovuloNetwork
This web application is used by Novulo employees to plan work, store documentation and handle service requests (SR’s) from partners and customers. NovuloNetwork also stores all product issues (PI’s) and release notes for application updates.
Product issue (PI)
A product issue stores the documentation related to the change of a component. Every time when a new component revision is saved, the developer has to document the changes in a message. Those messages are bundled per product issue. A product issue could be called “Bugfix for type error” or “New feature for generating invoices”. Even though the name suggests that only “issues” are stored as product issue, also new features and improvements are stored the same way.
Service request (SR)
A service request is a ticket in NovuloNetwork that is either classified as a bug, a new feature or a question. Service requests are used to communicate with customers and partners to identify needs and to share progress updates. SR’s have a unique number that starts with SR. For example: SR12345
Novulo platform
The Novulo platform is the combination of all terms mentioned above. It allows for rapid development and deployment of production ready business applications.