Testing

Description

Testing section

Testing Section will facilitate monitoring of the functioning of some components of GreenVulcano^® ESB, exploiting the potential of the web. The passage of data and their possible change is in fact visually displayed.

In this area the user can compile an input object and display output from the execution of the service. The input object, such as the output, changes depending on the requested test.

GV Console Configuration

Testing is a Web application that provides a GreenVulcano^® ESB service invocation simulating a client request.

In this area you can test the services already configured.

The configurable tests in Testing Area are related to the following sub-systems:

• Core to test the direct call to the EJB of GreenVulcano’s Core.

The testing process is divided into three steps:

• Data input
• Testing output
• Exceptions

Data input

GV Console Testing data

For a test that accepts a GVBuffer input object the display appears as shown in the following figure:

GVBuffer input Object has default values already set as Id but can be inserted by the user, or been generated using the "getId" function. In the case of insertion by the user, we recall the normal rules for generating the ID (unless you want to test the case of incorrect ID insertion):

• Length of 24 hex digits.
• Must contain only upper case letters from A to F.
• Not end with 0000.

If user enters incorrect values, the application will however attempt to follow the test and returns an exception.

All the text box for entering input GVBuffer values are still editable. These values are:

• Output File Name: name of the file where the test output will be saved;
• Input File Name: name of the input file containing the serialized GVBuffer;
• Iterator Number: number of invocations to be run using the same payload;
• ID: transition unique identifier;
• Service: name of the service to be invoked;
• System: name of the client system to be simulated;
• ReturnCode: numerical return code;
• Character Encoding: payload encoding;
• Payload: data to be sent for testing;
• Properties: GVBuffer properties;
• Transaction Mode: transition simulation modality;
• Forward Name: name of the forward to be simulated, if possible.

Management of properties requires the inclusion of multiple name-value pairs with the key Properties. Moreover, each inserted pair can always be eliminated by clicking on [del] icon.

Upload Data

Regarding the Payload, the user has the option to insert the value in the text box or upload a file with the value by the UPLOAD function.

In case of using the UPLOAD function, the Text Area will contain this file.

The UPLOAD function allows the selection of a file and choosing the type of file:

• Binary
• US-ASCII
• ISO-8859-1
• UTF-8
• UTF-16BE
• UTF-16LE
• UTF-16

If user wants to upload a binary file, the text box of the date field will be replaced by a showData button that just displays the binary data in the form of hex dump.

To reset the date field to a text box just click the resetData key.

The choice of encoding will change the display of the payload field. This view, to be correct, requires that you save the file in the right encoding, where it is required the UPLOAD function.

For executing the tests, the page offers a number of submit buttons as there are GreenVulcano^® ESB possible services to test.

Parameters for the connection to EJB

Given the specific features of the test to invoke the EJBs, you can set the connection parameters through the "Set JNDI Parameters" link. This Link proposes a series of useful parameters for an invocation of an EJB and then:

• JNDI Name: Name of the EJB to be invoked (Required)
• JNDI Factory: Name of the application server Factory where the EJB was deployed
• Url: URL where the EJB was deployed
• User: Application server User
• Password: Application server Password

The text box will always be editable and propose in the first instance the default values specified in the configuration file:

• GVSupport.xml

This file will be configurable through the GreenVulcano^® ESB interface.

Setting these parameters from the user will remain so for the duration of the test required, except, of course, where the values are reset to the default ones held at first instance.

For each input type any validation control is done so any input item is obligatory. It is possible to testing one or configurable more times. In case of iteration of the same test, the GVBuffer input will be the same but the Id which will be generated for each test.

Iteration number

The test number to be done can be modified in runtime from the same page, as seen in the following picture:

Test output: file writing

It is also possible to define a file that contains all the looped test output and if this file is append or not:

Testing output

Single Test Output

Both for individual tests than for multiple, compared with an invocation, the workbench does not eliminate the input, but still maintains the view to facilitate the comparison with the produced data.

If the user has sent a binary file, the output will give the possibility to choose between Show Binary, which presents the binary data in a hexadecimal dump, and Show as text, which presents the binary data in a string with decoding to be chosen in a combo box, as shown in the following figure:

Five iteration output

In the event that has been run the same test for a variable number of times, the output is presented as the following figure:

The ID is generated at run time and will be one for each test. By the link "Output" you can see the result of single test, selecting the encoding type.

Exceptions

Wrong Paradigm Error

Each found error will put with the input visualization the exception stack trace.

The following picture shows a service invocation failed because of followed with the wrong paradigm: