> > > Using the Test / Quality Assurance (QA) Server

Using the Test / Quality Assurance (QA) Server

9th July 2016

Sean Hoppe Consulting Group

Your company just purchased Cleo Clarify, and included is a Test Server, which was previously known as the Quality Assurance (QA) Server.  Great, but you may be asking, what is it and how do you properly use it?

Cleo Clarify Deploy Projects to QA/Test server

What is the Test Server?

A Test Server, which is often referred to as the QA Server, is installed on a different machine than the Clarify Studio(s). It is the server to which completed Projects are deployed for the purpose of integration environment testing. This is where you load-test your environment, identify benchmarks, and guarantee that all of your integrations function together. This Server should mirror your Production environment. To ensure the best results when using a Test Server, the following guidelines should be followed:

  • Disable the communication paths to your trading partners. Instead, use the file system to test your solution’s output.
  • Ensure that all objects are saved in your SVN Repository, or in a different branch for test data.

The Test Server may mirror the Production environment, but may not have the required memory to run data or processes that the Production environment may contain.  Running larger processes with large files, or processing a large volume of database records may crash the server if memory is not available.

After my Test Server is installed, how do I use it?

The Test Server will be used after testing has successfully completed in the Local Test Server in the Clarify Studio.  Once local testing is completed, follow these five steps to properly use the Test Server before testing!

The first step you’ll want to do is to (1) take all the Projects that currently have been tested in the SVN Repository’s Trunk and branch them into a new location called Test (or QA, if desired).  This places those Projects into a separate location of the SVN Repository, which can be easily accessed at a later time, and indicate which Projects are ready for testing.

Once these Projects are available in the branch, you will want to (2) create a new workspace named Test (or QA).  This new workspace will allow you to have two different Project Explorers to easily maintain your Test Server Projects, as opposed to those being designed in other workspaces.  It also helps to differentiate between Test and Production when both are running.

Once your new workspace is created, verify you are using the new workspace and (3) check out the Projects that have been placed into the new branch.  

Once they are checked out and inside the new workspace’s Project Explorer, (4) modify the objects and resources within the Projects to suit your testing needs. Many of these objects should already be using testing values, as they were previously tested locally in the Local Test Server.  However, ensure that they are still using the testing parameters and values.  Here are some examples on what to modify:

  • EDI Envelopers may need to be revised to ensure that they are using testing values, such as the proper Test/Production qualifier.
  • Routes may need to be revised to ensure that they are using testing values, such as incoming values for Inbound EDI Routes.
  • FTP Adapters may need to be revised to ensure that they are using testing values, such as an alternate filename, or a different testing directory on the FTP Server.
  • Global Variables may need to be revised to ensure that they are using testing values. Global Variable values can be maintained after deployment in the Settings view in the Admin Console.
  • Business Processes may need to be revised to ensure that they are using testing values, such as SendEmail tasks and EXTOL Secure Exchange (ESX) tasks.
  • Database objects may need to be revised to ensure that the Test Database URL is being used.

Note:  Some folders and data that you may be using on your local machine for testing using the Local Test Server, or even Production, may not exist on the Test Server environment.  Be mindful to choose different values for your File Adapters, File Monitors, and other objects.  Or, copy those folders over to your Test environment to ensure that your objects are being properly directed.  For example, if you are using a specific folder for all of your EDI documents, copy that folder from your local system to the Test Server’s system in the same location.  This folder may contain essential values that need to be referenced, such as the JDBC Driver for your database connection, and need to be available on this server as well.

The final step will be to (5) deploy and install the Projects to the Test Server for proper testing.

Now that you’ve tested your data and objects and they work successfully, you’ll want to configure them to your Production server, which we will cover in an upcoming guide.

Maintaining your Test environment is easy!  Simply follow the same steps as you have previously to properly test your new Projects:

1.  Copy your new Projects into the Test branch of your SVN Repository.
2.  Switch your workspace to the Test workspace that was created.
3.  Check out the Projects into the Project Explorer.
4.  Modify the objects accordingly to ensure that they are using testing values.
5.  Deploy and install the Projects and test.  

By: on