Application Containers
Lab 1: Instant SaaS Architecture
Overview
Lab 1 shows how Multitenant with Application Containers
provides an instant SaaS architecture for an application formerly architected
for standalone deployment.
Execution
- Open a terminal window
- Change directory to /u01/HOL/app_containers/
- source the environment. At command prompt execute source cdb1.env
- sqlplus /nolog
- At the SQL prompt execute SQL>@01.Instant_SaaS.sql
Simply start the script and follow what’s happening in the script. Ample explanation accompanies the commands to explain what we're doing. The script execution will pause periodically to allow you to review and read about what’s happening. When you’re ready for the script to advance, press [Enter] and execution will proceed.
Review of Application Container Lab1:
In this lab, we have worked through the following stages:
1. Setup Application Root - wmStore_Master
2. Install v1 of Application wmStore in Application Root
3. Create and sync Application Seed and provision Application PDBs for four franchises:
· Tulsa
· California
· Tahoe
· NYC
4. Populate Application Tenant PDBs with demo data.
This demonstrates how Multitenant with Application Containers delivers an "Instant SaaS" architecture, for an application definition previously architected for standalone deployment. You are now encouraged to execute some queries against the various franchise PDBs. Sample queries can be found in file Lab1_Queries.sql.
Detailed Steps
Phase 1. Create and Open Master Application Root.
Now we have an Application Root. Next, we have to install the master definition of the application wmStore (Walt's Malts Store).Let's get on with that...
Phase 2. Define Application Master.
Phase 2a. Begin the master application definition.
Phase 2b. Create tablespace and Application Common User.
What now follows is the standard installation script for the application. Note that this is basically unchanged from the application installation script that would have been run for a standalone installation in a non-CDB.
Phase 2c. Standard Application Installation.
In the preceding section we installed the master application definition in our application root, wmStore_Master. This process started with the statement:
alter
pluggable database application wmStore begin install
'1.0'
Following this we had a standard application installation script. We now have to designate the end of the master application definition.
We have now created the Application Root and installed the master application definition. Next we create the Application Seed and sync it with the application master. Following that, we can provision Application PDBs for new tenant / franchises.
Phase 3: Create Application Seed and Provision Application PDBs.
Phase 3.1. Create and open the Master Application Seed PDB.
Phase 3.2. Sync the Application Seed with Application wmStore.
Now we have an Application Seed from which to provision new tenants / franchises. Notice the syntax for creating the seed PDB, using the phrase "as seed".
Phase 3.3. Provision the App PDBs for each Franchise.
We have now provisioned an Application PDB for each tenant / franchise from the Application Seed, all synchronized with the master application definition. Now we'll go to each tenant PDB in turn and add some franchise-specific data. This is for demonstration purposes only. This is not part of the application definition. It merely simulates the creation of data which in the usual course of events would be defined through the application itself. This demo data will be added by the execution of scripts.
Phase 4: Create franchise-specific data
Phase 5: Queries
1. Notice the name of the Application Seed database. Recall from the lab that there was no opportunity to specify the name of Application Seed. The name is always that of the Application Root with a suffix of $SEED.
2. The previous statement succeeded because c##System is a CDB Common User with Set Container privilege in all containers. Now Let's connect to wmStore_Admin in the Application Root.
3. The previous statements succeeded because wmStore_Admin is an Application Common user. In fact all users created within an Application Root are by definition Application Common users. Application Common users may connect to an Application PDB in the same Application Container. However, they may not connect to any containers outside the Application Container. The following statement should therefore fail.
4. Now let's experiment with the Admin Users in the Application PDBs. Recall that an Admin User is specified along with the creation of every new PDB, including Application PDBs. In these labs, Application PDBs are provisioned with statements similar to this (which we'll comment out here):
create pluggable database Tulsa
admin
user wm_admin identified by secret
/
5. Let's experiment with these users a little. Notice that the direct connections were successful. We used the same username and password in each case. However, these are local users and technically it's purely coincidental that they have the same username and password. The alter session set container statement failed because they are not common users.
Click Here to Go to Lab 2