Introduction

Onesait Platform integrates functionalities for the generation of applications, providing facilities for the creation of web systems from a base template. This base Web Template allows us to easily create deployable web applications as web projects on the Platform using No code.

In this tutorial, we will detail the different components and configurations to be made to deploy our own web project. We will see the generation of a project, where different resources will be embedded, such as dashboards and / or forms, which at the same time will enrich the web template that will expose the information based on a role-based authentication.

Open

Components of the application or project generation example

The Platform Application or Project concept allows to create a collaborative Environment, in which platform users with different roles can create grouped Platform concepts, allowing also to assign a security domain, web application, etc. from a single point.

For this example, several Platform services will be used to achieve a complete application, with several resources and user management by roles, among them:

• Template web: project in Vue.js, which includes a complete integration with the Platform.

• Realm: which allows the creation of security domains for our application.

• Centralized configuration: Allows the configuration of web template menu components and access by roles or users from a YAML file created in the Control Panel.

• Internalization: allows us to have centrally managed internationalization files for applications, dashboards, forms, menus...

• Dashboards: The Platform allows the creation and visualization of dashboards on the information managed by it, consumable from different types of devices and with analytical and Data Discovery capabilities.

• Forms: The aim of this functionality is to support within Onesait Platform the development of Web applications with a No Code approach. Thus, from the Control Panel you will be able to create forms, assign Entities (and DataSources) to them and navigate between forms.

• Web applications through Git: System that allows us to manage our web project, from editing the project to compiling and deploying it automatically.

Open

Next, we will see in detail the generation of each one of them, finally arranging our own web project managed and enriched by Onesait Platform.

Tutorial Steps 

Step 0: Starting Point

Before starting to generate all the resources, we are going to download the Platform web template in our local from our GitHub repository.

To mount the distributable (dist) of the Vue2 project, we are going to compilate it. We can do this with both NPM:

As well as with Yarn:

Once the resources have been configured and our project has been generated, we will have a web page similar to the following one:

As can be seen in the image, the template is structured in an access menu on the left side and a central area to display the associated Platform resources. From here, we can see what we will see and/or not be able to see depending on our users, roles or Platform elements added to the project.

The template also adds by default user management and a section for notifications:

We will perform step by step the creation of resources on the Platform with the creation and deployment of our web project, where we can see how to generate a web system on this template, making our own web app.

Step 1: Generation of Roles in the Application

To manage permissions by users in an Application, we can manage them user by user or generate a specific configuration through the Platform’s Realms.

From the menu Development > My Realms of the Platform, we can create our own permissions hierarchy, defining all the necessary roles for our Application.

At first, we will access a list of previously generated Realms, where we can edit them and/or create a new one at any time. In our case, we will generate a new Realm from the creation option.

When creating a new Realm, we must define an unique identifier for our Realm (in this case “helsinki_realm”) and a simple secret (“helsinki”). We will also define all the possible roles that will be finally managed in the app. In this case, we will add two different roles: “admin” and “analyst”, and we will create our Realm.

After creating our Realm, we will be able to edit it and assign the Platform users we want to have access to our application, associating specific roles to each of them. Later, in the centralized configuration and in projects, we will see how to give specific access to each role or user.

This management will allows us to see the Applications where our Realm is associated or to associate the roles of our Realm to another one already generated, making it possible to link it directly with multiple applications, etc.

More information on how to work with Realms can be found in this guide.

Step 2: Datasource Creation

As base information for the following elements that we are going to generate, we will create our own datasource on an instance, and then we will be able to link them with the resources.

To do this, we will go to the Visulization & GIS > My Datasources menu.

From this point, we will have a list of all those DataSources in which we have permissions and allows the creation of new ones.

Using the wizard we can easily generate a query for our entity (“helsinkiPopulation”).

Here, we will be able to execute our queries before creating the DataSource, thus validating the final structure that we will need to generate the rest of the resources on our query.

To assist in the generation of queries, the Platform adds the Query Tool functionality. This is accessible from the Tools > Query Tool menu:

