1.10.3 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:

1. Create a Java Keystore containing the database password
2. Create a PGX graph configuration file describing the location and properties of the graph to be loaded
3. 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",
    ...
  }