This is documentation for Apprenda 7 and 8.
Documentation for older versions are also available.

Data Tier

Given the importance of data storage to most applications, Apprenda manages "databases", or "structured storage partitions" in Apprenda terminology, supplied by your application archive as first-class citizens. The Apprenda Platform will provision both the artifacts that make up the SQL Server or Oracle storage partition (tables, views, etc) and populate initial data as required. Apprenda's advanced lifecycle mechanisms make sure that your storage partition is updated appropriately by the Platform when new versions of your application are published. This topic describes how data storage works on the Platform.

NOTE: As of Platform version 8.1.0, Oracle 11g is no longer supported.

Data Storage Hosts

All Apprenda Platform installations offer MS SQL Server as a data storage host for guest applications. A Platform may also be configured to offer Oracle RDBMS as a data storage host. These software technologies each employ their own set of terminologies. As much as possible, our documentation will use technology-specific terminology; the Apprenda Platform itself, however, will use the following terms: 

Definition MS SQL Server Usage Oracle 11g Usage Oracle 12c Usage Apprenda Usage
Installation of the primary DBMS software on an individual server or cluster that serves as data storage host, SQL Server Instance Oracle RDBMS Installation/Node

Oracle RDBMS
Installation/Node
or
CDB
(Container Database)

Database Node/Server
Storage unit within a data storage host that is usable by Apprenda for provisioning for guest applications Database Schema PDB
(Pluggable Database)

Database
or
Storage Partition

In addition, the following SQL Server and Oracle-specific terms are used throughout our documentation.

  • SQL Server Login: Account created in and able to attach to a SQL Server instance.
  • Windows User account:  pre-existing Windows accounts that can be specifically granted login permission to access a SQL Server instance.
  • SQL Server User: Association between a login and permissions to access specific databases.
  • Oracle User: Account provisioned with a specific schema. What a user can do is determined by permissions the user has been granted, including attaching to an Oracle RDBMS instance and accessing another user's schema.  A user will ALWAYS have certain inalienable permissions to the objects created in their own schema.

Platform Operators may update guest applications data partitions that use SQL Server or Oracle 12c to connect to off-Platform storage servers via the forward-deploy operation (previsouly called a database move). The functionality allows the Platform to better support enterprise-level scenarios like High Availability and credential rotation. The abilitt o forward-deploy SQL Server databases is new in Platform version 8.0.0, but was previously available for Oracle databases in earlier Platform versions. See more more information on the forward-deploy workflow and administering Database-as-a-Service on the Apprenda Cloud Platform.

The naming and user conventions outlined below for both SQL Server and Oracle 12c apply once a storage partition is deployed on the Platform. If Platform Operators choose to forward-deploy partitions to external servers, then different naming and password conventions can be used. 

Deployment Mechanics

Any Apprenda Windows Application server that hosts Apprenda's Storage Controlling Services (which requires that the server have SQL Server Management Objects [SMO] installed) will have the Storage Controlling Services Host role. The Storage Controlling Services interfaces with SQL Server and Oracle to create, delete, and otherwise configure databases, schemas and any other database object.

The following steps occur as a part of the deployment process:

  1. Apprenda chooses a data host based on an application's configuration (SQL Server, Oracle 11g, or Oracle 12c), the data host's Database Security Mode, and any relevant Application Deployment Policies.
  2. Apprenda provisions the database objects and inserts initial data.
  3. Apprenda establishes connection information.

Unless Application Deployment Policies or Database Security Mode configurations are in play, Apprenda chooses a data host at random. Once the host has been chosen, the Storage Controlling Services manages the remaining steps.

Applications in the Sandbox Stage

Deployment of a storage partition is always triggered whenever an application is promoted to the Sandbox stage; this is the case regardless of whether the application is single- or multi-tenant (and regardless of the data deployment model chosen for multi-tenant apps).  The reason for this is that a storage partition is provisioned for testing purposes.  

The storage partition used for an application version in the Sandbox stage is permanently deleted when the application is promoted to the Published stage. It will also be deleted if the application version is demoted from the Sandbox stage to the Definition stage (a new storage partition will be deployed if the application version is subsequently re-promoted to the Sandbox stage). 

Applications in the Published Stage

