Messaging Platform Test Simulator Sample¶

Communication confirmation test¶

It can be used as a destination system for simple communication in the communication test to confirm the configuration of Nablarch application framework, middleware, hardware, etc. after building the test environment.

Combined test¶

It can be used as a pseudo counterpart system for inter-system communication confirmation during application integration test. By using the simulator to set the data to be used as the request message/response message, the test using the scenario can be performed.

While testing using scenarios is possible in a subfunction unit test, testing using a simulator is different in that it is possible to confirm the operation of the OS and middleware.

Load test¶

It is possible to send and receive a large number of messages to apply a load when performing an application load test.

Test data can be created in the same way as subfunction unit testing¶

The test data used in this simulator can be created in the same way as the subfunction unit test. Therefore, no extra learning cost is incurred when using this simulator.

Supports special and complex test cases by customizing (message reception)¶

By modifying the source code of the provided simulator, the following tests can be performed for special and complex test cases.

• Perform a test that needs to dynamically change the content of the response message according to the content of the request message.
• Perform an abnormal pattern test by intentionally delaying the response time to cause a timeout.

Capable of sending request messages in multiple threads (message sending)¶

The multi-thread execution control handler of Nablarch application framework is used inside the simulator. By sending a request message with multi-thread, it is possible to perform a load test that sends a large number of messages.

When the simulator receives a message¶

• It is possible to send response messages on receiving HTTP messages and MOM receiving synchronous message.
• It is possible to output a log of the request message.
• Can return any HTTP status code.
• It is possible to send response messages according to the order of requests to the simulator (similarly to the unit test, the contents described in the Excel file are returned in order from the top).

When the simulator sends a message¶

• Request messages for sending HTTP messages, MOM sending synchronous message, and MOM sending asynchronous message can be sent.
• Send the same message a specified number of times.
• The response message log can be output.
• The contents described in the Excel file can be sent sequentially.

Create a simulator execution module¶

In this sample, it is assumed that the user will customize the Java file etc. in order to carry out the intended test, so the source code and configuration file are provided as samples.

Therefore, in order to use the simulator, it is necessary to execute a build and create an execution module according to the following procedure.

Getting a simulator

Execute the following command to get the source code of the simulator.

git clone https://github.com/nablarch/nablarch-messaging-simulator.git

Creating an execution module

Execute the following command to create an execution module under target/build.

mvn clean dependency:copy-dependencies -DoutputDirectory=target/build/lib package

The created execution module is placed in the environment where the simulator is to be executed.

Start the simulator¶

The simulator is started by executing the following bat file included in the execution module.

Specify the number of times to send a request when sending a message¶

By default, the requests for the line count described in the send list file (CSV) are sent, and the request send count can be specified with the sendCount option to send the same data repeatedly.

An example for specifying options is shown below.

java <omitted> nablarch.fw.launcher.Main <omitted> -sendCount 10000

Switch the response according to the type of request when receiving a message¶

To switch responses based on the request type, modify the getRequestId method of the action class.

Implementation example when switching the response by request URI when receiving HTTP message is shown below.

public class HttpIncomingSimulateAction implements Handler<HttpRequest, HttpResponse> {

    // Omitted

    protected String getRequestId(HttpRequest request) {
        // Switch the request ID of the response based on the request URI.
        return request.getRequestUri().endsWith("RM11AC0101") ? "RM11AC0201" : "RM11AC0202";
    }
}

Intentionally delay the response when receiving a message¶

To delay the response intentionally when receiving a message, implement the delay process directly in the handle method of action class as follows.

public class HttpIncomingSimulateAction implements Handler<HttpRequest, HttpResponse> {

  public HttpResponse handle(HttpRequest request, ExecutionContext context) {

      try {
          // Delay for 10 seconds
          TimeUnit.SECONDS.sleep(10);
      } catch (InterruptedException e) {
          // Exception handling
      }

      // Omitted
  }
}