Oracle GoldenGate From On-Premises to OCI DBCS – Part 4: Connecting On-Premises GoldenGate to OCI using NGINX and Creating Extract & Replicat

Introduction

This is Part 4 of a four-part blog series on replicating data from an on-premises Oracle Database to Oracle Cloud Infrastructure (OCI) using Oracle GoldenGate.

In this final blog, we focus on establishing secure connectivity between the on-premises and OCI GoldenGate environments using NGINX. Once connectivity is in place, we create and configure the Extract and Replicat processes to enable real-time data replication from the on-premises source to the OCI target database.

Related blogs in this series:

• Part 1: Configuring the Source Environment
• Part 2: Configuring the Target Environment on OCI
• Part 3: Connecting On-Premises GoldenGate to Source and OCI GoldenGate to Target Database

Create a trusted connection 

The following image demonstrates what should be configured to establish secure connectivity between the on-premises and OCI GoldenGate deployments.

What is WSS?

The WSS (WebSocket Secure) protocol is used in Oracle GoldenGate Distribution Path configuration to enable secure, encrypted data transfer over WebSocket using TLS (Transport Layer Security).

When you configure a Distribution Path in GoldenGate Microservices, you specify a Target URL. To enable encryption, it should look like this:

wss://<host>:<port>/services/v2/receivers/<receiver-name>

Requirements for wss:// to work:

•  A valid SSL/TLS certificate on the target (can be self-signed or signed by a CA).
•  Proper Nginx reverse proxy configuration, terminating or forwarding the TLS connection.
•  OCI GoldenGate receiver created and configured to accept WSS connections.
•  Any firewall or network rules must allow port 443 (or a custom secure port).

Step 1: Create a User in the Target Deployment for source Oracle GoldenGate Access

In the target deployment, create an administrator user named ggnet to be used for connectivity.

Go to the Admin Client for the target OCI GoldenGate deployment, navigate to Administrator from the menu, click + to add a user, set the user type to Operator, and use Amir123! as the password.

Now, the ggnet user has been created

Step 2: Create a Credential in the Source Oracle GoldenGate Using the Same Credentials

In the source (on-premises) GoldenGate deployment, open the Administration Service, navigate to Configuration, and click + to add a new credential. In the User ID field, enter the user created in the target deployment (ggnet) and specify the same password.

Now, the credential has been created.

Step 3: Generate a Client Certificate for the Source Deployment Using OpenSSL

We require a certificate to establish a WSS path for secure communication between the on-premises source system and the target OCI environment.

First, create a configuration file. Using this file, we can then generate the certificate. In the configuration file, be sure to specify the hostname on the last line.

[oracle@src ~]$ pwd
/home/oracle

[oracle@src ~]$ hostname
src.amir.net

[oracle@src ~]$ vi genkey.conf
[ req ]
distinguished_name = DN
x509_extensions = V3
prompt = no

[DN]
CN = src.amir.net

[V3]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:TRUE
subjectAltName = "DNS:localhost,DNS:src,DNS:src.amir.net,DNS:127.0.0.1,IP:127.0.0.1"

To create the certificate files (the private key and the .pem certificate), I used the following command. 

[oracle@src ~]$  openssl req -newkey rsa:2048 -nodes -keyout src.key -new -x509 -days 3650 -out src.pem -config ./genkey.conf
Generating a 2048 bit RSA private key
       
[oracle@src ~]$ ls
dis_client.pem    dist_client.key    genkey.conf

we can see the output of this OpenSSL-created file using the openssl x509 -in src.pem -text command. In the following output, you can see Isuuer and subject CN name, which are the same as src.amir.net

Step 4: Add the source certificate to the source GoldenGate deployment.

Now, go to the Service Manager in your on-premises GoldenGate environment, then navigate to Certificate Management. Make sure you select your deployment from the Deployment Name drop-down list (not the Service Manager).

Click + under Client Certificates. Use cat src.pem to display the certificate, then copy and paste the entire content into the Certificate PEM field. Next, use cat on the private key file and copy and paste the entire content into the Private Key field. Since this is a self-signed certificate, you do not need to enter anything in the CA Certificates field.