For applications in the Published stage, storage partition deployment occurs as follows:

  • For single-tenant applications, a storage partition will be provisioned when the application is promoted to Published.
  • For multi-tenant applications with  a commingled data deployment model (MS SQL Server only), a database will be provisioned with the app is promoted to Published.
  • For multi-tenant applications with an isolated deployment model, a storage partition will be provisioned for each Tenant when they initially subscribe to the application.

How Apprenda Provisions a SQL Server Database or Oracle Schema/PDB for Single-tenant Applications

For single-tenant applications, Apprenda first creates a virtual Tenant by means of an account created by the Platform Operator.  All of the data ultimately created will belong to this single virtual Tenant. For applications configured to use Authentication or Authorization services, all of the Users granted access to the application will be joined to the virtual organization. The virtual tenant is a useful construct for the Apprenda Platform in light of the fact that the Platform supports multi-tenancy, which can be summarized as the segmenting of data when many organizations are sharing the same website or service (see below for information on data in multi-tenant applications).  Please note that for single-tenant applications with Authorization, the Development Team that owns the application will be used in lieu of creating a virtual Tenant in the Sandbox stage only.

Sandbox Stage Naming Conventions

For a SQL Server database created for an application in the Sandbox stage, the alias of the application, the alias of the application version, and the alias of the virtual Tenant form the name of the database as follows:

${appAlias}--${versionAlias}__${tenantAlias}

For an Oracle 11g schema created for an application in the Sandbox stage, this format will be preceded by "DB#-"; the full name will correspond to an Oracle user created to provision and own the schema:

DB#-${appAlias}--${versionAlias}__${tenantAlias}

For an Oracle 12c PDB created for an application in the Sandbox stage, this format will be as follows:

D#${appAlias}_${versionAlias}_${tenantAlias}

Published Stage Naming Conventions

For an application in the Published stage, the name of the SQL Server database is formed as follows:

${appAlias}__${tenantAlias}

The Oracle 11g  schema for a Published application is formed as follows; the full name will correspond to an Oracle user created to provision and own the schema:

DB#-${appAlias}__${tenantAlias}

For an Oracle 12c PDB in the Published stage, the name is formed as follows:

D#${appAlias}_${tenantAlias}

Once the database, schema, or PDB is created, the application provisioning script or Data Tier plugin is executed to create the views, stored procedures, tables, and other artifacts. Then, the Tenant provisioning script, if provided, is executed against the database to insert initial data.

Please see below for applicable information on Additional Provisioning Steps Specific to SQL Server Databases and Additional Users/Schemas Created in Oracle.

How Apprenda Provisions a SQL Server Database or Oracle Schema/PDB for Multi-tenant Applications

For multi-tenant applications, databases/schemas are designed as if for one and only one Tenant, which corresponds to the way on-premise software databases are designed. Apprenda will then convert your storage partition model (written as though it was for one Tenant) and change it so that the data for multiple Tenants can be stored and accessed from your other application components. 

When using MS SQL Server, there are two different options for how Apprenda applies multi-tenancy to your databases, with varying implications on the server's resources:

  • Commingled: Data for multiple Tenants is stored in and retrieved from a single database by means of row-level security. Apprenda modifies the entire physical structure of your database to inject shared, multi-tenant ownership of rows while guaranteeing the full structural expectations of all callers (i.e., callers will be executing queries as if they were communicating for a specific Tenant, despite working with a database that has mixed data from multiple Tenants). This model is currently only supported in SQL Server and it allows for high overall compression and scale on a limited number of database servers. 
  • Isolated: In the case of SQL Server, data for each Tenant is stored in an individual database; data for different Tenants is never mixed with each other like in the case of Commingled data model. Apprenda provides the infrastructure for keying into the correct database and selecting data from that database depending on the Tenant under which a User is initiating queries against the data model.

At present, when using Oracle there is only one option for applying multi-tenancy:

  • Isolated: In the case of Oracle, data for each Tenant is stored in an individual schema/PDB; data for different Tenants is never mixed with each other. Apprenda provides the infrastructure for keying into the correct schema/PDB and selecting data from that storage partition depending on the Tenant under which a User is initiating queries against the data model.

An application's data deployment model can be configured in the Developer Portal prior to publishing the application on Apprenda as well as through the application's Deployment Manifest.

