Testing the solution

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
• Postman

Using the OpenShift graphical user interface (GUI), select the Data Grid Administration Console URL (Figure 9).

Figure 9: Get Data Grid Administration Console URL.

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).

Figure 10: Data Grid Admin Console.

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).

Figure 11: Postman Collection.

Initially we check that there is no object present in the cache, either on site-1 or on site-2 (Figure 12).

Figure 12:  Initial cache state.

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).

Figure 13: POST request to create an employee.

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).

Figure 14: Employee replicated on site-2.

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).

Figure 15: Update employee to version 2 using Quarkus service on site-1.

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).

Figure 16: Import employee from cache into .NET service on site-1.

Figure 17: Import employee from cache into Golang service on site-2.

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).

Figure 18: Update employee to version 3 using Golang service on site-2.

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).

Figure 19: Data Grid Admin Console showing update for version 3.

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).

Figure 20: Employee query by uuid in Quarkus service.

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).

Figure 21: Error message for outdated employee in local base.

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).

Figure 22: Fetching the employee's internal identifier based on its uuid.

For the .NET service, this employee has the internal identifier 14. Let's use it to try to update the employee ( Figure 23).

Figure 23: Error message for outdated employee in local base.

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).

Figure 24: Updating local employee with data from cache.

Next, we check whether the local base has been properly updated with the latest version present in the cache (Figure 25).

Figure 25: Querying employee data.

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).

Figure 26: Update employee to version 4 using Quarkus service on site-1.

Well done. The version is up to date and we can see it in the cache as shown below ( Figure 27).

Figure 27: Cache state after update to version 4.