This tool facilitates the generation of more complete queries through the query wizard and allows us not only to compile and execute our query, but also to export the results in different formats such as: flat file, JSON or CSV.

This query tool has a generative AI integration to support the creation of queries with natural language.

Step 3: Dashboard Generation

For the first element to integrate in our application, we will use a simple Dashboard, although as we will see, we have multiple elements to add to our application.

From the menu Visulization & GIS>My Dashboards, we can generate our own control panel, in this case we will generate a simple dashboard even having endless possibilities, as we can see in detail on the web at Dashboard Engine.

In the "My Dashboards" section we will find a list of all those to which we have access, either because we are owners or because we have permissions on third-party dashboards. In the same way as all the elements, we will be able to create a new dashboard from the option at the top right.

To begin with, we will configure the Dashboard itself, which we will call "helsinki_population", adding its basic information and tags, as well as the option to add libraries and scripts to generate our own format. Once we click on create, we can enter the workspace of the dashboard itself and edit, adding elements to it.

Once the Dashboard is created, an editing canvas will be enabled to be able to compose our Dashboard using different elements or gadgets (already created in the Platform or with the possibility of creating them at the moment).

In this case, we will create a demographic Gadget of the population of Helsinki, so we will add a new element to our Dashboard.

From the selector to add elements, we will be enabled a section with the various Gadget and styles, which we can add the one that interests us by Drag & Drop.

In our case we will generate a Gadget of type bar, that when dragging it to the canvas will open a wizard to complete the gadget, where we will associate the datasource that we generated previously (“helsinki_datasource”).

We deploy all the wizard options and add the information we want to display, keeping the literal of the names for later internationalization: "helsinki.year", "helsinki.population", etc., and linking in "Field" the corresponding parameter of the instances collected by the DataSource.

The generation of the sample represented on the Y-axis has two configurations. The first one in which the different data to be displayed are added:

Subsequently, in the Data option, we will link the Y axis identifiers with the data to be represented, allowing us to configure each one of them independently, selecting max, min, color, etc. In this way we will add all the Y axes previously configured.

Finally, from the Entity of the Platform itself, we have been able to generate a real-time representation of the information recorded in the database through simple steps and under No Code methods.

Step 4: Form Generation

As a second element in our application, we are going to add two forms, one with an informative approach and a second one with the possibility of inserting data in an Entity.

Thanks to the Platform, the creation of these Forms is very simple, with multiple capabilities and with a very wide freedom of configuration as we can see in the documentation: How to work with OP Forms?

From the Visualization & GIS > My Forms menu, we can generate new Forms.

Next, a list will be opened with all the forms to which the user has access and we will have the option to generate a new one as any element in the Platform, which will enable us a space for the creation of a new Form.

This includes a palette of tools with various elements to attach to our forms, including basic systems such as adding a “Text Area” or more advanced ones such as list generation.

The workspace itself, adds a section of tips or advice to work on our own Form, with support in its generation and editing.

For this example, we will generate two forms where we will define the names similar to the rest of the resources generated for our application, facilitating their subsequent internationalization (see more Step 5: Internationalization Files).

Writing Form

The first form (“helsinki_population”), will be generated automatically from the structure of the “HelsinkiPopulation” Entity, just by linking the entity we can select the button “Create Form from Entity” and a default form will be generated, editable and expandable.

The following image shows the auto-generated form, which in this case only the field names have been standardized to facilitate later internationalization.

The functionality of the generated button serves by default to perform insertions/updates in the corresponding Entity, but the triggering event is fully editable.

Once the form is generated, we can manage it from the Forms section, where the code associated to it will appear for its integration with other forms (“<form_name-user_name>”).

Reading Form

The second Form that we will generate will be exactly similar to the previous one, except that we will modify the elements of the default form so that it will only show us in the future the information of a record of the selected entity, in this case “HelsinkiPopulation”.

To do this, once the Form is generated, we will access the field by field edition and we will rename them for the internationalization standardization and edit them one by one.

In this case, we are going to disable the input of the element so that it is read only.