Apprenda is cognizant of the need to scale and relocate data among multiple servers in the Platform instance. Thus, Apprenda introduces the notion of partitions and shards. How these apply to databases is defined below:

  • Partition: Each instance of a storage partition is a storage partition.
  • Shard: The rows of data that belong to the Tenant comprise a shard.

When the deployment model is Commingled, a partition can have multiple Tenant shards. When the deployment model is Isolated, each partition has one and only one Tenant shard.

Though the steps are the same, the deployment process is quite different depending on the deployment model that is chosen.

Isolated Deployment

Recall that for an Isolated data deployment model, each and every Tenant who subscribes to the application will have their data stored independently of other Tenants. The procedure outlined here happens each and every time a new Tenant has subscribed to the application.

When the application is promoted to the Sandbox stage, the Development Team that created the application is automatically provisioned as a Tenant for testing purposes.

Sandbox Stage Naming Conventions

In the case of SQL Server, this server will host a newly created database.  For an application in the Sandbox stage, the alias of the application, the alias of the application version, and the alias of the subscribed Tenant (for the initially provisioned database, this will be the alias of the Development Team) form the name of the database as follows:

${appAlias}--${versionAlias}__${tenantAlias}

For an Oracle 11g schema created for an application in the Sandbox stage, this format will be preceded by "DB_*"; the full name will correspond to an Oracle user created to provision and own the schema:

DB#-${appAlias}--${versionAlias}__${tenantAlias}

For an Oracle 12c PDB created for an application in the Sandbox stage, this format will be as follows:

D#${appAlias}_${versionAlias}_${tenantAlias}

Published Stage Naming Conventions

For an application in the Published stage, a SQL Server database or Oracle schema will be created each and every time a new Tenant subscribes to the application (storage partition creation will not occur upon promotion to the Published stage). 

For an application in the Published stage, the name of the SQL Server database is formed as follows:

${appAlias}__${tenantAlias}

The Oracle schema for a Published application is as follows; the full name will correspond to an Oracle user created to provision and own the schema:

DB#-${appAlias}__${tenantAlias}

For an Oracle 12c PDB in the Published stage, the name is formed as follows:

D#${appAlias}_${tenantAlias}

Once the database, schema, or PDB is created, the application provisioning script or Data Tier plugin is executed to create the views, stored procedures, tables, and other artifacts. Then, if the Tenant provisioning script is provided, it is executed to insert initial data. 

Please see below for applicable information on Additional Provisioning Steps Specific to SQL Server Databases and Additional Users/Schemas Created in Oracle.

Commingled Deployment (available for MS SQL Server only)

For the Commingled model, multiple Tenants' data will be placed in the same database. Recall that each database is a partition, and each shard corresponds to the Tenant's logical data. This means there are multiple shards in the same database as illustrated in the following diagram that shows how Commingled data is represented in Apprenda:

In this model, partition, or database, creation is a separate operation from the Tenant's shard creation. Databases are created when:

  • The application is promoted to the Sandbox or Published stage.
  • The Development Team elects to create an additional partition to distribute data among multiple servers.

Upon database creation due to one of the reasons above, a random SQL Server instance is chosen. This instance will host a newly created database on this server. For a database created for an application in the Sandbox stage, the alias of the application and the alias of the application version form the name of the database as follows:

${appAlias}--${versionAlias}

For an application in the Published stage, the name of the database is formed as follows:

${appAlias}

Once this database is created, the application provisioning script or Data Tier plugin is executed to create the views, stored procedures, tables, and other artifacts. Apprenda produces a set of transformations on the originally uploaded script that add row-level ownership constructs into the table structure, allowing data from multiple Tenants to be mixed in single database instances. Specifically, tenant ownership columns are introduced to tables, primary keys are augmented, foreign keys are re-bound, indexes are optimized, row level security is injected through dynamic role creation, and appropriate configuration is introduced to provide Tenant-specific yet indirect access to the underlying data. Apprenda focuses on providing optimized multi-tenant access. For example, indexes are modified to allow for quick disk seeking to shard data, and query plans are optimized around new indexing constructs. Then, each time a Tenant is provisioned for the application, the Tenant provisioning script (if provided) is executed against the database to insert initial data for that Tenant.

Please see below for applicable information on Additional Provisioning Steps Specific to SQL Server Databases.

Additional Provisioning Steps Specific to SQL Server Databases

Provider Database

