org.openeai.implementations.applications.testsuite
Class TestSuiteScheduledCommand

java.lang.Object

  |

  +--org.openeai.OpenEaiObject

        |

        +--org.openeai.afa.ScheduledCommandImpl

              |

              +--org.openeai.implementations.applications.testsuite.TestSuiteScheduledCommand

All Implemented Interfaces:

ScheduledCommand

public class TestSuiteScheduledCommand

extends ScheduledCommandImpl

implements ScheduledCommand

This is the first of two commands that make up the OpenEAI "TestSuite" Application. This command is a ScheduledCommand that reads a TestSuite XML document, performs the messaging actions specified and validates the results of those actions. It is simply a messaging application that uses OpenEAI foundation APIs to interact with a gateway developed on the OpenEAI foundation.

Based on the contents of the TestSuite document this command will create, update and delete objects at the destination. It will also query the destination to verify create, delete and update actions were successful. The TestSuite document specifies all the expected results that this command uses to verify actions performed.

This command works in conjunction with the SyncVerificationCommand to perform and verify theses tasks. This command performs all the Point-To-Point messaging and the SyncVerificationCommand consumes the resulting Synchronization messages that should be published by an authoritative source when the Point-To-Point actions are executed. i.e. - when a create-request is sent to an authoritative source, that system should publish a create-sync message according to the OpenEAI Message Protocol.

Relations to the TestSuite document

As stated above, this command reads a TestSuite document and executes the instructions specified in that document. In order to do that though, there are some relationships that must be specified between that document and this command. These are listed here:

• The PointToPoint producer named in the TestSuite document (producerName attribute associated to a TestSeries) must be specified in the Configuration associated to this Command. The name of the producer must match the name specified in the TestSuite document and must be configured appropriately to produce requests to the gateway being tested.
• Any message object used in the TestSuite, must be specified and configured appropriately in the Configuration associated to this Command. For example, if the TestSuite specifies that a BasicPerson object is used to perform BasicPerson/Create-Requests, that object must be configured in the MessageObjectConfigs section of the deployment descriptor associated to this command. Additionally, that message object must be named according to the name given to it in the CreateRequest element of the TestSuite document. This command will look for that named message object in it's AppConfig with which to perform the requests specified in the TestSuite document. The message objects used in performing actions such as create, delete and update will be specified in the "messageObjectName" attribute associated to those actions and must be included in this Command's Configuration element. Likewise, objects used to perform queries will be specified in the TestSuite document by the "queryObjectName" attribute and must be included in this Command's Configuration.

Test Suite helper Objects

In order to correlate any request action to a reply or to a sync message published as a result of that action, the following Message Objects must be specified in this command's Configuration:

• org.openeai.moa.objects.testsuite.TestId
• org.openeai.moa.objects.testsuite.TestStatus
• org.openeai.moa.objects.testsuite.TestSuiteSummary
• org.openeai.moa.objects.testsuite.TestSeriesSummary
• org.openeai.moa.objects.testsuite.TestCaseSummary
• org.openeai.moa.objects.testsuite.TestStepSummary

These objects are a part of the OpenEAI JAR file (openeai.jar) and are used to complete the TestSuite summary document as well as correlate replies and sync messages to the requests that precipitated them. The name of the objects should should match their class name (without the package).

Gateways that are tested with this Test Suite Application should pull the TestId out of the ControlAreaRequest/Sender element and populate the synchronization messages it publishes with that information.

Consuming the Sync Messages:

In order to complete the TestSuite, the TestSuite Application must produce requests, consume the replies, verify those replies and consume any synchronization messages that result from the request-reply actions. To do this, this scheduled application actually contains a PubSubConsumer to consume the sync messages. Therefore, there must be at least one PubSubConsumer configured within this Command's Configuration Element that is set up appropriately to consume these sync messages.

The TestSuiteScheduledCommand (this command) expects any consumer that is to serve this purpose to have a name that starts with "PubSubConsumer".

This command will retrieve any consumer with a name staring the "PubSubConsumer" from its AppConfig, start them to verify their durable subscriptions have been established and allow them to consume any message left over from previous runs. Then it will stop them, and perform all the request-reply messaging before re-starting the consumer(s) to process the sync messages that should have been published during the request-reply activity. Between the request-reply message production and verification and the consumption and verificaton of resulting sync messages, the entire TestSuite is completed.

Configuration Parameters:

These are the configuration parameters associated to this command.