Table Pag Form

Finally, we will edit the default button and modify a little its style and functionality, since it will return us to the previous page from which we came from. We will add a redirect action and link in "Form Code" the code of our main form (“helsinki_form-demo_developer”) for redirection.

In a last form, that we will call "helsinki_form", we will focus on the creation of a list, with a CRUD functionality on the associated Entity, where we will finish linking with the two previous forms.

In this case, we will not auto-generate our Form, but we will use the tools offered by the editor itself as Table Pag (from the menu Data > Table Pag), adding it to the canvas by Drag & Drop.

Just by adding the element to the Form, we will open the configuration of the same, where we will define the different existing fields, such as the name ("helsinki_population") and the same datasource that we will use ("helsinki_datasource").

We will also be able to add different fields to our table (where we maintain the standardization of the labels for internationalization).

The tool itself will show us a preview of any change we make in the configuration, allowing us to adjust our final form in the best way.

The Table Pag also allows us to add actions on the table itself, where we can easily generate the action of delete on a data by means of its unique identifier (in this case “_id$oid”) and indicating that it is a delete button.

Also, we can associate other options, such as editing or creation through actions linked to other forms. Therefore, we associate this new element to the code (but not to the name) of the previous form created, in this case “helsinki_crud-demo_developer”.

As we can see in the final configuration, the creation of a form is simple thanks to a No Code method by the Platform, where we will add the code in the "FormCode" section.

In this way, we would have a table with the basic functionality to delete or edit records.

We also want to be able to visualize a data from this same table, for this we generate another functionality with the eye icon and in this case we link to the code of the form that we have generated only to visualize the information, in our case "helsinki_view-demo_developer".

Finally, we will add a button, which allows us to add information. To do this we drag the Button element from the tool palette.

We will place it, modifying its label and add the redirection to the form in Form Code, which in this case would be to "helsinki_crud-demo_developer".

In this case, the button will send us without added information, to the crud form, allowing us to insert a new record.

Finally, once the various functionalities have been generated and saved, we will have the management of the three forms:

In this way, we will be able to directly display “helsinki_form“ and have all the functionality centralized:

Add Info

The form will redirect us to the linked form ("helsinki_crud"), with an empty record for the insertion of a new data.

Display Record

It will link us to “helsinki_view” and we will be able to see the information of the selected record:

Edit Record

Where the form will redirect us to the “helsinki_crud“ form with the information of the current record, being able to make modifications on it.

Delete Record

With which we can delete the record from the database based on its unique identifier.

Step 5: Internationalization Files 

The Platform itself allows us to generate internationalization files to allow the change of language in the elements of the Platform.

To do this, from the Dev Tools > My Internationalizations menu, we can generate internationalization files grouping different languages.

We will access the internationalization management, where the files to which we have access (read or write) are grouped in a list. Also from this manager we will be able to generate our new internationalization file for the project.

For this example, we will generate a single file for all the visual elements that we have in our Project. In this case it would consist of the Web Template, the Form and the Dashboard that we want to add and all the languages that we want to implement in our application.

On the other hand, we will add the generic Onesait Platform Template Web file.

Internationalization of resources

When creating a new file, a template will be opened to complete the main tags for its identification, where we can add multiple languages for its interchange in our web project.

In this step, we are going to create these internationalization files so that our elements adapt and show the appropriate information to the user. To do this we will add a JSON for each language with the following structure:

As you can see in the example, we keep the same IDs that we have used when generating our form. Hence the importance of standardizing the creation of resources for reuse and adaptation in the future, reducing development times and maintaining the quality of the same.

We set the literals of the forms to arrange them homogeneously to those of the Dashboard.

Once saved, we can edit our different resources (Forms, Dashboard, etc) and associate our internationalization file. Once done, we will be able to visualize our resource where we will be able to observe the exchange of the defined values.

Internationalization of web template

Finally, we will have to add the internationalization to our web template, to be able to modify the language of the user interface, such as headers, footers or user management.

To do this, we will generate a new file called “helsinki_web_en_esp“ and add the configuration for our website.

