GoldenGate Microservices Operations: Connecting, Listing Deployments, and Creating Database Connections

Classic GoldenGate has one entry point: GGSCI. Microservices has three — adminclient (a scriptable CLI purpose-built for MA), direct REST calls, and the Service Manager Web UI. This post covers the CLI and REST paths for the operations you’ll do constantly: connecting to a deployment, seeing what’s running, and setting up database connections that Extract and Replicat processes can reuse.

1. Connecting with Adminclient

adminclient ships alongside the Microservices install and is the closest equivalent to opening GGSCI — except it talks to the Service Manager over REST instead of operating on local files directly.

$GG_HOME/bin/adminclient

OGG (not connected) > CONNECT https://ggms01.internal:9011 AS oggadmin PASSWORD ********
Connected to https://ggms01.internal:9011

OGG (Service Manager) >

For scripted/non-interactive use, pass the connection details and a command in one shot:

$GG_HOME/bin/adminclient \
  -c "CONNECT https://ggms01.internal:9011 AS oggadmin PASSWORD $OGG_PWD" \
  -c "INFO SERVER"

The REST equivalent of establishing a session is authenticating against the Service Manager root endpoint — every subsequent call carries basic auth (or a bearer token, if OAuth2 is configured) rather than a persistent connection:

curl -u oggadmin:Password1 https://ggms01.internal:9011/services/v2

2. Listing Deployments

A single Service Manager can host multiple deployments (e.g., production, dr, staging), each with its own set of services and processes. Before doing anything else, confirm which deployment you’re working in.

OGG (Service Manager) > LIST DEPLOYMENTS

Deployment    Status    Description
production    RUNNING   Primary CDC pipeline
staging       RUNNING   Pre-prod validation
dr            STOPPED   DR standby deployment

REST equivalent:

curl -u oggadmin:Password1 https://ggms01.internal:9011/services/v2/deployments

{
  "deployments": [
    { "name": "production", "status": "running" },
    { "name": "staging", "status": "running" },
    { "name": "dr", "status": "stopped" }
  ]
}

3. Connecting to a Specific Deployment

Once you know which deployment you need, connect into it — this is the step that shifts commands from Service-Manager-level (deployments, services) to deployment-level (Extracts, Replicats, connections):

OGG (Service Manager) > CONNECT https://ggms01.internal:9011 DEPLOYMENT production AS oggadmin PASSWORD ********
Connected to deployment 'production'

OGG (production) >

OGG (production) > INFO SERVICES

Service                    Status
Administration Server      RUNNING
Distribution Server        RUNNING
Receiver Server            RUNNING
Performance Metrics Server RUNNING

REST equivalent for service status within a deployment:

curl -u oggadmin:Password1 \
  https://ggms01.internal:9011/production/services/v2/config/health

4. Creating a Database Connection

This is the piece that has no real equivalent in Classic — instead of embedding credentials directly in a parameter file, Microservices lets you register a Connection: a named, reusable database credential that any Extract or Replicat in the deployment can reference. It’s stored via the credential store, not in plaintext.

OGG (production) > ADD CONNECTION source_orders_db, ↩
    USERID ggadmin, PASSWORD ******** ↩
    ORACLE ↩
    CONNECTINFO "//ora-prod-01.internal:1521/ORDERSDB"

OGG (production) > INFO CONNECTION source_orders_db

Connection: source_orders_db
Type: ORACLE
ConnectInfo: //ora-prod-01.internal:1521/ORDERSDB
Credential: (stored in credential store)
Status: VALID

REST equivalent (POST to the connections endpoint):

curl -u oggadmin:Password1 -X POST \
  https://ggms01.internal:9011/production/services/v2/connections \
  -H "Content-Type: application/json" \
  -d '{
    "name": "source_orders_db",
    "type": "oracle",
    "connectionString": "//ora-prod-01.internal:1521/ORDERSDB",
    "userId": "ggadmin",
    "password": "********"
  }'

Listing and Validating Connections

OGG (production) > LIST CONNECTIONS

Name                  Type      Status
source_orders_db      ORACLE    VALID
target_reporting_db   ORACLE    VALID
kafka_analytics       KAFKA     VALID

OGG (production) > VALIDATE CONNECTION source_orders_db
Connection 'source_orders_db' validated successfully.

Validating before wiring it into an Extract catches credential and network-reachability problems early, rather than discovering them as an Extract abend later.

Using a Connection When Adding a Process

Once a connection exists, Extracts and Replicats reference it by name instead of embedding a connect string:

OGG (production) > ADD EXTRACT ext_orders, INTEGRATED TRANLOG, ↩
    CONNECTION source_orders_db, BEGIN NOW

This is also what makes credential rotation manageable at scale — updating a Connection’s stored password in one place takes effect for every Extract/Replicat referencing it, rather than hunting through parameter files.

5. Removing a Connection

OGG (production) > DELETE CONNECTION kafka_analytics

Microservices will refuse deletion if any Extract or Replicat still references the connection — a useful safety check that Classic’s file-based credentials never had.

Quick Reference: Adminclient vs REST

Summary

The pattern in Microservices is consistent at every level: connect to the Service Manager first, select a deployment, then operate within it — and everything you’d type in adminclient has a direct REST equivalent, which is what makes this architecture the natural fit for CI/CD pipelines and infrastructure-as-code. Connections are the piece worth internalising early: registering credentials once and referencing them by name, rather than duplicating connect strings across every Extract and Replicat parameter set, is the biggest day-to-day operational difference from Classic.