Property Name	Required	Description
TestSuiteDocUri	yes	The URL for the actual TestSuite associated to this instance of the TeseSuiteApplication. This is the same value used by the SyncVerificationCommand that points to the TestSuite document used by both commands to compare expected with actual results. The TestSuite document contains all the instructions that are to be carried out by this command as well as the expected sync messages that the SyncVerificationCommand expects to consume.
TestSuiteSummaryDocPath	yes	This is the output path (directory name) where the TestSuite summary document should be written to. Both the SyncVerificationCommand and this command need this parameter. They will both write the results of their processing to a file in this directory. The name of the summary document will be the actual file name of the test suite document with the word "-summary" appdended to it. For example, if the TestSuiteDocUri is: http://xml.openeai.org/xml/configs/messaging/environments/development/tests/1.0/TestSuite_BasicPerson_v1_0.xml then the summary document name would be TestSuite_BasicPerson_v1_0-summary.xml and it would be written to the directory specified in this property (e.g. "./"). If this command recognizes that a sync message should be published based on an action performed, it will set the status of that test step to 'pending' (unless a failure occurs carrying out that action). The SyncVerificationCommand will set the status to 'success' or 'failure' based on the results of it's processing when it consumes the sync message associated to the action.
producerTimeoutInterval	no (default=30000 or 30 seconds)	This is the maximum time (specified in milliseconds) that the producer used to carry out the requests listed in the TestSuite will wait for a response. If the producer does not receive a response to the request it sends within this time, it will throw an exception resulting in a 'failure'. This property can be used to benchmark a gateway being tested to see how big of a load can be thrown at it before performance starts to degrade. This can be useful in determining such things as how many gateways to deploy etc. because once you start causing timeouts due to a massive load, you can see how adding gateways to a cluster affects those errors.
maxProcessTime	no (default=300000 or 5 minutes)	This is the maximum time (specified in milliseconds) that the entire application will stay alive. This value is only used if the SyncVerificationCommand never starts consuming messages as a result of actions performed by this command. Once the SyncVerificationCommand has consumed and processed its first message, the 'maxConsumptionTime' property associated to it will be the only relavant "timer" for the application.
useThreads (true | false)	no (default=false)	This property tells the TestSuiteScheduledCommand whether or not it should use threads to execute the test suite. Each TestSeries in the suite can be executed in Threads. If threads are to be used, this command expects there to be a ThreadPoolConfig associated to it named "TestSuiteThreadPool".

Author:

Tod Jackson

See Also:

SyncVerificationCommand

Field Summary

static boolean

STAY_ALIVE

Fields inherited from class org.openeai.OpenEaiObject

logger

Constructor Summary

TestSuiteScheduledCommand(CommandConfig cConfig)
This is the constructor used by the ScheduledApp foundation to instantiate this ScheduledCommand.

Method Summary

int	execute() The execute method that will be called whenever the ScheduledApp foundation determines that this command should be executed.

Methods inherited from class org.openeai.afa.ScheduledCommandImpl

buildError, getAppConfig, getControlArea, getInboundXmlValidation, getOutboundXmlValidation, getSyncErrorPublisher, getSyncErrorSyncPrimedDocumentUri, publishSyncError, publishSyncError, setAppConfig, setInboundXmlValidation, setOutboundXmlValidation, setSyncErrorSyncPrimedDocumentUri

Methods inherited from class org.openeai.OpenEaiObject

addLog4jProperty, getAppName, getDebug, getFromAddr, getLog4jProperties, getMailHost, getMailService, getProperties, getToAddr, initializeLog4j, initializeLog4j, initializeLog4j, setAppName, setDebug, setFromAddr, setMailHost, setMailService, setProperties, setToAddr

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

STAY_ALIVE

public static boolean STAY_ALIVE

Constructor Detail

TestSuiteScheduledCommand

public TestSuiteScheduledCommand(CommandConfig cConfig)
                          throws java.lang.InstantiationException

This is the constructor used by the ScheduledApp foundation to instantiate this ScheduledCommand. The ScheduleApp foundation will instantiate this command passing the commands configuration information when the application is started.

The following variables associated to this command are initialized in this constructor:

Method Detail

execute

public int execute()
            throws ScheduledCommandException

The execute method that will be called whenever the ScheduledApp foundation determines that this command should be executed. This execute method will read the TestSuite document associated to the application, execute the Point-To-Point messaging actions specified and verify the results according to the information found in the TestSuite XML document associated to this instance of the application.

Specified by:

execute in interface ScheduledCommand

Returns:

int just an indicator that the ScheduledApp can use to determine if the command executed successfully. -1 indicates unsuccessful execution but all error handling specific to this command is handled by the command.

Throws:

ScheduleCommandException

ScheduledCommandException - if errors occur executing the business logic associated to the ScheduledCommand.

See Also:

ScheduledApp