In this case we attach the configuration for the Onesait Platform Web Template, which we could adapt for a new template.

Step 6: Centralized Configuration File

The Web Template needs a centralized configuration file, which stores properties such as the Realm name, client ID to use, menu accesses, application title, internationalization file name, logo properties, etc.

To create a centralized file, go to Dev Tools menu > My configurations.

We will access directly to the list of all the configurations to which we have access and from where we will be able to generate a new configuration through the creation option.

In this example, we are going to define a configuration named "helsinki_conf", linking to an external (custom) configuration and to the default environment (this being the Platform itself).

The configuration is very accessible, thanks to the possibility of completely editing the configuration file; from defining the navigation menus (with their corresponding icons) as well as the permissions to the different roles.

In this case, we are going to include all the management that we have commented; we define step by step all the fields that must be modified to work with the Platform Web Template , since this file is editable and adaptable to any template that a user can generate.

Definition of centralized configuration file

The first part corresponds to the configuration of the Platform, where we will have to adapt the different values such as:

• realmId: the name of the Onesait Platform Realm.

• clientId: the name of the Realm client.

• secret: the token to use in the Realm client.

• title: the name we want to give to the project.

• i18n: the name of the language configuration file.

• project: the name of the centralized configuration application.

In our case it would look like:

In addition, we will have fields that can be adjusted to a specific product, versioning, views, etc. such as:

• productInfo: The properties of the project logo. The main ones are:

• suite: Name of the suite. For example: "suite".

• product: The product name. For example: "product name".

• productModule: The product module name. For example: "module".

• onesait: If checked, the product and productModule properties are hidden. By default it is set to "false".

• appVersion: Refers to security layers. Default is set to 0.

• customization: Frontend customization layer.

• GlobalFilters: To show the language selector, the property "user.showLanguage" must be set to "true".

• To change the color scheme, you can touch the CSS properties of "styles".

Finally, we will define the navigation parameters by managing access by roles, where we will give full permission to the admin role and visualization to the analyst role:

• initialNavigation: Here we define the entry point into the app for each role type, in our case the administrator.

• navigation: Components of the application's side menu. Our example will consist of two accesses, one for the Dashboard and another for the Form (“helsinki_dashboard” and “helsinki_form”). To both definitions we will add the information of the ID of the associated Platform component, as well as the end point of the resource as “/forms/helsinki_form-demo_developer”.

• navigationAllowed: Corresponds to the list of access permissions of the different roles with respect to the previously defined side menu components. Using the two roles defined above we could generate full admin permissions, while the analyst role will only have access to view the Dashboard.

Finally, the example we are building would look like this:

Step 7: Create the Application and associate the Resources 

Now it is time to create the Application and associate the Resources according to the Realm roles in order to restrict access to the components by role. To generate our own Project, we will access the menu Development > My Applications.

We will have direct access to the list of projects to which we have access, either complete or only for visualization with their corresponding actions.

In this case we name the project “helsinki_project“, indicating its description and associating a logo to our Application.

Once the Application is created, we can edit it and manage various configurations, such as the User Management, where we have the option to add Platform users independently or we can also link a previously created Realm, facilitating multi-user management.

In our case, we link the previously created Realm “helsinki_realm“, where the two defined roles will appear.

Grouping of elements: The second configuration of the project will allow us to generate a collaborative system thanks to the ease of sharing elements between users in the same project. Being able to add, modify or delete elements at any time during the life of the project.

In this step we should already have created the entities, the centralized configuration file, Forms, Dashboards, etc. to be able to give permissions in the application according to the defined roles. So one by one, we will add the elements associating the corresponding permissions by the role associated to the realm.

In this example, we will have to add the visual resources, but we will also add those of configuration to create a collaborative project in the evolution of the Project, allowing the analyst to manage some Resources.

Once all the elements or resources of the Platform have been added, we will have a view of all of them and the associated permissions.

When adding some Resources, the Platform itself will add those other Resources that are associated to the main one, such as: Instances, DataSources, etc.

