Category Archives: Autonomous

Create and use an Oracle Autonomous Cloud Database from the Command Line

In this post I’ll cover how to create an Oracle Autonomous Cloud Database download the Wallet credentials and connect to the database all from the command line using the OCI-CLI.

After that I’ll include an example of a shell script that I use to setup my Demo environment.

Prerequisites

Get the Compartment OCID

I like to keep all of my work compartmentalized so that I don’t run into conflicts between my (and potentially other people’s) projects.  This means I’ll need to get the OCID of the compartment I want to work in.

Rather than use the Web Console you can run this command to get a list of your available compartments.

Assuming that you already know which compartment you want to work with you can use the --query  parameter to retrieve the ID of that compartment.

The above command returns an array called data that I will use to query an object.

I’d like to retrieve only the object with a name of ‘Demo’.

Now that I have the full object, I can get the id value.

The list command will return all objects that match the query criteria in an array.  Even when there is only a single object it will be returned in an array.

Next, I pipe out the first (and only) value from the array.

Using the --raw-output  parameter, I can get the raw value without the double quotes.

I can use this command to set an environment variable.

The OCI-CLI query parameter uses the JMESPath query language.

Create Compartment

If the compartment doesn’t exist you can use OCI to create one.  For this command you will need the OCID of an existing compartment.  This will be the parent compartment.

If you want to use an existing compartment as a parent, you can use the above command to get the OCID.  Or, if you want to add the new compartment to the ROOT compartment, you can use the Tenancy OCID.