The provider database is a special database created for SQL Server only in order to permit the querying of data belonging to multiple Tenants along with other advanced features at the same time. When the initial database for an application is provisioned, the provider database is created if it does not already exist. There is exactly one provider database per application regardless of the number of Tenants.  Although the provider database is only useful for multi-tenant applications, it is created for all guest applications that use SQL Server as a part of the Platform's functionality.

For an application in the Sandbox stage, its name is as follows:

${appAlias}--${versionAlias}__PROVIDER

For an application in the Published stage, its name is as follows:

${appAlias}__PROVIDER

Database Logins and Users (for Applications using SQL Server Authentication)

Apprenda creates one login per Tenant (including virtual Tenants) using the following pattern that is keyed to a unique tenantID:

tenant-${tenantID}

In addition, Apprenda creates one login for each Development Team using the following pattern that is keyed to a unique tenantID:

provider-${tenantID}

The credentials for each login are encrypted and stored in the SaaSGrid Core database.

For each application database deployed with the Isolated data deployment model, Apprenda will take the login for the Development Team and the login for the single corresponding Tenant and make them users for that database.  

For each application database deployed with the Commingled data deployment model, Apprenda will take the login for the Development Team and the logins for all corresponding Tenants and make them users for that database.  The user for a specific Tenant will be able to access only those rows that have been allotted for that Tenant, meaning that security is row-specific and only the data corresponding to a given Tenant is visible to that Tenant. The user for the Development Team will have access to all rows in the database.

For each provider database,  Apprenda will take the login for the Development Team and the login and the logins for all corresponding Tenants and make them users for that database.  The user for the Development Team will have access to all rows in the database; users that correspond to Tenants will have access only to data that is marked as shared among all Tenants.

Now that the database name and login information are set, all of the necessary information needed by the Platform to construct a connection string to the database is in place. The connection string used by your application components can be accessed via Apprenda's API, or the connections can be dynamically configured by the Platform via configuration when those items are deployed. See the Developer Topic called Working with Data for more information on how to work with database connections in other application components.

Database Logins and Users (For Single-Tenant .NET Applications on Platform Configured to use Windows Authentication/SSPI)

For single-Tenant .NET applications that use MS SQL Server on Platforms configured to use Windows Authentication (through SSPI), all communication between a guest application's services/UIs and corresponding database is done through Windows User account credentials. The login/user configuration process for such an application is as follows:

  • When a guest application UI or service is provisioned, the Windows User account under which UI/service component runs is granted login access to the SQL Server instance (with public server role privileges only) that houses the guest application's database. If the login already exists, this step will be skipped.
  • The login will be made a user for the guest application database.
  • If the guest application has components that run under different Windows User accounts, each account will (as needed) be granted login access to the SQL Server instance and made a user for the guest application database.

A record of each login and corresponding databases for which they are made users is stored in the ApprendaManagement database; passwords for Windows User accounts are not stored. This allows Apprenda to keep track of all SQL users and logins. A Windows User-based login will be removed as a user from a database if all UI/service components that used the corresponding credentials are removed; if a Windows User-based login is removed as a user from all guest application databases, it will be removed from the SQL instance if the Windows User account was initially granted login permissions by Apprenda. Any Windows User accounts that are manually added as logins on a SQL instance will not have their login privileges revoked in such a manner.

Please note: if a SQL Server instance is configured to use both SQL and SSPI, SQL logins will still be created as noted above, but UI and service components will communicate with the database only through Windows User account(s).

Now that the database name and login information are set, all of the necessary information needed by the Platform to construct a connection string to the database is in place. The connection string used by your application components can be dynamically configured by the Platform via configuration when those items are deployed. See the Developer Topic called Working with Data for more information on how to work with database connections in other application components.

Shared Data

In MS SQL Server, the Platform supports sharing data in specified tables across all Tenants for a multi-tenant application. This is done by marking specific tables as "shared" in the Deployment Manifest included with the Application Archive used to initially upload application binaries to the Platform. Shared tables can be specified for applications configured with either the Isolated and Commingled data deployment model. It should be noted that shared data manipulations affect all Tenants for the application.

Shared data resides on the provider database created for an application (explained above), making it accessible to the application's Development Team and Tenants through their respective database logins.

Additional Users/Schemas Created in Oracle 11g

