Application configuration

[tomg-formpak]

We are using SaaS Boost version [v2.0.0-rc1], we have configured the application, service and container settings. My concerns are :

1. To upload a database file for initial datasets, what is the format/database backup command that I need to use to get the file in the right format if I need to take a backup from our current database (SQL server or DB2 or PostgreSQL pg_dump)?
2. How can I add an environmental variable or a parameter like a license key which is generated using an external application to use at the time of tenant onboarding? This will be used at the application run-time for each tenant to restrict the specific functionalities within the application.

Please advise me on this. Thank you.

[brtrvn]

@tomg-formpak thanks for the questions

Remember that the database bootstrap script is not intended to be a migration tool. It's just meant to create an initial blank schema so that your application can connect to a functional database when it first starts up. Many server side technologies have a similar functionality built into them, but we wanted to provide a mechanism for customers who are not using such tools already or want more control over how their database schema come to life. You can of course include static "lookup" data if your "empty" database should come to life with that data available.

The format that SaaS Boost expects for the database bootstrap file is UTF-8 encoded without a BOM. SQL statements should be terminated by a semicolon followed by a newline (either \r\n or \n). The SQL statements themselves need to be a string that the JDBC driver for the chosen database can execute. Comments are allowed as long as you use standard SQL single line comments that begin the line with --.

For example, the following is a completely valid MS SQL Server statement:

-- Create the category table if it doesn't exist
IF OBJECT_ID('category', 'U') IS NULL
BEGIN
    CREATE TABLE category (
        category_id INT PRIMARY KEY IDENTITY(1, 1),
        category VARCHAR(255) NOT NULL UNIQUE CHECK (category <> '')
    )
END;

That entire block will be sent as a single statement to SQL Server and will execute properly.

The PostgreSQL equivalent of that statement is:

-- Create the category table if it doesn't exist
CREATE TABLE IF NOT EXISTS category (
	category_id SERIAL PRIMARY KEY,
	category VARCHAR(255) NOT NULL UNIQUE CHECK (category <> '')
);

Note that specialized commands such as the Postgres COPY command is not supported by default with the JDBC driver and will not execute properly as part of SaaS Boost's bootstrap process. Therefore, if you use a tool such as pg_dump make sure you use the --inserts switch.

If you use SQL Server Management Studio generate scripts command, it will encode the text file as UTF-16 LE by default. There is a way to select the file encoding when you save the output.

IBM DB2 has an export command with lots of options, but I haven't used DB2 in years. Someone else from the community might be able to jump in. Note that DB2 is not currently a supported engine on Amazon RDS, so you'd need to be sure that the output is standard ANSI SQL or otherwise compatible with MySQL/MariaDB, PostgreSQL, or SQL Server.

---

As for your second question I can think of a few options:

• You could leverage the config file upload feature during tenant onboarding. That file will be hosted in a secured S3 bucket and made available to the container. Your code would then have to download the file from S3 and parse it for the API key.
• There is a (currently undocumented) attributes property for tenants. It is a simple Map/Dictionary collection that can contain any key->value pair as long as the key and the value are strings (you could of course get creative an use an escaped JSON string to collect more advanced values). The attributes map is not currently exposed in the onboarding UI, but it is supported by the API. If you go this route, your application would need to query the Tenant Service API using the TENANT_ID environment variable to retrieve the information at runtime.
• A possible "think outside the box" solution would be to align the API key/feature switch functionality with tiers. If you have a limited set of possible on/off feature flags that these API keys represent, you could make a tier for each option and onboard the tenants into the proper tier.
• Of course you can also contribute a different solution as a pull request and we can work together on how best to incorporate this feature.