Appian Cloud Database Administration

Overview

Appian allows you to configure and connect to your own supported relational databases. However, maintaining your own database requires certain expertise, which isn't desirable for all organizations. The Appian Cloud database is pre-configured so that you can focus on building low-code applications without any database set up.

This article provides guidance on how to use the database provided with your Appian Cloud environment.

Transitioning from MySQL to MariaDB

Your Appian Cloud database is either a MySQL or MariaDB database server. To determine the database version, run a SELECT version() query in phpMyAdmin.

The default Appian Cloud database used to be MySQL. Appian has since transitioned to MariaDB as the default database. If you have not transitioned to MariaDB, refer to the MariaDB upgrade guide for more details.

MySQL and MariaDB are widely adopted solutions with abundant online documentation. Because of this, Appian Technical Support does not provide general assistance or training for using these databases.

Accessing the Appian Cloud database

The interface used for the Appian Cloud database is phpMyAdmin. phpMyAdmin is an open source tool written in PHP, intended for use with MySQL and MariaDB.

Depending on if a user is a database administrator, editor, or viewer, they will have different access to the schemas in the database. See system groups to learn more about various database roles.

phpMyAdmin is a widely adopted solution with abundant online documentation. Because of this, Appian Technical Support does not provide general assistance or training for using phpMyAdmin.

To access the relational database for your Appian Cloud site:

  1. In your Appian environment, go to the navigation menu.
  2. For database administrators, choose Cloud Database.
  3. For database viewers and editors, hover over Cloud Database and choose a schema. Only schemas that you have access to display.

cloud_schema_view.png

The phpMyAdmin interface opens. Database administrators see all schemas in phpMyAdmin. Database viewers and editors see the specific schema they clicked, along with the default Appian schema.

To help distinguish between the phpMyAdmin interfaces for different environments, the phpMyAdmin header has a different default color and label for development, testing, staging, and production environments. If you want to change this label or color, open a support case.

Using schemas to configure access to data

Information in databases is often sensitive. While developers need access to certain information, it may be unnecessary to grant them access to all data in a database. For example, a developer who is only working on applications for HR wouldn't need access to data that is specific to Finance.

In your Appian cloud database, you can use schemas to control access to certain data. All Appian Cloud databases ship with a default "Appian" schema which has broad access. However, database administrators can create additional schemas and use system groups and object security to secure access to them.

schemas

This section describes best practices for creating schemas, how to grant access to schemas, and how to create schemas.

You can only create schemas if your Appian Cloud database uses MariaDB.

Best practices for creating additional schemas

The majority of your data should be stored in the default "Appian" schema. We recommend that you only create additional schemas when your applications need data segregation and isolation.

We also recommend that when you create tables for an application, you only use one schema for that application in addition to the default "Appian" schema. If there are tables that are common to applications in your environment that use different data sources, create those tables in the "Appian" schema. For example, an Employee table that needs to be used in both Finance and HR applications should be created in the "Appian" schema.

We do not recommend migrating data from existing schemas into new schemas. We recommend only creating schemas for new applications.

Granting access to schemas

Access to schemas is granted through system groups and the object security for the data source connected system of a schema.

System groups

System groups determine what users can do in the Appian Cloud database through phpMyAdmin.

Putting a user in the Database Administrators, Database Editors, or Database Viewers system group will give them the access assigned to that group in phpMyAdmin. See User Roles for more information on what access users in these groups have.

Object security

While the type of phpMyAdmin access a user gets is determined by which system group they are in, the schemas they have access to are determined by object security. In order to give users access to a certain schema, you must give them at least viewer permission on the data source connected system object for the schema.

For example, if you want to give editor access to an HRData schema in phpMyAdmin, you would first put the user in the Database Editors group. But they wouldn't have access to the HRData schema until you give them viewer permission on the HRData data source connected system object.

Users in the Database Administrators group have access to all schemas, whether or not they are given access to the data source connected system object for the schema.

Configuring access to schemas

To grant different access in phpMyAdmin to different types of users for additional schemas, do the following:

  • To grant Administrator access to all schemas, put the user in the Database Administrators system group.
  • To grant Editor access to the default "Appian" schema, put the user in the Database Editors system group.
  • To grant Viewer access to the default "Appian" schema, put the user in the Database Viewers system group.
  • To grant Editor access to additional schemas, put the user in the Database Editors system group and give the user at least Viewer permission on the data source connected system object for the schema.
  • To grant Viewer access to additional schemas, put the user in the Database Viewers system group and give the user at least Viewer permission on the data source connected system object for the schema.

The Enhanced Data Pipeline allows access to the new schemas. To request access to these schemas, you will need to open a support case.

Creating new schemas

To create a new schema:

  1. Create separate schemas for each application or suite of applications that you want to secure using the AppianProcess.createNewSchema() stored procedure.
  2. Copy the credentials and connection URL.
  3. Create a MariaDB Data Source connected system for each schema using the credentials.
  4. For each connected system object, give at least viewer permissions to the users that you want to give schema access to.
  5. To allow users to make changes to the database through phpMyAdmin, put them in the Database Editors group. To give users read-only permissions in phpMyAdmin, put them in the Database Viewers group.

By default, you can create up to fifty schemas in your environment.

The credentials created by the stored procedure can only be used to connect to the data source from Appian. The password is encoded and can only be decoded by the application. Therefore, these credentials cannot be used to connect to the database from any other client.

Before deploying, create any additional Appian Cloud database schemas in the target environment

After you create a new schema, before deploying the associated data source connected system, manually create the schema in the target environment. See Data Source Connected System for more information on deploying data sources.

Built-in stored procedures

The following stored procedures are available in the Appian Cloud database:

AppianProcess.getMyProcessList()

This stored procedure produces a list of running threads started by the user executing the stored procedure. A problematic long-running query can be identified and killed using the information generated.

Required role: Database Administrator, Database Editor, or Database Viewer

Inputs: None

Example syntax: call AppianProcess.getMyProcessList()

AppianProcess.getFullProcessList()

This stored procedure produces a list of running threads started by any database user in your environment. A problematic long-running query can be identified and killed using the information generated.

Required role: Database Administrator

Inputs: None

Example syntax: call AppianProcess.getFullProcessList()

AppianProcess.killProcess()

This stored procedure allows database administrator to kill any thread started by any database user in your environment. A problematic long-running query can be killed using this stored procedure.

Required role: Database Administrator

Inputs: Thread ID

Example syntax: call AppianProcess.killProcess(6342)

AppianProcess.metadataLocks()

This stored procedure shows data about current locks in the database. This information can be used to identify the exact process that is locking a database object in order to take any required action.

Required role: Database Administrator, Database Editor, or Database Viewer

Inputs: None

Example syntax: call AppianProcess.metadataLocks()

AppianProcess.viewRoutineDefinition()

This stored procedure outputs the definition of a procedure or function that the database user is not the DEFINER for.

By default in phpMyAdmin, if a routine was created by a different database user, database editors might not be able to view the definition of a stored procedure or a function. if you have access to the schema in which the routine exists, this stored procedure can be used to retrieve the definition of the routine. You can then proceed to update or recreate the routine as required.

Required role: Database Administrator or Database Editor

Inputs:

  • Whether it is a 'procedure' or 'function'
  • Schema name
  • Routine name

Example syntax: call AppianProcess.viewRoutineDefinition('procedure','InventoryApp','GetItems')

AppianProcess.createNewSchema()

This stored procedure creates a schema. It outputs the required credentials that you can use to create a data source connected system for the schema that was created. Copy the credentials immediately after they are displayed and save them for use in your application.

If you forget to copy the credentials and navigate away from the screen, use the AppianProcess.updateSchemaPassword() stored procedure to create new credentials. This creates new credentials which you may need to update in the data source connected system.

Required role: Database Administrator

Inputs: Schema name

Example syntax: call AppianProcess.createNewSchema('InventoryApp')

AppianProcess.dropSchema()

This stored procedure drops a schema.

Required role: Database Administrator

Inputs: Schema name

Example syntax: call AppianProcess.dropSchema('InventoryApp')

AppianProcess.updateSchemaPassword()

This stored procedure updates the password for the database user of the schema. The updated password is output along with the other credentials required for the data source connection.

Required role: Database Administrator

Inputs: Schema name

Example syntax: call AppianProcess.updateSchemaPassword('InventoryApp')

AppianProcess.rotateEncryptionKey()

This stored procedure rotates the data encryption key (DEK) that is used for encryption of database tables. To change all the keys, use -1 for the input. If tables were created with specific key IDs, to rotate that specific key use the key ID for the input.

Required role: Database Administrator

Inputs: -1 or specific Key ID

Example syntax: call AppianProcess.rotateEncryptionKey(-1)

Best practices

Use Appian features to manage your Appian Cloud database

You can use phpMyAdmin for debugging or advanced database manipulation when necessary. However, it is a best practice to use Appian applications to change tables or data in the Appian Cloud database.

For example, you can execute database scripts using compare and deploy. You can also create tables by generating them from custom data types.

Making these changes through Appian means that your database will remain compatible with newer versions of Appian.

Follow industry and Appian best practices

Appian strongly recommends following industry best practices to manage the data stored in the Appian Cloud database.

These include but are not limited to using:

  • A normalized schema.
  • Proper indexes on the data.
  • Optimized queries and views.
  • Database performance testing in lower environments.

When designing and using your database, we recommend that you follow the best practices outlined in Relational Database Guidance.

Properly design the schema to avoid decreased query performance

Even though there may be no predefined limits (besides disk) to the amount of process data that can be stored in the Appian Cloud database, it is important to keep in mind that you might experience decreased query performance as disk footprint increases, unless you properly design the schema.

To help analyze the performance of the database, use the following tables in the Appian Cloud database performance schema:

  • performance_schema.events_statements_history
  • performance_schema.events_statements_current
  • performance_schema.events_statements_history_long
  • performance_schema.events_stages_history
  • performance_schema.events_stages_current
  • performance_schema.events_stages_history_long
  • performance_schema.events_statements_summary_by_digest
  • performance_schema.table_io_waits_summary_by_table
  • performance_schema.table_io_waits_summary_by_index_usage

Note that Appian Support doesn't help interpret or make use of the information in these tables.

Do not use the DEFINER clause in SQL scripts when creating objects

When running SQL scripts to create objects in the Appian Cloud database, don't use the DEFINER clause. If you don't specify the DEFINER, the database will use the default user to create the objects. This means that if the default database user ever changes, you won't have to worry about updating your scripts.

See troubleshooting section if you have issues related to editing objects in phpMyAdmin.

Only store data for your Appian applications in the database

Appian provides the Appian Cloud database to store data for your applications. We strongly discourage using the database to store other types of data. Doing so is outside of the scope of the Appian Cloud service.

Considerations and limitations

Advanced database configurations are not available in Appian Cloud databases

Because we want the Appian Cloud database to be easy to use, it is not a full-featured database solution. Many advanced features would require a dedicated database administrator for support. In order to avoid that, Appian Cloud customers don't have access to advanced database configurations.

If you want a full-featured database solution with advanced database features, you can host your own relational database and connect to it over the Internet or through VPN.

Creating and dropping temporary tables is not supported

The Appian Cloud database is configured for High Availability using GTID-based replication. Consequently, the use of CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE in transactions, procedures, functions, and triggers is not supported.

See the MySQL documentation on Restrictions on Replication with GTIDs for more information. The same limitations apply to MariaDB.

Limitations of responsibilities

Appian maintains performance for tables supplied by Appian. You are responsible for performance for the tables you create.

Appian Technical Support is not responsible for the administration of any customer data you may store in your database, beyond performing regular backups.

Maximum storage space limitations

There is a limit to your maximum allocated storage space, which is specified in your service agreement. Consider this limitation when designing your database or estimating the amount of data that will be stored in your database.

Additional features

The following features are available for Appian Cloud databases:

  • Advanced or Enterprise Support Appian Cloud customers can use the Enhanced Data Pipeline to connect directly to their business data source. It also allows them to utilize their data management tools such as:
    • Extract Transform Load (ETL) processes
    • Business intelligence
    • Data warehousing
    • Reporting
  • Appian Cloud databases that use MariaDB can enable data-at-rest encryption.

Troubleshooting

Editing stored procedures or function fails

If you are editing a stored procedure or function as a database administrator in phpMyAdmin, make sure that the value in the definer field is either empty or dbadmin. In general, it is a best practice not to use the DEFINER clause when running scripts in phpMyAdmin.

What to do if you get locked out of a stored procedure or function

If you try to edit the view without updating the DEFINER field, you may get locked out of the stored procedure or function. Use the AppianProcess.viewRoutineDefinition() to get the definition of the object and recreate it with dbadmin as the DEFINER or without the DEFINER specified.

Editing a view fails

When editing views in phpMyAdmin as a database administrator, if there is a value such as appian in the DEFINER field, update it to dbadmin. Do not leave it blank.

Open in Github Built: Tue, Nov 23, 2021 (07:31:46 PM)

On This Page

FEEDBACK