As noted above, when a schema is created for an application, a corresponding user is created to provision the schema and act as the schema owner: 

DB#-${appAlias}__${tenantAlias}  

Because the user above is the schema owner, it has permissions and rights that are required to create a schema, but which are superfluous for runtime use by the application.  For security reasons, a second user with reduced privileges is created to act as the runtime user:

TU#-${appAlias}__${tenantAlias}

A third user is created as a provider account (this user is reserved for future use):

PU#-${appAlias}__${tenantAlias}

Examples above are for a Published application; in actual execution the "#" will be replaced by a number that will be consistent across all three users/schemas.  In all cases the user/schema name is limited to 30 characters and will be truncated at the end if needed.

Please note that the credentials for each user/schema are encrypted and stored in the SaaSGrid Core database.

Now that the schema/user information is set, all of the necessary information needed by the Platform to construct a connection string to the appropriate schema is in place. The connection string used by your application components can be accessed via Apprenda's API, or the connections can be dynamically configured by the Platform via configuration when those items are deployed. See the Developer Topic called Working with Data for more information on how to work with Oracle schema connections in other application components.

Additional Users Created in Oracle 12c

As noted above, when aPDB is created for an application it is named as follows:

D#${appAlias}_${tenantAlias}  

Examples above are for a Published application; in actual execution the "#" will be replaced by a number. In all cases the PDB name is limited to 30 characters and will be truncated at the end if needed.

A corresponding user is created to act as the default owner of all objects created without specifying a schema: 

DEFAULT_SCHEMA

Because the user above is the schema owner, it has permissions and rights that are required to create and patch a schema, but which are superfluous for runtime use by the application.  For security reasons, a second user with reduced privileges is created to act as the runtime user:

TENANT

Please note that the credentials for each user are encrypted and stored in the SaaSGrid Core database.

Now that the PDB and user information is set, all of the necessary information needed by the Platform to construct a connection string to the appropriate PDB is in place. The connection string used by your application components can be accessed via Apprenda's API, or the connections can be dynamically configured by the Platform via configuration when those items are deployed. See the Developer Topic called Working with Data for more information on how to work with Oracle schema connections in other application components.

Database Provisioning for Patched Application Versions

Some application components, like WCF services, Windows Services, .NET UIs, and Java Web Applications, are disposable. When a future version of the one of those types of application components is Published, the old version is removed and replaced with the new version. This is not possible for SQL Server and Oracle storage partitions, because data must be preserved from version to version in many cases.

The database provisioning strategy chosen when first deploying the application will affect how the Platform provisions the application’s databases when the application is patched.

Note: Data Tier plugins were introduced in Platform version 8.2.0. They enable developers to use any ORM software, like Microsoft’s Entity Framework Code First Migrations to configure the data tier for a guest application. If you are running a Platform version before 8.2.0, all database provisioning is done using scripts.

Data Tier Plugin Patching (Platform version 8.2.0 and later)

When provisioning, once a storage partition, during Promotion or Tenant Onboarding, is created, the Data Tier plugin Provision callback method is executed to create the views, stored procedures, tables, data and other artifacts.

When patching, the Data Tier plugin Patch callback method is executed. The Platform provides the Patch method with information needed to find the two application versions (X and Y) of the application involved in the patch. The plugin must then perform the changes necessary to bring the partition from X to Y, including all schema artifacts & data. During this method call, the Platform provides a user to the plugin with elevated permissions to allow schema modifications.

The table below outlines how and when each Data Tier Plugin callback method is used to affect the structure and content of guest application storage partitions:

Application Version Stage New or Existing DB/Schema Plugin Callbacks Notes
Version 1 (initial version) Sandbox New Provision A DB/schema is created for testing only, and will be torn down when the version is Published
Version 2 (patched version) Sandbox New Provision A DB/schema is created for testing only, and will be torn down when the version is Published
Version 2 (patched version) Published New Provision  
Version 2 (patched version) Published Existing Patch, Rollback (on failures only)  

The following steps explain how storage partitions are patched:

  1. When the patched version (Version 2) is promoted to the Sandbox stage, a test storage partition is created and Provision applied to it.
  2. During promotion of the patched version to Published
    • Patch is called for each existing Tenant Partition
    • If this is an single tenant application, Provision is called to create the apps singular Partition
    • The storage partition used for the Sandbox stage is permanently deleted.
  3. For multi-tenant apps only, Provision is called for each new partition created during Tenant Onboarding

