Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

We did testing before (see tag Testing), but also the testing market evolved with great new tools where two of them are (in my opinion) highly interesting to start learning. For this week, we have Gatling Java DSL on the planning; for next week, we’ll pick up on Playwright. Both are great tools, and the beauty is that you can program them both with Java.

Why not k6 (by Grafana) which comes with a great Studio? Well, because I want to have full control over the outcome (which I doubt on “Studio/Recording” tools). AND at heart I’m a Java enthusiast where k6 can only work with JavaScript.

Let’s jump into the head start of working with Gatling with a first setup to run a basic test. After that, we’ll add a next test to (at least) make an authentication call to OTDS, grab a SAML token, and do a call against our OPA solution!

Let’s get right into it…

My first question is where to start? Well, you can call Gatling via Java. This means we can simply create a new Java project in our favorite IDE (mine is the community edition of IntelliJ) where we create a new Maven-dependent Java project:

Next step is updating the pom.xml for this project to have the Gatling dependencies available for the project:

1
2
3
4
5
6
7
8

<dependencies>
    <dependency>
        <groupId>io.gatling.highcharts</groupId>
        <artifactId>gatling-charts-highcharts</artifactId>
        <version>3.15.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Once this is in place, you can craft a new Java class like below; I’ll craft it in the ‘test’ sources of the Maven project instead of the ‘java’ sources. This move just feels correct…this is the code-part:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package nl.bos;

import io.gatling.javaapi.core.Simulation;
import io.gatling.javaapi.http.HttpProtocolBuilder;

import java.time.Duration;

import static io.gatling.javaapi.core.CoreDsl.rampUsers;
import static io.gatling.javaapi.core.CoreDsl.scenario;
import static io.gatling.javaapi.http.HttpDsl.http;
import static io.gatling.javaapi.http.HttpDsl.status;

public class AppWorksTipsSimulation extends Simulation {

    public AppWorksTipsSimulation() {
        HttpProtocolBuilder httpProtocol = http.baseUrl("https://appworks-tips.com");

        setUp(scenario("OPA Simulation")
                .exec(http("Open homepage")
                        .get("/")
                        .check(status().is(200)))
                .injectOpen(rampUsers(10).during(Duration.ofSeconds(15)))
        ).protocols(httpProtocol);
    }
}

Why does Gatling use an extended Simulation class instead of JUnit tests!? A great question, but that’s because Gatling wants to know how the system behaves over a certain amount of time with X number of users. Playwright uses JUnit because it only needs to validate if a function is red or green.

This code will do 10 simple GET requests against your favorite blog site; this happens with 10 total virtual users over 15 seconds with this line of code: rampUsers(10).during(Duration.ofSeconds(15))
That’s a pretty powerful line; now check this table on the impact of requests:

After this quick implementation, you can run your first simulation via PowerShell after moving into the directory space of your new Java/Maven project: .\mvnw.cmd gatling:test "-Dgatling.simulationClass=nl.bos.AppWorksTipsSimulation"

First step is made, and Gatling creates (automagically) a nice report on the results in the target folder of your project:

NICEEEEEE! 😍

Time to continue our journey…

The authentication call against OTDS

Now that Gatling is working, we can also do a similar call to our OPA environment. So, boot up your VM and make a small project with a ‘Case’ entity to play with; just a one-prop entity is enough as we’ll use the Typed REST layer (in /app/admin) of the solution to call CRUD operations!

However, before we start, we always need a SAMLart token to communicate with OPA from an external system (our Java/Maven test-project!)

If you want to understand more about authentication against OPA, read this post.

Authentication happens in 2 steps. First, a call against OpenText Directory Services (OTDS) to grab a ‘Ticket’. Second, reuse that ‘Ticket’ to request a ‘SAML artifact’ token for further communication.

See this code-snippet for that first part in the same AppWorksTipsSimulation class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

public class AppWorksTipsSimulation extends Simulation {

    private static final String OTDS_AUTHENTICATION_URL = "http://192.168.56.102:8181/otdsws/rest/authentication/credentials";
    private static final String OTDS_USERNAME = "opadev";
    private static final String OTDS_PASSWORD = "admin";
    private static final String OTDS_TARGET_RESOURCE_ID = "296c66f2-c3cc-4c59-918e-883dbd882c22";

    public AppWorksTipsSimulation() {
        HttpProtocolBuilder httpProtocol = http
                .baseUrl("https://appworks-tips.com")
                .acceptHeader("application/json")
                .contentTypeHeader("application/json");

        setUp(scenario("OPA Simulation")
                .exec(http("Open homepage")
                        .get("/")
                        .check(status().is(200)))
                .exec(http("Authenticate with OTDS credentials")
                        .post(OTDS_AUTHENTICATION_URL)
                        .body(StringBody("""
                                {
                                  "userName": "%s",
                                  "password": "%s",
                                  "targetResourceId": "%s"
                                }
                                """.formatted(OTDS_USERNAME, OTDS_PASSWORD, OTDS_TARGET_RESOURCE_ID)))
                        .asJson()
                        .check(
                                status().is(200),
                                jsonPath("$.ticket").saveAs("ticket")
                        ))
                .exec(session -> {
                    System.out.println("ticket: " + session.getString("ticket"));
                    return session;
                })
                .injectOpen(rampUsers(10).during(Duration.ofSeconds(15)))
        ).protocols(httpProtocol);
    }
}

