Using Oracle Graph with the Autonomous Database

2 Using Oracle Graph with the Autonomous Database

Oracle Graph with the Autonomous Database allows you to create property graphs from data in your Autonomous Database.

When using Autonomous Database Serverless deployment, you can use Graph Studio, a fully managed service with a powerful user interface for developing applications that use graph analysis. Using Graph Studio, you can automate the modeling of graphs from tables in Autonomous Database. You can interactively analyze and visualize the graph queries using advanced notebooks with multiple visualization options. You can execute over 60 built-in graph algorithms in Graph Studio to gain useful insights on your graph data. See Using Graph Studio in Oracle Autonomous Database for more information.

You can also access few Graph Studio features using the Autonomous Database Graph Client API using the client shell CLIs or through your Java or Python application. See Using Autonomous Database Graph Client for more information.

Alternatively, you can use any version of Oracle Graph Server and Client with the family of Oracle Autonomous Database to create and work with property graphs. This includes any version of Oracle Autonomous Database Serverless or Oracle Autonomous Database Dedicated. You can always upgrade to the latest version of Graph Server and Client regardless of the version of your Autonomous Database. Note that the graph server is managed by the application in this case.

You can connect in two-tier mode (connect directly to Autonomous Database) or three-tier mode (connect to PGX on the middle tier, which then connects to Autonomous Database).

The database schema storing the graph must have the CREATE SESSION and CREATE TABLE privileges.

Two-Tier Deployments of Oracle Graph with Autonomous Database
In two-tier deployments, the client graph application connects directly to the Autonomous Database.
Three-Tier Deployments of Oracle Graph with Autonomous Database
In three-tier deployments, the client graph application connects to PGX in a middle tier, and PGX connects to the Autonomous Database.

Related Topics

Using Autonomous Database Graph Client

Parent topic: Getting Started with Oracle Property Graphs

2.1 Two-Tier Deployments of Oracle Graph with Autonomous Database

In two-tier deployments, the client graph application connects directly to the Autonomous Database.

Install Oracle Graph Client, as explained in Installing the Java Client From the Graph Server and Client Downloads.
Establish a JDBC connection, as described in the Oracle Autonomous Warehouse documentation.
You must download the wallet and unzip it to a secure location. You can then reference it when establishing the connection as shown in Example 2-1.
Start the Java Shell as shown in the code:
```
/bin/opg4j --no_connect
```
Connect to your database as shown in Example 2-1.

Note:

If you need to use the Graph Visualization Application, you must additionally install the Oracle Graph Server.

See Installing Oracle Graph Server for more details.
See Running the Graph Visualization Web Client for more details.

Example 2-1 Creating a Database Connection in a Two-Tier Graph Deployment with Autonomous Database


opg4j> var jdbcUrl = "jdbc:oracle:thin:@<tns_alias>?TNS_ADMIN=<wallet_location>" // jdbc url to the DB
opg4j> var user = "<user>"
opg4j> var pass = "<password>"
opg4j> var conn = DriverManager.getConnection(jdbcUrl, user, pass) // connecting to the DB
conn ==> oracle.jdbc.driver.T4CConnection@57e6cb01

In the preceding example:

<tns_alias>: TNS alias used in tnsnames.ora file
<wallet_location>: Path to the directory where the wallet is stored
<user>: Name of the database user
<password>: Password for the user

Parent topic: Using Oracle Graph with the Autonomous Database

2.2 Three-Tier Deployments of Oracle Graph with Autonomous Database

In three-tier deployments, the client graph application connects to PGX in a middle tier, and PGX connects to the Autonomous Database.

The wallets downloaded from the Oracle Cloud Console are mainly routing wallets, meaning they are used to route the connection to the right database and to encrypt the connection. In most cases, they are not auto-login wallets, so they do not contain the password for the actual connection. The password usually needs to be provided separately to the wallet location.

The graph server does not support a wallet stored on the client file system or provided directly by remote users. The high level implications of this are:

The server administrator provides the wallet and stores the wallet securely on the server's file system.
Similar to Java EE connection pools, remote users will use that wallet when connecting. This means the server administrator trusts all remote users to use the wallet. As with any production deployments, the PGX server must be configured to enforce authentication and authorization to establish that trust.
Remote users still need to provide a user name and password when sending a graph read request, just as with non-autonomous databases.
You can only configure one wallet for each PGX server.

Having the same PGX server connecting to multiple Autonomous Databases is not supported. If you have that use case, start one PGX server for each Autonomous Database.

Pre-loaded graphs

To read a graph from Autonomous Database into PGX at server startup, follow the steps described in Store the Database Password in a Keystore to:

Create a Java Keystore containing the database password
Create a PGX graph configuration file describing the location and properties of the graph to be loaded
Update the /opt/oracle/graph/pgx.conf file to reference the graph configuration file

As root user, edit the service file at /etc/systemd/system/pgx.service and specify the environment variable under the [Service] directive:

Environment="JAVA_OPTS=-Doracle.net.tns_admin=/etc/oracle/graph/wallets"

Make sure that the directory (/etc/oracle/graph/wallets in the preceding code) is readable by the Oracle Graph user, which is the user that starts up the PGX server when using systemd.

In addition, edit the ExecStart command to specify the location of the keystore containing the password:


ExecStart=/bin/bash start-server --secret-store /etc/keystore.p12

Note:

Please note that /etc/keystore.p12 must not be password protected for this to work. Instead protect the file via file system permission that is only readable by oraclegraph user.

After the file is edited, reload the changes using:

systemctl daemon-reload

Finally start the server:

sudo systemctl start pgx

On-demand graph loading

To allow remote users of PGX to read from the Autonomous Database on demand, you can choose from two approaches:

Provide the path to the wallet at server startup time via the oracle.net.tns_admin system property. Remote users have to provide the TNS address name, username and keystore alias (password) in their graph configuration files. The wallet is stored securely on the graph server's file system, and the server administrator trusts all remote users to use the wallet to connect to an Autonomous Database.

For example, the server administrator edits the service file at /etc/systemd/system/pgx.service and specifies the environment variable the under the [Service] directive:
```
Environment="JAVA_OPTS=-Doracle.net.tns_admin=/etc/oracle/graph/wallets"
```
and then start the server using
```
systemctl start pgx
```
The /etc/oracle/graph/wallets/tnsnames.ora file contains an address as follows:
```
sombrero_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=l8lgholga0ujxsa_sombrero_medium.adwc.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adwc.uscom-east-1.oraclecloud.com,OU=Oracle BMCS US,O=Oracle Corporation,L=Redwood City,ST=California,C=US")))
```
Now remote users can read data into the server by sending a graph configuration file with the following connection properties:
```
{
  ...
  "jdbc_url": "jdbc:oracle:thin:@sombrero_medium",
  "username": "hr",
  "keystore_alias": "database1",
  ...
}
```
Note that the keystore still lives on the client side and should contain the password for the hr user referenced in the config object, as explained in Store the Database Password in a Keystore. A similar approach works for Tomcat or WebLogic Server deployments.
Use Java EE connection pools in your web application server. Remote users only have to provide the name of the datasource in their graph configuration files. The wallet and the connection credentials are stored securely in the web application server's file system, and the server administrator trusts all remote users to use a connection from the pool to connect to an Autonomous Database.
You can find instructions how to set up such a data source at the following locations:
- WebLogic Server: Configuring a WebLogic Data Source to use ATP
- Tomcat: https://www.oracle.com/technetwork/database/application-development/jdbc/documentation/atp-5073445.html#Tomcat
If you gave the data source the name adb_ds, you can the reference them by sending a graph configuration file with the following connection properties:
```
{
  ...
  "datasource_id": "adb_ds",
  ...
}
```

Parent topic: Using Oracle Graph with the Autonomous Database