Introduction

This documentation applies to version 2.1.1

Kuwaiba is an enterprise-ready network inventory platform geared towards the Telecommunications industry, but easily adaptable to other domains. It was designed to not only serve as an asset repository, but also to orchestrate complex business processes such as Service Provisioning, Activation, Modification and Termination, and to greatly speed the creation and integration of OSS (as in Operation Support Systems) applications.

Kuwaiba’s architecture was designed with four principles in mind: modularity, scalability, extensibility and interoperability. In this section we will describe how all these elements play a role in the diagram above. Although initially Kuwaiba used a relational database (Oracle or Postgres), the technical team quickly realized that this was not the best way to model and store a telecommunications network, that’s why the decision of switching to a graph database was made. The Persistence Abstraction Layer makes the access to the database transparent to the rest of the application, so upper layers don’t know what kind of DBMS is being used. This layer defines a so-called Persistence API, whose reference implementation provides support for Neo4J, but support for other graph databases (or even non-graph ones too, though with a higher degree of complexity) can be added if needed. This API, defines a set of capabilities to manage inventory assets (network devices, infrastructure elements, etc) and application objects (users, reports, processes, automation, etc). On top of this layer, the Integration Layer manages the lifecycle and interactions of application modules (physical/logical connections, navigation, reporting, Outside Plant Management, external services, etc). The so-called Integration API makes the task of creating modules easy and painless. The modules access the inventory and application objects through the abstraction layer and push (and listen for) messages to the Messaging Services component, which is in charge of propagating the changes and informing the registered components of events in the system. The Integration Layer ensures the coexistence between core, open-source modules and commercial ones.

A separate component implements support for southbound interfaces, chiefly the Synchronization Framework, which is an extensible component that enables Kuwaiba to keep the inventory updated by fetching data from network devices, NMS and other information systems using a broad range of protocols, finding the differences with the information existing on the inventory, and finally conciliating the deltas according to business rules set by the customer. The synchronization process may require that (potentially) thousands or millions of devices to be queried, thus requiring to be highly scalable. The recollection process is performed by agents distributed throughout the network (o simply running on the same server depending on the scale of the operation). Integrations with new data sources can be done by creating the so-called Synchronization Providers, which implement the Synchronization API. More details about the Synchronization Framework can be found here.

The northbound interfaces allow Kuwaiba to talk to other higher-level systems, such as BSS platforms (ERPs, CRMs, etc) or OSS platforms (alarm/performance monitoring, billing, trouble ticketing, etc ) or simply to support the access from clients such as browsers, mobile or third-party clients. The load and response time requirements of both types of consumers, may make necessary to use different kinds of mechanisms to deliver the information required give the time restrictions under certain stress. To meet these needs, Kuwaiba provides so-called “regular-performance” interfaces (REST/SOAP webservices) which are more structured and implement more validations and procedures to ensure the security and integrity of the information, as well as “high-performance” interfaces, with less overhead and aimed do a lot of stuff in little time by keeping processing time to the bare minimum. At its core, Kuwaiba is a platform, that is, a piece of software that is meant for other components to be built on top of it. Kuwaiba may serve as an inventory system for other domains such as utilities, oil & gas or power transmission and distribution. It can be extended by creating domain-specific frontends which we call “Portals”, or UI-less mediation components (pieces of software that translate requirements from one domain to another).

Installation

Standalone

Requirements

Java Development Kit

JDK 11 is recommended, newer versions have not been tested and might not work. We recommend OpenJDK and it's available in most distros, however, if you are struggling to find the right version on your package repository, Several vendors offer pre-compiled builds (including Microsoft, Amazon and OpenLogic). We will use Amazon's JDK in this manual, but the instructions should apply to any other distribution. Unzip the installation package and copy it to your preferred location or install it using your package manager tools if a suitable installer is provider. This guide will assume you did the former.

The Server Application Bundle

Download the latest 2.1.x installation package from SourceForge. Let's take a look at the contents:

• data: Contains the directory structure where the database and other files are stored by default. This structure can be customized via configuration variables later. If you don't want to make changes to the default configuration, create the directory /data, copy the contents of data inside, and make sure the user running Kuwaiba has read and write permissions.
• dbs: Contains sample databases used to bootstrap the system. The database 01 is completely empty, save for the default data model. It has no containment structure, sample objects or list types. This database is recommended for those already familiar with the platform and those who are ready to run a production instance. The database 02 is no longer maintained and will be most likely removed in the future. It contains the same as the database 02 plus a basic containment structure. The database 03 is recommended for those willing to explore the features in Kuwaiba. It contains examples of several technologies, layouts, list types, validators, filters, configuration variables, topologies, views, reports and automated tasks, among many other goodies.
• kuwaiba_server_2.1.x-stable.jar: This file is the actual application. It has an embedded Tomcat server, so you don't need any other third-party software to run it. The extension of this file is .jar, but it's a regular .zip file, and you can open it with the archive manager of your preference. Inside you will find all the stylesheets and images to change the appearance of the UI.

The most important file is application.properties. It contains several configuration variables that govern the behavior of Kuwaiba as shown in the table below. You can change the values to your convenience and pack the .jar file again (most archive managers will repack the file when you save the text file).

Running the Server

The simplest method starts the server in foreground and logs in the standard output:

/path/to/java/installation/dir/bin/java -jar /path/to/kuwaiba/kuwaiba_server_2.1.x-stable.jar

The nohup command allows you to launch the server so that it is not terminated once you logout from the terminal. In this case, unless you redirect the output, the application will log to /home/<user>/nohup.out:

nohup /path/to/java/installation/dir/bin/java -jar kuwaiba_server_2.1-stable.jar&

In production environments it is highly recommended to create a special, restricted user to run the server. To run the server as that user, you can use the following command (application messages will be logged in /home/YOURUSER/nohup.out):

sudo runuser -u YOURUSER -- nohup /path/to/java/installation/dir/bin/java -jar kuwaiba_server_2.1-stable.jar&

Appendix B discusses how to configure the server to start on boot.

Deploying on an Existing Application Server

Requirements

Process Description

1. After you have installed Apache Tomcat in the requested version, generate the .war file of the project and place it in the /webapps folder inside tomcat. 1.1. If you want to set a specific path for the .war file when deploying. You can do this by modifying the server.xml file as follows. It is important to set the autoDeploy and deployOnStartup attributes to false. Automatic deployment allows for easier management but also makes it easier for an attacker to deploy a malicious application. Only the contexts defined in server.xml will be deployed and any changes will require a restart of Tomcat.

   <Host name="localhost"  appBase="webapps"
      unpackWARs="true" autoDeploy="false" deployOnStartup="false">
      <Context path="/kuwaiba" docBase="kuwaiba.war"/>
      <Context path="" docBase="sa.war"/>
   
      <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
            prefix="localhost_access_log" suffix=".txt"
            pattern="%h %l %u %t &quot;%r&quot; %s %b" />
   </Host>
   

2. Remove the default tomcat applications as these are unsafe applications from /tomcat/webapps.

3. If you need to create a management user, you can edit the tomcat-users.xml file, usually located in tomcat/conf. Note: It is important to limit access to users. Since some roles allow modifications to the deployed files or tomcat configurations. In case you find it necessary to create a user, make sure that their credentials are secure.

<role rolename="manager-status"/>
<role rolename="manager-jmx"/>
<role rolename="manager-script"/>
<user username="admin" password="admin123" roles="manager-status"/>

4. After the above settings, you can start tomcat manually ./opt/tomcat/bin/startup.sh

Configure Tomcat as a Startup Task

1. To configure tomcat as a startup task, you create a systemd service file in /etc/systemd/system/tomcat.service:

Note: It is recommended to run Tomcat with a specific user for security reasons.

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

Environment=JAVA_HOME=/route/java
Environment=CATALINA_HOME=/opt/tomcat/
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

User=tomcat user
Group=tomcat group
Restart=always

[Install]
WantedBy=multi-user.target

1. After creating the service file, reload the systemd daemon so that it recognizes the new service:

sudo systemctl daemon-reload

Installation of Self-signed Certificates in Tomcat

1. Modify the server.xml file as follows to use the self-signed certificate

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/certificate.jks"
        certificateKeystorePassword="certificate password"
        type="RSA" />
    </SSLHostConfig>
</Connector>

When restarting Tomcat and accessing https://localhost:8443/kuwaiba the browser will warn you that the certificate is untrusted, and you can then see the kuwaiba interface.

Configure User Permissions

If you run kuwaiba from apache tomcat with a specific tomcat user. You have to give read and write permissions to the tomcat user to some paths designated by kuwaiba.

• /opt/tomcat/*
• /data/db
• /data/processEngine/
• /data/files/attachments
• /data/img/backgrounds

Tomcat is added to your user's group. To allow your user access to the logs and files generated at runtime by the user tomcat.

sudo usermod -aG groupName tomcat

Then change the permissions so that users belonging to the same group can access the specified files.

sudo chmod -R g+rwx /data

In this way, Kuwaiba will be deployed to the address where the Tomcat server is running (port 8080, by default), as follows

Docker

Pulling the Image

For nightly builds (which are not really generated nightly, but at least once a week), use:

docker pull neotropic/kuwaiba:v2.1-nightly

Deployment

Starting the Container

The container exposes 2 ports: 8080 (application) and 8081 (SOAP-based web service). You can use the following command to run the container and map those ports to the host machine.

docker run -dp 8080-8081:8080-8081 --name kuwaiba-server neotropic/kuwaiba:v2.1-nightly

Now it's possible to access the application by going to http://localhost:8080/kuwaiba⁠, or to access the SOAP-based web service API WSDL at http://localhost:8081/kuwaiba/KuwaibaService?wsdl⁠

Using a Custom Database

To avoid losing information across containers when you update an image, you can mount a custom database (thus overriding the stock one) located in your host machine and reuse it in different containers:

docker run -dp 8080-8081:8080-8081 --name kuwaiba-server -v /path/to/your/custom/database:/data/db/kuwaiba.db neotropic/kuwaiba:v2.1-nightly

Make sure the user used to run the container has write access on /path/to/your/custom/database. You can download empty or sample databases from the Sourceforge repository⁠

Additional Information

• Default Server Credentials: admin/kuwaiba. There are several other users used to showcase the Process Manager capabilities in database 03. You can check them out in the User Manager module. Their passwords are also kuwaiba.
• Data Directory: /data
• Application Directory: /opt/programs

Generate Your Own Image

• Fetch the Dockerfile from the project repository⁠ on SourceForge. Alternatively, you can also download the docker compose file from the same repository⁠
• Customize the Dockerfile depending on your needs.
• Build the image with:

docker build -t REPOSITORY_NAME:TAG .

where REPOSITORY_NAME is the name of the repository where the image will be placed and TAG is the tag for such container. Instead, you can also use the docker compose file like this:

docker compose -f kuwaiba.yaml up

Appendix A. Securing the Server

• Make sure the user running the server only has access to the data directories and has as little other privileges as possible. Also, disable its shell access as instructed in the installation section.
• Install a firewall (ufw works pretty well) and restrict access to non-necessary ports.
• Disable SSH user/password authentication and favor key-based authentication.

Appendix B. Starting the Server on Boot

The following instructions apply to systemd-enabled distros, particularly Debian 11+. This is not a guide on how to create services in systemd, just a sample of what most production scenarios would require to run Kuwaiba on boot.

1. Create a file in /etc/systemd/system/ named kuwaiba.service

2. Paste the following lines inside:

   [Unit]
   Description= Kuwaiba Open Network Inventory
   After=network.target
   
   [Service]
   User=kuwaiba
   ExecStart=nohup /usr/bin/java -jar /path/file/kuwaiba_server_2.1.x-stable.jar
   SuccessExitStatus=143
   TimeoutStopSec=10
   Restart=on-failure
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target
   

   Note

   Make sure that the User field is set to the user that will be used to run the server. Also, double-check the ExecStart command syntax before saving.

3. Reload the service definitions

   sudo systemctl daemon-reload
   

4. Start and enable the service

   sudo systemctl start program-name
   sudo systemctl enable program-name
   

5. Verify the service status

   sudo systemctl status program-name 
   

Schedule Automatic Database Backup

The instructions below show an example of how to perform automatic backups of the Kuwaiba database. It applies to Linux distributions, specifically Debian 11.

1. Create a file named kuwaiba_database_backup.sh

2. Copy the following lines inside.

   #!/bin/bash
   
   # Define the paths
   NEO4J_DIR="/data/db/kuwaiba.db"
   BACKUP_DIR="/data/backups/"
   TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
   BACKUP_PATH="${BACKUP_DIR}backup-${TIMESTAMP}_kuwaiba.db.tar.gz"
   
   # Ensure the backup directory exists
   mkdir -p "$BACKUP_DIR"
   
   # Create a tarball of the Neo4j data directory
   tar -czvf "$BACKUP_PATH" "$NEO4J_DIR"
   
   # Optional: Remove backups older than 7 days
   find "$BACKUP_DIR" -type f -name "*.tar.gz" -mtime +7 -exec rm {} \;
   

   This script creates a backup of the Kuwaiba database and saves it in BACKUP_DIR. In addition, it deletes backups that have a creation date older than 7 days.

3. Give execution permissions to the above script.

   chmod +x /path/to/your/bash-script.sh
   

4. Schedule the task in Linux. To do this, use crontab.

   crontab -e
   

   0 0 * * * /path/to/your/bash-script.sh
   

Appendix C. Using a Reverse Proxy

Adding a reverse proxy with Nginx in front of Kuwaiba can provide several benefits:

1. Redirecting the traffic from standard HTTP/HTTPS ports 80/443 to 8080 allows a non-privileged user to run Kuwaiba
2. Security: Nginx can help protect Kuwaiba by hiding its internal structure and adding an additional layer of security.
3. Load Balancing: If you have multiple instances of Kuwaiba, Nginx can distribute the load among them.

This configuration is for Debian, but it should work for any derivative distribution like Ubuntu.

1. Install Nginx:

   Update you repository index, then install Nginx:

     sudo apt update
   

     sudo apt install nginx
   

   Note

   This step is optional. If applicable, allow access to Nginx through your firewall using the following command:

   sudo ufw allow 'Nginx HTTP'

   Verify that Nginx is running:

      systemctl status nginx
   

     Output
       ● nginx.service - A high performance web server and a reverse proxy server
           Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
           Active: active (running) since Mon 2022-08-29 06:52:46 UTC; 39min ago
           Docs: man:nginx(8)
       Main PID: 9919 (nginx)
           Tasks: 2 (limit: 2327)
           Memory: 2.9M
               CPU: 50ms
           CGroup: /system.slice/nginx.service
                   ├─9919 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
                   └─9920 "nginx: worker process   
   
   

2. Edit your Server Block:

   Create and open a new Nginx configuration file using nano or your preferred text editor:

       sudo nano /etc/nginx/sites-available/kuwaiba
   

   Insert the following text into your new file:

        server {
            listen 80;
            listen [::]:80;
   
            server_name localhost; # Replace 'localhost' with your FQDN if available
                
            location / {
                proxy_pass http://YOUR_IP_ADDRESS:PORT; # Replace PORT with the port Kuwaiba is running on (default is 8080, but could be different if the default settings were changed)
                include proxy_params;
            }
        }
   

   Next, enable this configuration file by creating a link from it to the sites-enabled directory that Nginx reads at startup:

       sudo ln -s /etc/nginx/sites-available/kuwaiba /etc/nginx/sites-enabled/
   

   You can now test your configuration file for syntax errors:

       sudo nginx -t
   

   With no problems reported, restart Nginx to apply your changes:

       sudo systemctl restart nginx
   

3. Run Kuwaiba and open your browser:

        localhost/kuwaiba
   

Appendix D. Accessing the Database

The reference implementation of the Persistence API (the layer in Kuwaiba that abstracts the access to the database, so changing the DMBS is transparent to upper layers) in Kuwaiba 2.1.1 uses Neo4J 3.5.5. You can make your own implementation to support other backends, and the project actually intends to support other graph databases in the mid-term. In this reference implementation, Neo4J works in embedded mode, which means that a mini database server runs on the same virtual machine as the application. This provides important performance improvements, but somehow limits the scalability of the system, so the current development version of Kuwaiba (2.5) will drop its support in favor of a more scalable serve mode. If you want to access the database directly, you can only do it from the same machine the server is running, as external connections are refused in embedded mode. This can be fixed by using an SSH tunnel, as we will see later. Having said that, we will review the procedure to connect the official Neo4J browser to the database of a running instance of Kuwaiba.

The Neo4J server includes a javascript client that works just fine and never fails to connect. We will extract it from the standard installer and use it on a regular browser:

1. Download Neo4J 3.5. Neo Technologies goes through great lengths to hide the open source versions behind several "Get Our Cloud/Enterprise Products" pages. The actual download page is this one. Neo Technologies also remove older versions of their products (Kuwaiba 2.5 uses Neo4J 4.4). Thankfully, the download link is composed by the name of the version, so we can infer it from the other downloads.

2. Inside the file, go to lib and search for the file neo4j-browser-3.2.18.jar. Jar are simple .zip files with another extension. Unzip that file.

3. The client application is inside a folder called browser as shown in the picture below. Open index.html with your preferred browser.

4. This will open a log in page. Use localhost:6677 in the Connect URL field and leave the password empty.

5. Verify it worked if the left panel shows all the labels and relationship types. You are ready to start executing cypher queries in the text field at the top.

Note

You can use a copy of the Kuwaiba database and use it on an actual N4J server and run tests without disturbing the inventory application.

Appendix E. Generating and configuring a self-signed SSL certificate

Digital certificates are an essential part of internet security. They function as electronic identifications that guarantee the authenticity and security of communications on the network. These certificates, issued by a Certificate Authority (CA), contain public and private keys used to encrypt and decrypt data, ensuring that information exchanged between a server and a client cannot be intercepted or altered.

In the context of web applications, digital certificates allow secure connections to be established using the HTTPS (HyperText Transfer Protocol Secure) protocol. This ensures that data transmitted between the user's browser and the web server is protected from malicious attacks. To configure HTTPS on a web server, you need to implement an SSL (Secure Sockets Layer) certificate, which is stored in a keystore, a secure container for keys and certificates.

In addition to certificates issued by a CA, there are also self-signed certificates. These digital certificates are signed by the same entity that creates them, rather than by a CA, which will be the type we are going to implement.

1. Create the Certificate Authority (CA) Private Key:

   Create a private key in the desired location. In this example, it was created in the root directory within a folder named certificate:

       mkdir certificate
       cd certificate
   

      openssl genrsa -out CA.key -des3 2040
   

   Enter a password for each time you export or sign a certificate:

       ● Output:
           Enter PEM pass phrase:
           Verifying - Enter PEM pass phrase:
   

   Note

   Whenever you are asked for a password, use the same password to avoid confusion.

2. Export the certificate as a PEM format:

      openssl req -x509 -sha256 -new -nodes -days 3650 -key CA.key  -out CA.pem
   

   Enter your password and the requested information:

   Note

   The requested fields can be left empty

       ● Output:
           Enter pass phrase for CA.key:
               
           You are about to be asked to enter information that will be incorporated
           into your certificate request.
           What you are about to enter is what is called a Distinguished Name or a DN.
           There are quite a few fields but you can leave some blank
           For some fields there will be a default value,
           If you enter '.', the field will be left blank.
           -----
           Country Name (2 letter code) [AU]:CO
           State or Province Name (full name) [Some-State]:POPAYAN
           Locality Name (eg, city) []:POPAYAN
           Organization Name (eg, company) [Internet Widgits Pty Ltd]:Neotropic SAS 
           Organizational Unit Name (eg, section) []:TI Department                                    
           Common Name (e.g. server FQDN or YOUR name) []:neotropic.co
           Email Address []:
   

3. Create and Sign a Domain Certificate:

   Create a Directory for the Domain inside folder certificate:

       mkdir neotropic.co
       cd neotropic.co
   

   Generate a Private Key for the Domain:

       openssl genrsa -out neotropic.co.key -des3 2048
   

   Enter a password:

       ● Output:
           Enter PEM pass phrase:
           Verifying - Enter PEM pass phrase:
   

   Create an extension configuration file:

       touch neotropic.co.ext
   

   Edit neotropic.co.ext with your preferred editor and add the following content:

       authorityKeyIdentifier = keyid,issuer
       basicConstraints = CA:FALSE
       keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
       subjectAltName = @alt_names
       
       [alt_names]
       DNS.1 = neotropic.co
       IP.1 = 192.168.0.11
   

   Generate a Certificate Signing Request (CSR):

       openssl req -new -key neotropic.co.key -out neotropic.co.csr
   

   Enter your password and the requested information:

   Note

   The requested fields can be left empty except for (A challenge password [ ]:YOUR_PASSWORD)

       ● Output:
           Enter pass phrase for neotropic.co.key:
           You are about to be asked to enter information that will be incorporated
           into your certificate request.
           What you are about to enter is what is called a Distinguished Name or a DN.
           There are quite a few fields but you can leave some blank
           For some fields there will be a default value,
           If you enter '.', the field will be left blank.
           -----
           Country Name (2 letter code) [AU]:
           State or Province Name (full name) [Some-State]:
           Locality Name (eg, city) []:
           Organization Name (eg, company) [Internet Widgits Pty Ltd]:
           Organizational Unit Name (eg, section) []:
           Common Name (e.g. server FQDN or YOUR name) []:
           Email Address []:
           
           Please enter the following 'extra' attributes
           to be sent with your certificate request
           A challenge password []:neotropic
           An optional company name []:
   

   Sign the certificate request (neotropic.co.csr) using the CA certificate (CA.pem) and private key (CA.key). This will generate a new certificate (neotropic.co.crt):

       openssl x509 -req -in neotropic.co.csr -CA ../CA.pem -CAkey ../CA.key  -CAcreateserial  -days 3650 -sha256 -extfile neotropic.co.ext -out neotropic.co.crt
   

   Enter a password:

       ● Output:
           Certificate request self-signature ok
           subject=C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
           Enter pass phrase for ../CA.key:
   
   

4. Convert to PKCS12 Format:

   Export the certificate and private key to PKCS12 format:

       openssl  pkcs12 -export -in neotropic.co.crt -inkey neotropic.co.key -out neotropic.co.p12 -name default
   

   Enter your password:

       ● Output:
           Enter pass phrase for neotropic.co.key:
           Enter Export Password:
           Verifying - Enter Export Password:
   

5. Update kuwaiba application properties:

   Change the application port in application properties:

       server.port=8443
   

   Add the following content to your application properties:

       server.ssl.key-store=file:/route/to/your/p12/file/neotropic.co.p12
       server.ssl.key-store-password=YOUR_PASSWORD #Password that you wrote in " A challenge password [ ] "
       server.ssl.key-store-type=PKCS12
       server.ssl.client-auth=none
   

6. Run Kuwaiba and open your browser:

       https://localhost:8443/kuwaiba/
   

   Click on the following button (you can also view the url with https):

   

   Click on (Connection not secure) and then on (More information) and you will see the following information:

   Click on (View certificate):

   

   Your certificate:

   

Appendix F. Configuring the Max Attachment Size

An attachment is a file directly associated with an inventory object or a list-type item (which in turn will be linked to several objects e.g. a router installation manual file attached to a list type item representing its model will be available to all routers of said model). These files can be documents, images or relevant settings, and can be downloaded, added or deleted at any moment.

To ensure that the storage endpoint used to store the files won't be abused or overwhelmed, the attachments size limit is capped and configurable.

Note

The value is specified in MB, and you only need to adjust this value as needed. The default value is 10 MB.

Open your application.properties file and modify the following lines:

1. Set the max file size at application server level. This property sets the maximum size for individual files that can be uploaded.

      spring.servlet.multipart.max-file-size=10MB
   

2. Set the max (HTTP) request size at application server level. This property sets the maximum size for the entire multipart request.

      spring.servlet.multipart.max-request-size=10MB
   

   Note

   Maximum File Size and Maximum Request Size should be configured in accordance with the Maximum Attachment Size, as explained in the next step.

3. Set the max file size at application level. This property sets the maximum allowed size for attachments within the application. This restriction will apply to all Persistence API calls related to attachment handling, regardless if they are consumed through the northbound interfaces or automation procedures (such as tasks in the Task Manager).

      bem.max-attachment-size=10