Click add, now the client certificate has been added to the source GoldenGate deployment.

Step 5: Add the dest certificate to the source GoldenGate deployment.

In the browser used to access the target (OCI) GoldenGate Console (for example, Chrome), download the root certificate. Then, in the on-premises GoldenGate Service Manager, navigate to Distribution, ensure the correct deployment is selected, click + under CA Certificates, and upload the downloaded certificate file.

Click the Upload button, then the Add button.
Note: It’s important to understand the difference between Shared and Local options. If you select Shared, the digital root certificate is shared across all deployments, meaning you don’t need to add it to other deployments. If you select Local, the certificate is added only to the current deployment. In this example, I selected Local and then saved it.

Now, both the source and the destination certificates have been added to the source (on-premises) GoldenGate deployment.

Create the extract at the source.

In Blog 3 of this series, we created the CDB and PDB credentials and added the TRANDATA schema at the PDB level. With these steps completed, we can now add the Extract process. In the On-Premises GoldenGate Administration Service, go to Overview and click + to add the Extract.

On the opening page, I set the following parameters:

• Process Name: exthr
• Description: Extract from on-premises to OCI
• Intent: Unidirectional
• Begin: Now
• Trail Name: ef
• Trail Subdirectory: (leave blank)
• Trail Size (MB): 50
• Trail Sequence: 0
• Trail Offset: 0

Select the CDB and PDB credentials that we created in blog 3.

Note: I created the table below in the HR schema on both the source and destination PDBs and used it to test Oracle GoldenGate replication.

CREATE TABLE TBL_GGTEST 
(
  ID NUMBER(8) 
, VALUE VARCHAR2(10) 
, CONSTRAINT TABLE1_PK PRIMARY KEY 
  (
    ID 
  )
  ENABLE 
);

The following is the Extract command I used in my test, which captures both DDL and DML changes.

EXTRACT exthr
USERIDALIAS cdbggsrc DOMAIN OracleGoldenGate
EXTTRAIL ef
DDL INCLUDE MAPPED 
DDLOPTIONS REPORT 
TABLE pdb1.hr.TBL_GGTEST;

Now, we can start the Extract, which will register it with your database.

Now, the Extract has been started.

Create the path

Open the on-prem Oracle GoldenGate distribution service and click + button.

For the target host, we can copy it from the OCI Goldengate browser

The port is set to 443. The target trail is the trail name that will be referenced by the Replicat process. In this example, I used rf, and the Replicat trail file will also be named rf.

For the Domain and Alias, use the ggnet credential information created earlier. You can copy and paste these values from the previously created credentials.

All other fields can be left with their default values, then click Create Path.

Now, the path is created

If I check the OCI GoldenGate Console, I can see the path listed under Receiver Paths.

Create a Replicat in the Target OCI GoldenGate Deployment Console

First, connect using the PDB credential and create the checkpoint table in the OCI GoldenGate Console

The checkpoint table has been added

Go to the OCI GoldenGate deployment, click Actions, and select Launch Administration Client.

Now, we can add replicat.

Choosing Nonintegrated provides better performance.

For credential alias use PDB credentials.

The following is the Replicat command I used in my test.

REPLICAT hrrep
USERIDALIAS C2DBCSPDB DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
BATCHSQL
MAP PDB1.HR.TBL_GGTEST, TARGET DESTPDB.HR.TBL_GGTEST;

The Replicat has been created, and we can now start it.

Conclusion

In this final part of the series, we completed the end-to-end Oracle GoldenGate replication setup between the on-premises source database and the OCI target database. We configured NGINX to enable secure communication between the two GoldenGate deployments and created the Extract and Replicat processes to capture and apply transactional changes.

With all components now fully configured—source environment, target environment, database connections, secure networking, and replication processes—you have a complete and functional architecture for replicating data from on-premises to OCI using Oracle GoldenGate. This four-part series provides a practical, step-by-step reference that can be adapted for real-world hybrid and cloud migration scenarios.