Now that we have deployed the applications and properly configured the Red Hat Data Grid cluster, let's try some scenarios and prove the cross-site replication functionality of the Data Grid.
To test the applications and validate the results, we will use these tools:
- Data Grid Administration Console
Using the OpenShift graphical user interface (GUI), select the Data Grid Administration Console URL (Figure 9).
Another alternative is to use the OpenShift Client and perform a query directly on the cluster:
oc get route dg-external -o=custom-columns=HOST:.spec.host --no-headers
Access the console URL on each site and use one of the credentials present in the identities.yaml file. Below we have the Data Grid administration console side-by-side for both sites (Figure 10).
Below is an example of Postman's collection for consuming the service's APIs. This collection is available in the source code repository for this article (Figure 11).
Initially we check that there is no object present in the cache, either on site-1 or on site-2 (Figure 12).
Scenario 1: Create an employee through the Quarkus service on site-1 and validate entry on the site-2 cluster
Let's send a request to create an employee through Postman (Figure 13).
After employee creation, we observed that the employee was successfully created and immediately replicated from site-1 to site-2 using uuid as a key (Figure 14).
Scenario 2: update employee on site-1 quarkus service and watch version change
Now let's update the employee to version 2 via the Quarkus service on site-1 (Figure 15).
We can see that the version has been changed to 2
Note: Check the updated By and employee version attributes after the update.
Scenario 3: Import employee from cache in .Net service from site-1 and Golang service from site-2
Now let's import from the cache the employee in the .Net service of site-1 and Golang in site-2. We will do this using the uuid attribute that is used as a key in the Data Grid (Figure 16).
Note: Note that each service has its own way of managing an identifier for the employee.
Note: As the Golang service uses a MongoDB database, we chose to use the Identifier automatically generated by the bank and therefore the numbering differs from other services. It is up to each service how to manage an internal identifier or even opt for the entity's uuid.
Scenario 4: Upgrade the employee to version 3 through the Golang service deployed on site-2
Right now, all services have the latest version of the employee, version 2, let's update the employee to the next version using the Golang service deployed on site-2 (Figure 18).
We can check in the Data Grid Administration Console that in both sites the employee has been updated and has version 3. Observe the updatedBy attribute proving that the last update was made by the Golang service in site-2 (Figure 19).
Scenario 5: Trying to update an outdated employee in the local database
Now let's use the Quarkus service to try to update the employee.
Before updating, let's retrieve its internal identifier based on the uuid (which is the key used by the Data Grid) ( Figure 20).
The internal code for the employee is 23, let's use this identifier to try to update this employee and see what happens ( Figure 21).
The application responds with a response 400 status and a very clear message. This is exactly the behavior we want. Through the cache we can keep updates on entities in a very agile way without relying on database replication.
This behavior is especially valuable when heterogeneous applications need to share data and need some concurrency control over this data.
Let's try to follow the same steps with the .NET service published on site-1 and see if the same behavior is repeated (Figure 22).
For the .NET service, this employee has the internal identifier 14. Let's use it to try to update the employee ( Figure 23).
This is an expected error. A good sign for us. It means that the applications are working exactly as expected.
Just as the local Quarkus database, in this case a Postgres, is outdated, so is the .NET database, a SQL Server.
In this way, both services need to update their local base before being able to carry out any operation on this employee.
Scenario 6: Updating the local base and performing operations on the employee
For this scenario we will use the Quarkus service deployed on site-1.
First let's update the local user with the data present in the cache ( Figure 24).
Next, we check whether the local base has been properly updated with the latest version present in the cache (Figure 25).
The employee has been successfully updated in the local database.
From now on, the application is able to update the employee. To prove this, let's make one more change to the employee and observe the results ( Figure 26).
Well done. The version is up to date and we can see it in the cache as shown below ( Figure 27).