goldengate bug

Earlier today, I have been working on a few GoldenGate Obey files that will setup a customer’s environment; that is until I ran into an issue with AdminClient. I’m hoping this issue is more of a design overlook than a bug, but let’s see after this post is done. With the shift to everything in the cloud and Oracle GoldenGate moving more and more into microservices, this opens up a remote administration for users. To take this the next step, I built a Docker Container that runs Oracle GoldenGate 21c AdminClient (here). I also wrote about this back in March 2022 (here) . Using AdminClient in this way, I can have a free standing version of AdminClient that allows me to connect to local Oracle GoldenGate implementations, remote or cloud based implementations, and OCI GoldenGate Services. Would highly recommend you take a look at this approach as well. While I was working with AdminClient in writing some obey files, I identified that the below command does something unexpected: connect https://goldengate.rheodata.com deployment dep_ctmsbob_ft2 as oggadmin password WElcome09876^^ ! ADD CREDENTIALS EUDB USER ggate@rd.sub.demovnc.oraclevcn.com:1521/PDBTST_iad1hs.sub.demovnc.oraclevcn.com PASSWORD “WElcome09876^^ The ADD CREDENTIALS command, when ran in a local AdminClient updates the local wallet not the credential store within the deployment. This is documented in the documentation (here): Note: The ADD CREDENTIALS command adds a new username and password to an Oracle wallet that resides on the same system where the Admin Client is running. This credential is used to log in to Oracle GoldenGate Service Manager and Admin Client command line using the CONNECT command. Now that I have a better understanding on where it is running or going to be stored at, lets take a look and see what it would look like: 1. Start AdminClient (Dockerized) docker run -it --rm --memory=2048M --platform linux/amd64 --hostname=GG21c-Admin --name AdminClient rheodata/adminclient:latest 2. Login to the deployment using AdminClient connect https://**********.rheodata.com deployment dep_*******_ft2 as oggadmin password WElcome******** ! 3. Review the credential store -> INFO CREDENTIALSTORE. Notice that I have two credentials already in the credential store. This aligns with what I have in the credential store via the HTML5 interface page as well: At this point, I would think that when I create another credential it will show up in the credential store for the deployment. 4. Add another credential ADD CREDENTIALS EUDB USER ggate@rd.sub.demovnc.oraclevcn.com:1521/***TST_iad1hs.sub.demovnc.oraclevcn.com PASSWORD “WElcome******* This will return successfully an say the credential was added. 5. Check the credential store again -> INFO CREDENTIALSTORE Notice that we do not have an alias in the credential store called EUDB. What this means is that the AdminClient (locally running) cannot directly update the credential store of a deployment. So where is it? Per the documentation, as pointed out earlier, since the AdminClient is running locally, the credential was created locally in a local wallet. After clearing the screen, I can run INFO CREDENTIALS * and will see the alias I would have expected in the deployment. This issue is either an undocumented bug or a gap in the product. I come to this conclusion because if I was to use a standard cURL command against the API for creating credentials, the credentials are added to the deployment without any issue. At this point, I’m going to turn message the team at Oracle and see if they can provide a reason why the product behaves this way. Enjoy!! **** UPDATE **** Follow up from conversation with Oracle – 9/13/2023: After posting this post, I was able to connect with a few friends at Oracle. They pointed out the exact difference with the approach of how the credential store is used. Within the Microservices Architecture (on-premise and cloud), the credential store is pre-allocated and ready to use within the microservices frame work. This means to provide connection details for an alias from a localized AdminClient, we just need to use ALTER CREDENTIALSTORE. If we use the command ADD CREDENTIALS, AdminClient will create a new credential store locally and not update the existing credential store in deployment. The correct command that should be followed when working with a remote deployment (on-premise or cloud), we just need to use ALTER CREDENTIALSTORE. alter credentialstore add USER ggate@rd.sub.demovnc.oraclevcn.com:1521/PDBTST_iad1hs.sub.demovnc.oraclevcn.com alias EUDB domain OracleGoldenGate PASSWORD “********* After execution, the new alias will appear in the AdminSrvr -> Configuration page.

goldengate bug

AdminClient – ADD CREDENTIAL doesn’t do what you expect!

Recent Posts

Stop Managing Port Numbers. Start Managing Data.

GenAI: How to get started

Basic DDL Replication with Oracle GoldenGate

Posts by Tag

Links