Web Application: Finally, to the Application we can associate an already created Web Application or generate a new one. In this case we will generate a new web app that we will call “helsinki_web”.

We will finish configuring our web application using the Git option, as we will see in the following Step 8.

Step 8: Web App Management

From the Platform we will also be able to fully manage our web application from the Dev Tools > MyWebApps menu, where we will have access to a list with all the web applications and the possibility of creating new ones from the creation wizard.

For the management of the web app, we will have two options: a direct upload of a zip file, where we have hosted the web app itself, and a second possibility for the management of the same web app from a Git repository.

In this workshop, we will follow the management through Git and we will add the repository information and the access token.

Additionally, we can also manage NPM projects, being able to configure different commands.

The following configuration shown, will allow us to launch the “build” command (npm run is added by the Platform itself) of the project and will place the final file (zip) in 'dist' (this being the default directory generated in the compilation with the project. This option enables the Platform itself not only to generate and store the zip file of the project, but also to unzip and deploy it automatically as we will see later.

Once our web app is configured, we will be able to access the Git option of the web app from the extended options in the web app list.

It will open an editor with a tree of files, which will show the repository linked to the Git project. From there we will be able to maintain the project making changes, add new files, update them and even compile and deploy the project.

Initially we can select the branch in which we want to work.

Once our branch is selected, it will load all the elements associated to it and we will be able to work on it.

This editor not only allows us to manage our Git project, adding/modifying elements, managing branches, etc., but also integrates generative AI such as the Query Tool, providing a support tool to the developer for code generation.

With access to all the resources, we will be able to modify and adapt our Web Project if necessary and we must configure our web app to host it in the Platform environment and work under the security provided by the Platform.

To do this we will modify the file named “.env.producction“ adding the corresponding information.

We will proceed to make the changes from the Platform tool, save the changes and these will be uploaded to our repository with the comments we add.

Once the file has been modified, we can compile the Web Project and it will automatically display the changes.

Finally, we could access the Web Application.

Step 9: Access to the created Web Application

After deploying the webapp, we will be able to access it through the URL exposed by the Platform in:

When starting from the Web Template, the first thing that will appear will be the Login UI, thus having a web app secured against the Platform’s Identity Manager:

If we access with the user with “manager” role, the menu will appear with two entries, one with the “helsinki_form” information Form, being this the one defined in initnavigation of the configuration file (see Step 5: Centralized Configuration File) and a second access with the Dashboard.

While, if we access with the other user with “analytics” role, in the menu we will only have a single entry, which will be the access for the dashboard visualization, being the one predefined in initnavigation in the configuration file (see Step 5: Centralized Configuration File).

In the same way, if we modify the language from the user menu, the whole system will change from its internationalization file.

Step 10: Asset Code 

Bundle generation

Initially, we will generate a zip file with all the resources that we have created, in order to be able to export to another environment or to save a backup of our project. For it, we will move to the menu of Version Control > Bundle generation.

Then, a tree will open with all the resources we have permissions for, where we will be able to select all those we have generated and want to export.

Once the general information is complete (name, description, logo, etc) we can create our zip file and then upload it to any environment.

Additionally, the Platform not only allows the generation of a Bundle through a ZIP file, but we can also deselect the "generate Zip" option and a system for uploading the project to the Git repository that we link will appear.

Once the authentication and repository information has been completed, we can create the Bundle and the Platform will automatically commit the structure to the defined branch and Project.

Restore Bundle

To import the previous Bundle or any other, we will simply download the file and, in this case, we will go to the menu Version Control > Bundle Load.

Once in this page we will click on the button "Upload ZIP" linking the Bundle ZIP previously generated and where we will leave checked the options of loading by zip and loading the resources with the current user. Later we will launch the "Import" again.

Once the file has been imported, it will indicate that the upload has been successful and we will have all the resources associated with our user.

We also have other restoration systems, such as the restoration from a Git repository. We will access this system in the same way as the previous one, unchecking the ZIP upload. Enabling, at the same time, an upload via Git repository