Notes:

• Update the OTDS_ variables for your environment
• You’ll find the target resource ID in OTDS (under ‘Resources’)
• Use credentials of a test-account with the proper roles applied for your solution!
• The result is a ‘ticket’ which we print in the console and save “in memory” for the next call

After another run, you should see a valid build with correct (and green) output (incl. a new report to check out):

1
2
3
4
5
6

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  16.986 s
[INFO] Finished at: 2026-06-02T23:49:02+02:00
[INFO] ------------------------------------------------------------------------

Mine is green, so let’s move on…

Grabbing a SAMLart value from OPA

The next call is a POST request to the OPA Gateway.wcp endpoint calling SOAP service Request with the correct XML body. Have a look at these parts to add in the AppWorksTipsSimulation class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

//The URL variable
private static final String SOAP_GATEWAY_URL = "http://192.168.56.102:8080/home/opa_tips/com.eibus.web.soap.Gateway.wcp";

//The executioner (watch the #{ticket} value!)
.exec(http("Get SAML artifact")
        .post(SOAP_GATEWAY_URL)
        .requestTimeout(Duration.ofSeconds(30))
        .header("Accept", "text/xml, application/xml")
        .header("Content-Type", "text/xml; charset=UTF-8")
        .body(StringBody("""
                <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
                    <SOAP:Header>
                        <OTAuthentication xmlns="urn:api.bpm.opentext.com">
                            <AuthenticationToken>#{ticket}</AuthenticationToken>
                        </OTAuthentication>
                    </SOAP:Header>
                    <SOAP:Body>
                        <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1" MinorVersion="1">
                            <samlp:AuthenticationQuery>
                                <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
                                    <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
                                </saml:Subject>
                            </samlp:AuthenticationQuery>
                        </samlp:Request>
                    </SOAP:Body>
                </SOAP:Envelope>
                """))
        .check(
                status().is(200),
                xpath("//*[local-name()='AssertionArtifact']").saveAs("assertionArtifact")
        ))
.exec(session -> {
    System.out.println("assertionArtifact: " + session.getString("assertionArtifact"));
    return session;
})

We again save and show the output. A test run will show this in the console during testing:

1
2
3

Simulation nl.bos.AppWorksTipsSimulation started...
ticket: *VER2*ABTLn...
assertionArtifact: e0pBVkEtQ...

Great, we’re still green…Now for that next call for your solution!

Create a new case

For this one, we use the automagically generated Typed REST services of the solution (our project with a ‘Case’ entity). You can access it via the /app/admin portal of the platform:

You’ll enter the SwaggerUI documentation to do your CRUD operations on the runtime entities:

Update the AppWorksTipsSimulation class with these 2 code snippets to create a new case in runtime:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

//The URL variable
private static final String CASE_ENTITY_URL = "http://192.168.56.102:8080/home/opa_tips/app/entityRestService/api/opa_tipsgeneric/entities/case";

//The executioner (watch the #{assertionArtifact} value!)
.exec(http("Create case entity")
        .post(CASE_ENTITY_URL)
        .header("Accept", "application/json")
        .header("Content-Type", "application/json")
        .header("SAMLart", "#{assertionArtifact}")
        .body(StringBody("""
                {
                    "Properties": {
                    "case_name": "string"
                    }
                }
                """))
        .asJson()
        .check(
                status().is(201),
                jsonPath("$.Identity.Id").saveAs("caseId")
        ))
.exec(session -> {
    System.out.println("caseId: " + session.getString("caseId"));
    return session;
})

After this run, it’s all green on the tests, but have a look in runtime now:

We have a case instance…Great! However, after testing you also want to clean up the mess…

Clean up the mess

Finally, we do one last update to clean up our mess…It’s as easy as this, reusing the URL of the previous call:

1
2
3
4
5

.exec(http("Delete case entity")
        .delete(CASE_ENTITY_URL + "/items/#{caseId}")
        .header("Accept", "*/*")
        .header("SAMLart", "#{assertionArtifact}")
        .check(status().is(204)))

That’s it…Do a full run now on your first set of Gatling tests. You’ll be fine with green checkmarks and a solid report to further investigate. This is also where the fun starts, and where you can extend things against your solution!

You’ll find the full class here

You’ll find my latest report run here

A well-earned DONE where we got a great head start on using Gatling Java DSL for your first performance/load testing requirements. Things don’t need to be hard to use; just a simple example can trigger your creativity to embrace these tools. Play with it, have fun with it, and we’ll chat on a next testing tool, next week! Cheers…

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The Process Automation guy”?