{section}
{column}
h1. Test aspect overview:
The test view part of the Petals Webconsole allows to perform
several test actions on the selected server, but also provide
informations on the +only previous performed exchanges by the test+
+view+. This informations are _gathered_ into a history tab, it displays
the content of *IN/OUT/FAULT* message sended during the exchange,
the message exchange pattern ...
{column}
{column:width=350px}
{panel}{toc}{panel}
{column}
{section}
h1. Test tab
h3. Form part
This tab provides the form which allows you to send message to Petals ESB,
this form is consists of _two_ part, the first is the following:
!Test-form-page.png|thumbnail!
The form contains the following parameters:
* The endpoint name.
* The interface name.
* The service name.
* Operations found.
* The IN message content.
* The message exchange pattern.
* The timeout in millisecond.
* The checkbox for manually settings
While the filling of the form you can selected the desired endpoint, following
this selection the Webconsole try to solve the _interface/service_ associated
to the endpoint.
The operation list should also be _automatically filled_, if the Webconsole
found the associated operations thank to Petals ESB wsdl return.
If operations are available into the operation list, the fact of selecting one
should automatically generate the *standard XML template*, of the message
content which will be sent.
For the message exchange pattern parameter you can select the four following values:
!mep.png|thumbnail!
For more informations on each pattern please +refer you+ to the JBI Specification.
The timeout parameter must be set in millisecond with a _int value_, as the
MEP parameter +refer you+ to the JBI Specification for the meaning of the
timeout in the message exchange.
The send DONE checkbox allows you to send a DONE message _to complete_
_the exchange_ after OUT/FAULT/ERROR reception, +if the message exchange+
+pattern allow it.+
If the service, interface or operations aren't found, you have the possibility
to set manually the desired parameter by *checking* the associated checkbox
for +manually settings+:
!Manually-settings-checked.png|thumbnail!
The second part of the form allows to set:
* Message exchange properties.
* Normalized message properties.
* Attachments.
!bottom-test-form-page.png|thumbnail!
All previous properties and attachments setted will be sent
with the IN message exchange.
Screenshot of the form that allows you to set a normalized/exchange
message property:
!nm-property.png|thumbnail!
The following screenshot represent the add attachment form:
!attachment.png|thumbnail!
h3. Response part
This following page are displayed after the return of the message exchange :
!Test-response-page.png|thumbnail!
The screen result is split in _two_ section, the first section displays the *message content* you sent and
the second section displays to you the returned *message content* in result. This content can be:
* A _OUT_ message
* A _FAULT_ message
* A _ERROR_ message
(i) *Information*: Nothing can be retuned if the message exchange pattern is +InOnly/InOptionalOut/RobustInOnly+
At the bottom of the response page, you may have a proposed acknowledgment type in order to, return a acknowledgment
for the exchange (often to complete the current exchange). The proposed acknowledgment may be:
* Active
* Done
* Fault
These acks will be proposed following to the message exchange pattern used and the returned response.
* If you select Active, no ack will be sent.
* If you select Done, the exchange will me marked "done/complete".
* If you select Fault, a textarea will be displayed in order to provide you
a textbox where you could write the returned fault.
h1. History tab
h3. Overview
This tab display into a table message exchanges sent from Test tab. This history table
create one row for each exchange and present many associated exchange informations
like:
* Message exchange Id.
* Message exchange pattern.
* Exchange status.
* The interface/service/endpoint.
!history.png|thumbnail!
Another secondary information but useful is the display of *available memory*, because keep exchanges sent
cost memory consumption. Think correctly what exchanges must be _kept_ and what others must be _remove{_}d,
because certain message exchanges with big content or large attachments can take a lot of memory volume.
h3. Detailed row
In the history table you can click on each row in order to display more exchange informations, like message
*IN/OUT/FAULT/ERROR* content, properties, attachments ...
!Exchange-history-details-page.png|thumbnail!
Each message are fully exposed in its concerned part like the following _IN_ message:
!In-details-page.png|thumbnail!
each part present the content, properties and attachments of the message.
An _OUT_ message:
!Out-details-page.png|thumbnail!
{column}
h1. Test aspect overview:
The test view part of the Petals Webconsole allows to perform
several test actions on the selected server, but also provide
informations on the +only previous performed exchanges by the test+
+view+. This informations are _gathered_ into a history tab, it displays
the content of *IN/OUT/FAULT* message sended during the exchange,
the message exchange pattern ...
{column}
{column:width=350px}
{panel}{toc}{panel}
{column}
{section}
h1. Test tab
h3. Form part
This tab provides the form which allows you to send message to Petals ESB,
this form is consists of _two_ part, the first is the following:
!Test-form-page.png|thumbnail!
The form contains the following parameters:
* The endpoint name.
* The interface name.
* The service name.
* Operations found.
* The IN message content.
* The message exchange pattern.
* The timeout in millisecond.
* The checkbox for manually settings
While the filling of the form you can selected the desired endpoint, following
this selection the Webconsole try to solve the _interface/service_ associated
to the endpoint.
The operation list should also be _automatically filled_, if the Webconsole
found the associated operations thank to Petals ESB wsdl return.
If operations are available into the operation list, the fact of selecting one
should automatically generate the *standard XML template*, of the message
content which will be sent.
For the message exchange pattern parameter you can select the four following values:
!mep.png|thumbnail!
For more informations on each pattern please +refer you+ to the JBI Specification.
The timeout parameter must be set in millisecond with a _int value_, as the
MEP parameter +refer you+ to the JBI Specification for the meaning of the
timeout in the message exchange.
The send DONE checkbox allows you to send a DONE message _to complete_
_the exchange_ after OUT/FAULT/ERROR reception, +if the message exchange+
+pattern allow it.+
If the service, interface or operations aren't found, you have the possibility
to set manually the desired parameter by *checking* the associated checkbox
for +manually settings+:
!Manually-settings-checked.png|thumbnail!
The second part of the form allows to set:
* Message exchange properties.
* Normalized message properties.
* Attachments.
!bottom-test-form-page.png|thumbnail!
All previous properties and attachments setted will be sent
with the IN message exchange.
Screenshot of the form that allows you to set a normalized/exchange
message property:
!nm-property.png|thumbnail!
The following screenshot represent the add attachment form:
!attachment.png|thumbnail!
h3. Response part
This following page are displayed after the return of the message exchange :
!Test-response-page.png|thumbnail!
The screen result is split in _two_ section, the first section displays the *message content* you sent and
the second section displays to you the returned *message content* in result. This content can be:
* A _OUT_ message
* A _FAULT_ message
* A _ERROR_ message
(i) *Information*: Nothing can be retuned if the message exchange pattern is +InOnly/InOptionalOut/RobustInOnly+
At the bottom of the response page, you may have a proposed acknowledgment type in order to, return a acknowledgment
for the exchange (often to complete the current exchange). The proposed acknowledgment may be:
* Active
* Done
* Fault
These acks will be proposed following to the message exchange pattern used and the returned response.
* If you select Active, no ack will be sent.
* If you select Done, the exchange will me marked "done/complete".
* If you select Fault, a textarea will be displayed in order to provide you
a textbox where you could write the returned fault.
h1. History tab
h3. Overview
This tab display into a table message exchanges sent from Test tab. This history table
create one row for each exchange and present many associated exchange informations
like:
* Message exchange Id.
* Message exchange pattern.
* Exchange status.
* The interface/service/endpoint.
!history.png|thumbnail!
Another secondary information but useful is the display of *available memory*, because keep exchanges sent
cost memory consumption. Think correctly what exchanges must be _kept_ and what others must be _remove{_}d,
because certain message exchanges with big content or large attachments can take a lot of memory volume.
h3. Detailed row
In the history table you can click on each row in order to display more exchange informations, like message
*IN/OUT/FAULT/ERROR* content, properties, attachments ...
!Exchange-history-details-page.png|thumbnail!
Each message are fully exposed in its concerned part like the following _IN_ message:
!In-details-page.png|thumbnail!
each part present the content, properties and attachments of the message.
An _OUT_ message:
!Out-details-page.png|thumbnail!