You can get the Tenancy OCID from:

  • Your OCI Config file cat ~/.oci/config.
  • The OCID of an existing compartments parent.
    This time I’m using the ?contains()  function to check compartment-id for the string ‘.tenancy.’.  Notice that the compartment-id must be double quoted because it contains a ‘-‘ and those double quotes are escaped.  \"compartment-id\" oci iam compartment list --query "data[?contains(\"compartment-id\",'.tenancy.')].\"compartment-id\" | [0]" --raw-output

Once you have the parent compartment OCID the command to create a new compartment is:

Database

I can check to see if the database already exists by using a query similar to the one I used for compartments.

If the demo database doesn’t exist I can create a new Always-Free Autonomous Cloud Database with the OCI-CLI.

The data-storage-size-in-tbs is set to 1TB which is larger than the free tier supports.  Setting --is-free-tier True  will cause the system to automatically scale it to the correct size.

The default value for ‘is-free-tier’ is False, if you do not include this parameter you will create a standard Autonomous Cloud Database.  You should check the Cost Estimator to ensure that you’re OK with the cost.

Setting --db-workload "OLTP"  will create an Autonomous Transaction Processing database, using “DW” will create a Data Warehouse.

Make sure you use a strong --admin-password , this will be the admin password for the new database.

This command will return a JSON object with the properties of the new database.

I’ll add the query and raw-output parameters to extract the ID and assign it to an environment variable.

In order to connect to my new database I will need to

Download the Wallet

Wait for your database to be in an AVAILABLE state before attempting to download the wallet.

This command will download your wallet credentials in a .zip file, just like you’d get from the web console.

The $DB_ID variable was set above for the demo database.  The –file parameter accepts the location and file name where you want to download the .zip file.  The new file will have the password set by –password.

Now that everything is in place I can

Test the Connection

  • I’ll start SQLcl without making a connection (/nolog).
  • Set cloudconfig to the location of the wallet credentials.
  • Connect with the admin password and one of the service names contained in the tnsnames.ora file included in the wallet zip file.
    The predefined service names will be in the form of <name of the database>_<performance level> .  You can find more information here.
  • Run a test query.

Use a Shell Script to Automate

The following is an example of a setup script I use for my demos.

Notice that in the create database method I added a new parameter to the OCI call --wait-for-state AVAILABLE.  Since I won’t be able to download the wallet until the database is available, I use this parameter to pause at the create step until the new Database is fully up and running.

When I run the script I get

Explore

This is just a small taste of what you can do with the OCI-CLI.  Check out the documentation for a look at the possibilities.

Leave a comment if you have a question and I will do my best to find you an answer.

Install and configure the Oracle Cloud Command Line Interface

I love working with cloud resources.  I don’t have to bog down my laptop and I don’t have to maintain all of the back-end stuff.  I don’t mean to make it sound as if I think the “back-end stuff” is easy.  It’s actually, I understand just enough of that “stuff” to make it go (most of the time) so it’s nice to have experts in the cloud taking care of it for me.

Some of you may be thinking “but cloud resources are expensive.”  That’s true sometimes, but it depends on who’s cloud you’re using.  If you’ve been following me you should already know how much I like Oracle’s Always Free Services and you should know that I love to automate anything I can.  If you’d like to follow along but you don’t have an Oracle Cloud account, click that link, create an Always Free account then come back.

In this post I’ll cover how to use the Oracle Cloud Command Line Interface (OCI-CLI) to access and control your Oracle Cloud resources.

CLI Overview

Oracle’s cloud CLI is a small application you can use to control your Oracle Cloud resources.  It gives you the same core functionality as you’d get using the Web Console, and some extra commands.  It allows you to control your cloud account from your local console application so you can easily automate the control of your resources.

Pre-requisits

Python 3.5+

The CLI is built with Python so make sure you have Python version 3.5 or higher installed.

RSA Key Pair

You will need an RSA key attached to your cloud user in order to remotely access your account.  This must be an RSA key pair in PEM format (minimum 2048 bits).

The easiest way to generate this key par is with openssl.  The following commands work in Linux/Mac environments.  For Windows you can use your favorite tool or execute the commands in GitBash, WSL or some other Linux shell environment.

The first command creates a PRIVATE KEY called ‘myPrivateKey.pem’ (name yours whatever you’d like).  This is the key you will use to access remote systems.  DO NOT share this key, whoever has this key can connect to those systems as you.  Think of it as your admin password.

The second command uses your private key to create a PUBLIC KEY called ‘myPublicKey.pem’ (name yours whatever you’d like).  This is the key you will share with remote systems.  Those systems will add your PUBLIC KEY to their authorized keys list, allowing you to access their system using your private key.

Store these keys in a secure location.  On Linux, the default location is usually in the ~/.ssh directory.  But, if you’re creating separate keys for your projects, you can store them wherever you’d like.  Just remember the location for later.

Cloud Account

You need to have access to an Oracle Cloud account with a user that is authorized to preform the tasks you intend to automate.  A good way to tell if your user has the correct permissions is to log onto your account through the Web Console and create an Always Free database then terminate it.

While you’re logged into the Web Console collect some information.

  1. Tenancy
    1. In the menu, under Administration, click Tenancy Details.
    2. Locate the OCID and click Copy.
    3. Save this value for later.
  2.  User
    1. In the menu under Identity click Users.
    2. Select your user.
    3. Near the bottom click ‘API Keys’ under the resource menu.
    4. Click the ‘Add Public Key’ button.
    5. Choose the PUBLIC key file you generated earlier.
    6. Click the ‘Add’ button.
    7. Your key should now show up in the ‘API Keys’ list.
    8. Copy the fingerprint of your key and save it for later.
    9. Near the top of the user page, locate the OCID and click Copy.  Save this value for later.

Quickstart Install

You can download an execute a script that will ask you typical installation configuration questions, after which it will install and configure the OCI-CLI.

The following is current as of the publish date for this post, but you may want to review the instructions in case things change.

Linux / Mac

Open a terminal and run the following command.

Windows

Open PowerShell as Administrator.

In either system, answer the questions to complete the install.

Install with Python

If you don’t have the rights on your computer or you’d rather not execute the above scripts, you can install the OCI-CLI with Python.

I recommend using a virtual environment when working with python.  It helps keep all of your projects clean and isolated.

Once your virtual environment is active, install the OCI-CLI with pip.

You can see if the install was successful by checking the version.

Configure the OCI-CLI

Using the values you saved from above, you can create a config file with this command.

You will be prompted for the following information.

  • The default location for the config file is typically ‘~/.oci/config’.  If you use a different location you will need to remember where it is.
  • Enter the user and tenancy OCIDs saved from your account.
  • Enter the region you want to work in.  The system will display some examples you can choose from.
  • You already generated an RSA key pair so enter ‘n’.
  • Enter the location of your PRIVATE key.  This will not be uploaded, the CLI will use your PRIVATE key to make the connection to the cloud.
  • Enter the Fingerprint you saved when you uploaded your PUBLIC key.

Once it’s complete, you should see a response similar to this.

Your OCI-CLI should now be configured.  If you open the config file it should look similar to this.

You can add other connection profiles manually by following this format or you can use the same command to add a new profile.  If you re-run the command, it will ask you for a name to use for the new profile which will be added to the config file.

Quick Test

Enter the following command.

If everything is working, you should receive a response similar to this.

Now that your OCI-CLI is installed and configured, you should familiarize yourself with the OCI-CLI documentation to learn about the many, many commands you can use to automate the control of your Oracle Cloud resources.

You can use these same commands from any system with the OCI-CLI installed, including Oracle Cloud Compute instances.

Use ORDS to run the CodeCard backend on your own free Oracle Cloud Database

ORDS (Oracle Rest Data Services) is a fast and easy way to host a REST API you can use to take full control of your Oracle CodeCard.

In this post I’ll walk through how to create the ORDS API on your own Always Free Oracle Cloud Database.

Prerequisites

    1. Create a compartment in your Oracle Cloud Account (Optional but recommended)
    2. Create an Always Free Autonomous Database on the Oracle Cloud
    3. Go to the Service Console for your new database, click on “Development” and save the URL in the “RESTful Services and SODA” section.
    4. CodeCard Sketch changes: Howto disable fingerprint check and increase REST URI size
    5. You Went to Oracle Open World 19 and got a Code Card, now what?
      Ignore the fingerprint settings since you just disabled that in the previous step but add the following.
      Replace the below {{URL}} with the URL you saved above.
      Make sure there’s only one / between your URL and cc.  For example:
      buttona1=https://asdr34edyjtyi4j-codecard.adb.us-ashburn-1.oraclecloudapps.com/ords/cc/functions/master

When all of that is done, go to the Development section of the Service Console for your ATP instance and click “SQL Developer Web”.  Sign in as admin with the admin password you created in step 2.

Database Setup

As Admin, create the CODE_CARD schema.

Execute the following code in the worksheet.  Use a good password and remember it for later.

This will create the new CODE_CARD schema and REST enable the schema so you can use it with ORDS.  Notice the p_url_mapping_pattern is set to ‘cc’, this will be part of the REST URI in the following sections.

oraclecloudapps.com/ords/cc/
As code_card, create the database objects

Switch to the code_card schema by changing the URL In your browser.  Replace ‘admin’ with ‘cc’.
...oraclecloudapps.com/ords/admin/_sdw/?nav=worksheet  to ...oraclecloudapps.com/ords/cc/_sdw/?nav=worksheet

Log into SQL Developer Web as code_card using your new password.

In a worksheet, use the following to create the tables.

Oracle REST Data Services API

You will need two rest endpoints.   One to POST the setting for each button press and one your CodeCard will use to GET those settings.

There are multiple ways you can create an ORDS API, this post will walk through how to create the API using PL/SQL.  I will explain the settings that are most important for the CodeCard interface.  For the other settings, you can find the full documentation here.

This step was completed above

When you created the new schema above, you also REST enabled the new schema with this PL/SQL.

This command was included in the above step so that you could log into SQL Developer WEB as code_card.

The following will explain the individual PL/SQL procedures used to create the REST API.

If you want to skip the explanation, you can jump straight to the complete code included below.

Define a module

A module is a collection of related REST services.  Think of a module as a package that contains REST endpoints.

Create a module called ‘functions’.

The base path is set to ‘/functions/’, this will be part of the REST URI.

oraclecloudapps.com/ords/cc/functions/
Define a Template

A Template is the endpoint for your REST API.

The pattern is set to ‘master’, this will be the final part of the REST URI.

oraclecloudapps.com/ords/cc/functions/master
GET request handler

The CodeCard sends a GET request to the REST API to retrieve the settings assigned to a specific button (A or B) and press function (long or short).

In order to handle this request we need to define a GET handler.

Using a source type of  ‘json/collection’ would allow you to use a simple SQL query and ORDS would handle all of the JSON formatting for us.  This would be easier.

However, we want to be able to return a functioning screen layout to the CodeCard even if there’s an error.  Using a source type of ‘plsql/block’ lets you create and return a custom APEX_JSON object even if there’s an error.

Parameters for the bind variables

The PL/SQL code uses 3 bind variables that are mapped to incoming request header values.

The bind variables are mapped to the header values by defining parameters. These parameters will all be assigned to the ‘functions’ module, ‘master’ template and  ‘GET’ handler.  They will be passed ‘IN’ through the ‘HEADER’ as a ‘STRING’ type.  The value of the incoming header defined in ‘p_name’ will be mapped to value of the PL/SQL bind variable defined in ‘p_bind_variable_name’.

  • X-CODECARD-ID is the id assigned to your CodeCard.
  • X-CODECARD-BUTTON-LABEL will either be the A or B button.
  • X-CODECARD-BUTTON-FUNCTION will be 1 for a short press or 2 for a long press.
Handle POST requests

The CodeCard sends a POST request to the REST API to store the settings assigned to a specific button and press function.

In order to handle this request we need to define a POST handler.

This PL/SQL block will either create a new record or update an existing record for the incoming CodeCard id, button label and button function.

Parameters for the bind variables

The parameters for the POST handler are the same as for the GET handler.

Register template (Optional)

The register template is used by the CodeCard designer to map your name to your CodeCard id, if you choose to enter it.  Another post will detail how to install the CodeCard designer in an always free Oracle compute instance.  If you plan on implementing the designer, include this handler template and handler.  Even if you do not plan on implementing the designer, it won’t hurt anything to include these objects.

If you are piecing all of the above sections together you will need to execute a ‘COMMIT’ to save the changes to your database.  Or, you can use the following.

Full ORDS PL/SQL code

In a worksheet use the following code to create the Oracle REST Data Services API.

Setup a button press

One final piece of information you’ll need is your CodeCard’s id.

  1. Turn your CodeCard on.
  2. Press and release the A and B buttons at the same time.  Your CodeCard will display a barcode with a 12 character id string under it.
  3. Save that ID string.

Testing

POST

If you are using a tool such as Postman to test your API you will need to create a POST request with the following pieces.

  • URI:  {{URL from the prerequisite section}}/cc/functions/master
    For example: https://asdr34edyjtyi4j-codecard.adb.us-ashburn-1.oraclecloudapps.com/ords/cc/functions/master
  •  Headers
    • X-CODECARD-ID: Us the ID string from above
    • X-CODECARD-BUTTON-LABEL:  either ‘a’ or ‘b’
    • X-CODECARD-BUTTON-FUNCTION: use ‘1’ for a short press or ‘2’ for a long press
    • Content-Type: application/json
  • Body: use a JSON object like this
     

If you’d prefer to use a CURL command (replace the {{ }} sections with your values):

With either method, you should receive a response with a status of 200 and a JSON object in the body like this

Test GET

Assuming you completed the prerequisite section, you should be able to short or long press the A or B button on your CodeCard and your new template settings will be displayed on your screen.

You can also test the GET handler by sending a GET request to the same URI used above.  Use the same values for the headers, you do not need a body.

  • X-CODECARD-ID: Use the ID string from above
  • X-CODECARD-BUTTON-LABEL:  either ‘a’ or ‘b’
  • X-CODECARD-BUTTON-FUNCTION: use ‘1’ for a short press or ‘2’ for a long press

If you’d rather use CURL (replace the {{ }} sections with your values):

You should receive a JSON object like the one you sent in the body of your POST.

If the GET request works but your CodeCard doesn’t, go back to the prerequisite section and make sure you followed steps 4 and 5 correctly.

Have Fun

Once you get everything working you could experiment with changing the ORDS GET handler to do something else when a button is pressed.

  • Create a new table and log which button is pressed and if it’s a short or long press.
  • Run a query on a table and return the results in the bodytext.  (There are some size limits.)
  • Execute a stored procedure that does whatever you want it to do.
  • Make a different module/template/GET API for each button/press.

Create an Always Free Autonomous Database on the Oracle Cloud

You’ve signed up for the Oracle Cloud Free Tier at https://www.oracle.com/cloud/free/ and now you want to create an Always Free Autonomous Database.

Create a new Database

These instructions should work for both (ATP) Autonomous Transaction Processing and (ADW) Autonomous Data Warehouse Databases.

After you log into your Oracle Cloud Dashboard.

  1. Click on the “Create an ATP database” box. (Or the “Create an ADW database” box if you want a data warehouse)
  2. Choose the compartment you want to use.
  3. Fill in the “Display Name” field.  This name will be displayed in the GUI lists and drop down selection boxes in your Oracle Cloud dashboard.  You can change this later.
  4. Fill in the “Database Name” field.  This name will be used as the permanent ID for this database.  It will show up in places such as the auto-generated TNSNAMES.ORA file that you’ll download in another step.  You can not change this later, so choose wisely.
  5. In the “Choose a workload type” section, make sure the correct workload type is selected..
  6. Since we want to create an Always Free Database, leave “Shared Infrastructure” selected in the “Choose a deployment type” section.
  7. Make sure the “Always Free” selector is turned on.  This will lock in the options for an Always Free instance.  (20 GB of storage and 1 OCPU)
  8. Scroll down to the “Create administrator credentials” section and enter a Strong password for your Admin account.
    You will use the Admin account to connect to your Autonomous Database instead of SYS or System.
  9. Under the “Choose a license type” section make sure “License Included” is selected.
  10. Click the “Create Autonomous Database” button.

Your new ATP instance will be provisioned.  The orange box will turn green once it has been provisioned and is available to use.

While you’re waiting, check that you see the Always Free tag next to your database name.  If you do not see the tag, you may want to check to see what license you created the instance under and make sure you are OK with those options or terminate the instance and create a new one with the Always Free options selected.

Once the orange box turns green and your database is available, you will want to connect to it.

The Oracle Autonomous Cloud Databases are setup with a little extra security.  In order to connect you will need to use a wallet credentials file.

Download the Oracle Credentials file

There are a couple different ways to get the wallet file through the Cloud Dashboard.

From the Details page
    1. Click on the “DB Connection” button.
    2. On this form you will find a list of the auto-generated TNSNAMES entries and connection strings that you can use to connect to your database.  There is a link to the documentation explaining the difference between the entries.  For typical transactions I like to use the one ending in _TP.
    3. Click the “Download Wallet” button.
    4. Create a password that will be used to access the .zip file.
    5. Click the “Download” button.

      Remember the location where you save your wallet file, you will need it when we test the connection.
    6. Save the .zip file to a secure location.  This file is used to access your database so keep it secure.
From the Service Console

You can get to the Service Console for your Database instance either from the Details page

or from the menu for the instance in the Autonomous Transaction Processing Database list.

Once your in the service Console

  1. Click on “Administration”.
  2. Click on “Download Client Credentials (Wallet)”.
  3. Create a password that will be used to access the .zip file.
  4. Click the “Download” button.
Important Wallet Security Information

All wallets downloaded with either method will create a copy of the *SAME WALLET* even if you use different passwords for the .zip file.

You can rotate the wallet from your database instance details page.  Read the docs.

  1. Click the “DB Connection” button.
  2. Press the “Rotate Wallet” button and follow the instructions.

Connect to the Database

SQLcl is a great tool for making a quick and easy connection to the new database.

  1. Start SQLcl in ‘nolog’ mode
  2. Set the location of your .zip file in the cloudconfig variable.
  3. Connect to your database using the password you set for the Admin account.
  4. Run a test query

Enjoy

Your new Always Free Oracle Autonomous Database is running and you are able to connect.  Now you can start building your application.

If you have an questions please post them in the comments and I’ll do my best to help you find an answer.

How To Connect your Node.js app in Docker to your Oracle Database

In this post I’ll cover how to make a connection from a Node.js application in a Docker container to your Oracle Database in three different scenarios.

  • Typical Database connection.
  • Database inside a different Docker container.
  • Oracle Autonomous Transaction Processing Cloud Database.

Simple Test App

When attempting something new, I find it’s best to make sure all of the pieces that are not part of the new thing, are as simple as possible.

For my examples I will be using a small Node.js application that:

  • Connects to the Oracle Database.
  • Runs a simple query.
  • Prints the results to the console.

Create a new file named dbConfig.js to set the database connection information.

Create a new file named server.js used to test the connection.

Install the node-oracledb driver. (If you have any questions about the node-oracledb driver, you can find the answers here.)

Create environment variables for the connection information.  (Replace my values with yours)

Test the Node.js application.  You should see something similar to the following.

Create a Docker Container for the Node.js app

Create a Dockerfile

Build the image

Now that you have an image you’ll run a container and to connect it to:

Typical Oracle Database
The container will run, execute the query and stop.  You should see something similar to this output.
An Oracle Database inside a Docker Container

In a previous post I walked through how to setup both an ORDS instance and an Oracle XE instance in Docker Containers.  Follow through the section showing how to create an Oracle XE Database in a Docker container.

When you followed the steps in that post you should have also created a Docker Network.

You’ll use that same network to connect from the Node.js container to the Oracle XE container.

First, change your NODE_ORACLEDB_CONNECTIONSTRING environment variable to use the Oracle XE container name.

Now when you run a new docker container you will attach it to the same Docker Network as the Oracle XE container.

The container will run, execute the query and stop.  You should see something similar to this output.

Since both containers are using the same Docker network, you do not need to open the port when you run the Oracle XE container.  This is useful if you’d like to keep your database private inside the Docker environment.

Oracle Autonomous Transaction Processing Cloud Database

After you create an Oracle ATP Cloud Database you’ll need to download the credentials file and extract it into a secure location.

For this database, you will be using an entry in the tnsnames.ora file to make the database connection.  Change the NODE_ORACLEDB_CONNECTIONSTRING environment variable to use the tnsnames entry:

Before you run the container, you need to modify the sqlnet.ora file found in the credentials directory.  Change the wallet location to the value that will be mapped inside the Docker container.

When you run the new container for the node app you will map a volume from the directory where you extracted your credentials file to the internal container directory.  Mapping a volume makes sure that there is not a copy of the credential files inside the Docker container.

Finally, when you run the new container, you will add an additional environment variable defining where the tns admin information is located.

The full command looks like this:

The container will run, execute the query and stop.  You should see something similar to this output.

I used the same docker image for all of the examples

You may have noticed that you only built the Docker image once at the beginning of the post.  The application in the Docker image uses environment variables to connect to the database.  This allows you to run the same application in one or more containers and each container can connect to different Oracle Databases without having to rebuild the image.

Oracle REST Data Services on Autonomous Transaction Processing Database

Whenever I give a presentation, write a blog post or make a video I like to run all of my examples and demos locally and on an Oracle Cloud instance.  I keep a Virtual Box machine or Docker Container ready on my laptop, just in case I can’t get to the internet, but for speed and dependability, you just can’t beat a cloud instance.

I like to have some automation scripts handy to create and destroy my environments and depending on what I’m doing that can sometimes take a while.

So when Oracle’s Autonomous Transaction Processing Database was released I was excited by how fast I could spin up a new instance.  It takes a few minutes instead of around an hour for other options.  Oracle wanted to make sure ATP was solid, so they initially launched with a limited feature set and new features have been making their way into Oracle’s Autonomous Transaction Processing Database almost every month.

At KScope19 it was announced that Oracle REST Data Services is now available on ATP.

I was scheduled to give my ‘Creating REST APIs Is Fast, Easy, and Secure with Oracle REST Data Services‘ talk on Wednesday and I like to live dangerously, so I decide (Tuesday afternoon) to convert my demos over to ORDS on ATP.  I figured worst case, if I couldn’t figure it out I’d just use my Docker container.

It’s going to be hard… right?

I already had a couple of ATP instances that I use for stuff and things.  Since I wanted to do a live demo, I decided to spin up a new instance just in case I expose anything that could be used to get in.  It took under 5 minutes to fully create and start up a brand new ATP database.  After that, I downloaded my Client Credentials (Wallet) and connected with SQL Developer.  There are lots of examples for this part so I’ll move on to the new stuff.

New User

I try to do as little as possible as the Admin user so I created a rest_demo user with a couple of tables and a view.

Create a test API

Then I used the SQL Developer ‘Auto REST’ feature to REST enable the schema and a table.   (PL/SQL exported below in case you want to try it.)

Get the URI

Now I just needed the URI to test my new service.  Here are the steps:

  1. Log into your Oracle Cloud Dashboard.
  2. From the menu, select ‘Autonomous Transaction Processing’.
  3. From the instance menu, select ‘Service Console’.

    Or, Click on your Instance Name then Click the ‘Service Console’ button.
  4. Click ‘Development’.
  5. In the Rest Data Services box, click the “Copy URL” button.
Test it

For a simple fast test, I just used an internet browser with the following URI:
https://someIdstuff-blaineords.adb.my-region-1.oraclecloudapps.com/ords/api/cool_data

Well, that was easy.

To be honest I expected this to be a lot harder and that I’d have problems.  I ran through all of the demos for my presentation and they just worked, first try.

The thing I spent the most time on was re-checking everything.  Since it was so easy, I thought I had connected to one of my pre-existing cloud databases.

Go try it!

As always, don’t take my word for it, go try it yourself.

Here are some links to help get you going: