One of the top level properties in the sgtech_config.json config file is https_only. When this value is set to true (the default), Oracle Spatial Studio will actively monitor all incoming requests and only allow requests that were made using SSL. Normal http:// requests will be denied.

Thus, if you tried to access the Spatial Studio application using an http:// URL such as http://localhost:8080/spatialstudio, and if the value of https_only is set to true, then you will not be able to log in. In fact, you will not even see the login page itself, because none of the page resources will be accessible by your browser. Similarly, all RESTful requests will be blocked unless accessed using HTTPS.

If you wish to enable http access, change the value of https_only to false, and then restart the Spatial Studio application or the JavaEE container where Spatial Studio is deployed.

Please note that enabling http access also requires the following:

• http is enabled in the JaveEE container.

  If you are running Spatial Studio Quick Start, then see Installing and Configuring the Spatial Studio Quick Start which explains how to enable HTTP access in the Jetty container.

• The http port is opened in the host OS firewall.

Spatial Studio must have access to a set of metadata tables, such as SGTECH_OBJECT. These tables are collectively considered the repository of the Spatial Studio application. The database schema that hosts these tables is considered the metadata schema or repository schema of Spatial Studio.

Spatial Studio must be able to establish a connection to this metadata schema as the first step during startup, when the connection details are found in the sgtech_config.json file in the metadata_schema section.

In an emergency situation, you can also manually edit this section to change or correct the connection details. However, be careful whenever editing this file, because any syntax error can cause Spatial Studio to stop working or fail to restart.

When you manually enter the repository schema connection details in the sgtech_config.json file (in the metadata_schema section), you must first specify whether CONTAINER or SPATAL_STUDIO is managing the physical JDBC connections:

"metadata_schema" : {
    "connection_manager": "CONTAINER"
}

Or

"metadata_schema" : {
    "connection_manager": "SPATIAL_STUDIO"
}

When connection_manager is set to CONTAINER, it means the JDBC connections to the Spatial Studio’s repository schema are managed through a Java EE data source already created in Jetty (for Quick Start) or WebLogic Server. For example, if there is a data source named jdbc/studioMetadata in the WLS domain, and if you want Studio to connect to the target schema using this data source, the relevant section in sgtech_config.json should look like this:

"metadata_schema" {
"connection_manager" : "CONTAINER",
"container_managed":{
        "jndi_datasource_name" : "jdbc/studioMetadata"
}
}

However, if you want Spatial Studio to manage the physical connections to its metadata schema, set connection_manager to SPATIAL_STUDIO, and supply the full set of JDBC connection details, which vary depending on whether the schema resides in an Oracle Autonomous database (which requires a database Wallet for establishing connections), or a regular database on-premises. You can check the inline comments inside the sgtech_config.json file for more details, but it is best if you simply log onto Spatial Studio as an admin user and then interactively supply the connection details for the repository schema. Such details will then be automatically saved in sgtech_config.json after Spatial Studio verifies the connection.

During run time as users create connections, datasets, and projects, Spatial Studio is creating, modifying, and storing a large amount of metadata (sometimes called Spatial Studio’s "domain objects"), such as the definition of a dataset and all of its columns, or the definition of a project including the full layout of all of its visualizations.

All the metadata objects are permanently stored in the metadata table SGTECH_OBJECT, but if the database must be accessed frequently (such as every time you open a project or view the properties of a dataset), performance may suffer. If this occurs, the solution is to cache frequently accessed copies of such metadata objects in memory.

The cache section of the sgtech_config.json file lets you specify whether to enable such an in-memory cache of metadata objects. If the cache is enabled, then you can further specify how many such objects can be cached and for how long. A general rule is that max_size (the maximum number of metadata objects to be cached) should be no less than 1000, but probably should not exceed 10000 unless you have a very large amount of memory allocated to Spatial Studio.

Spatial Studio 22.1 allows you to import different configuration files into the main sgtech_config.json configuration file.

The following describes the workflow for handling multiple configuration files:

Figure 2-5 Workflow to Handle Multiple Configuration Files

Description of "Figure 2-5 Workflow to Handle Multiple Configuration Files"

1. At startup, Spatial Studio loads the primary configuration file, sgtech_config.json.

   All the settings defined in sgtech_config.json are used as the base settings.

2. If the sgtech_config.json file contains the imports directive, then it loads the import files in the order (top to bottom) in which they are declared.

   For each loaded import file, the system reads and appends the settings to the base settings.

3. Once the base settings are all read in, the system encrypts any sensitive items and saves them back to their corresponding file.
4. Spatial Studio resumes loading the rest of the system.

"imports" : {
   "<import_name>" : {
      "module" : "<import_file_path>",
      "description" : "<import_description>"
   }
}

{
  "metadata_schema" : {
    "connection_manager" : "CONTAINER",
    "container_managed" : {
      ...
    },
  }
}

{
  "jobs" : {
    "init_threads_count" : 45
  }
}

{
  "version" : "22.1.0",
  "work_dir" : "",
  "https_only" : true,
  "master_seed" : "<somerandommasterseed>",
  "logging" : {
    "level" : "INFO"
  },
  "imports" : {
    "jobs" : {
      "module" : "extras/sgtech_config.jobs.json"
    },
    "db" : {
      "module" : "extras/sgtech_config.dbsettings.json",
      "description" : "Database settings optimized for clustering"
    }
  }
}

If the Spatial Studio Repository Schema Password has been changed, you must update the sgtech_config.json configuration file, as follows:

1. Make a backup copy of the file. For example, copy ~/.sgtech/sgtech_config.json to ~/.sgtech/sgtech_config.json_backup.
2. On the Spatial Studio compute node, edit the file ~/.sgtech/sgtech_config.json.
3. In the metadata_schema section, update database_password to the desired value.
4. Save the file and then restart the Spatial Studio deployment. To restart if you are using the Quick Start kit, see the README file for the Quick Start; to restart if this is a WebLogic Server deployment, use the WebLogic Server console.
5. Open the Spatial Studio application. You should be able to log in.

You will still have all the artifacts you had created, including other (non-repository) connections, which you can edit as needed.