Note that transactions cannot be guaranteed by the Platform when using Data Tier plugins. The Platform is set to taken a backup by default before Patch to aid in recovery if an error occurs.

For information on how to package Data Tier plugins for upload to the Platform, please see our documentation on Patching Archives.

Provisioning Scripts Patching

Recall that once a storage partition is created, the application provisioning script is executed to create the views, stored procedures, tables, and other artifacts.  When a Tenant is provisioned for the application, the Tenant provisioning script (if provided) is executed to insert initial data for that Tenant (if a Tenant provisioning script is not provided, initial data will not be populated).  At this point Tenants can access the application and create their own data.

When patching, then, both the structure and content of existing storage partitions must be taken into consideration. Because of this, it is not possible to simply upload and execute a new version of the application provisioning script; instead, patching scripts must be used (it should be noted that structural and/or content changes can also be made to shared tables using patching scripts). 

Structural changes to storage partitions can be achieved through a patching script known in Platform terminology as a “schema patching script”.  Such scripts will be executed against existing storage partitions to make structural alterations (e.g., add a column).  Schema patching scripts will also be used to amend the original application provisioning script, thereby creating an updated version of the application provisioning script that will be used to when creating databases/schemas for new Tenants.  

Changes to data in existing databases/schemas can be achieved through a patching script known as a  ”data patching script”.  Such scripts will be executed against existing partitions to alter existing content or insert new data (e.g., set the value for a column).  Data patching scripts will only be executed against existing storage partitions. They cannot be used to alter an existing Tenant provisioning script, and will have no effect on storage partitions created for new Tenants.  It is possible, however, to include a revised Tenant provisioning script when patching an application. The new Tenant provisioning script will simply replace the existing one, and will determine what data is initially inserted into databases/schemas created for new Tenants.

The table below outlines how and when an application provisioning script, Tenant provisioning script, schema patching script, and data patching script affect the structure and content of guest application storage partitions:

Application Version Stage New or Existing DB/Schema Structure Data Notes
Version 1
(initial version)
Sandbox  New Created by application provisioning script Populated by Tenant provisioning script (if provided) A DB/schema is created for testing only, and will be torn down when the version is Published
  Published New Created by application provisioning script Populated by Tenant provisioning script (if provided)  
Version 2
(patched version)
Sandbox New Created by an internal version of the application provisioning script that has been amended by any provided schema patching scripts Populated by updated Tenant provisioning script; if no updated script is provided, the script from Version 1 (if one was provided) will be used A DB/schema is created for testing only, and will be torn down when the version is Published
  Published  Existing Modified by any provided schema patching scripts Modified by any provided data patching scripts  
  Published New Created by an internal version of the application provisioning script that has been amended by any provided schema patching scripts Populated by updated Tenant provisioning script; if no updated script is provided, the script from Version 1 (if one was provided) will be used  

 

The following steps explain how storage partitions are patched:

  1. When the patched version (Version 2) is promoted to the Sandbox stage, a test storage partition is created based structurally on an internal version of the application provisioning script created by amending the original application provisioning script with schema patching scripts supplied for the patched version. If any updated Tenant provisioning script is included for Version 2, this will be used to populate data; if no new Tenant provisioning script is provided, but one was provided for the initial version (Version 1), the Version 1 tenant provisioning script is used to populate data.  
  2. Once the patched version is promoted to the Published stage, the storage partition used for the Sandbox stage is permanently deleted.
  3. The set  of changes denoted by the schema patching scripts and/or data patching scripts defined during the patch process are applied to any extant storage partitions. Storage partitions provisioned for new Tenants after the patched version has been published will be provisioned based on the amended application provisioning script.  If any updated Tenant provisioning script is included for Version 2, this will be used to populate data; if no new Tenant provisioning script is provided, but one was provided for the initial version (Version 1), the Version 1 Tenant provisioning script is used to populate data.

The process described above is transactional so that in the event that a patch script is invalid as applied to the existing data in a storage partition or some other issue occurs, the previous version of the application remains Published. The exception to this rule is that data left in the Sandbox version of the storage partition that was deleted in Step 2 is not guaranteed to be preserved.

For information on how to package patching scripts for upload to the Platform, please see our documentation on Patching Archives.