Summary 

V2 Receivers are GenRocket Receivers that share the following features:

  1. They have the character V2 just before the word Receiver (e.g. GenericSQLInsertV2Receiver).

  2. They have been updated with two new specific parameters to better manage how they access resources on a local computer.
    • resourcePath
    • resourceSubDir


Detailed Explanation

By observing our GenRocket users, we noticed that many users often need to connect to multiple databases within their testing environments, so they are having to add new global resources within their organization. This creates two negative challenges to our platform and the user experience.

  1. Adding a new resource affects all users within an organization and not all users need to use the additional resource.

  2. Adding new resources unnecessarily complicates the management for the given resources when the resources are meant to accomplish the same task.

For example, if a user needs to connect to three different databases on their local computer, the user would have to add two more global resources (e.g. resource.jdbc2.config and resource.jdbc3.config). Within a given Receiver, a user would need to know which resource to use, which binds the Receiver to a specific path and file on their local computer. 


But, what if the user has two different Project Versions, A and B respectively, and in Project Version B, the user wants to reference a different set of configuration files that were referenced in Project Version A? Well, the user can't modify the resources without affecting all Receiver database connections in Project Version A. The user would have to create three more resources and this simply won't scale.


So, enter the new V2 Receivers to resolve this issue. All V2 Receivers contain the following two new parameters: resourcePath and resourceSubDir.


resourcePath

The resourcePath parameter references the new global resource variable, #{resource.jdbc.directory}, by default. The global resource variable, resource.jdbc.directory, should only contain a base path where all configuration files are located. For example, on my computer, I might define my path as /Users/htaylor/dbConfigs.


resourceSubDir

The resourceSubDir parameter is used to define a subdirectory, under the resourcePath, where one or more configuration files may exist. This allows a user the ability to organize the configuration files in a very structured manner. For example, on my local computer, I might place each configuration file within its own subdirectory:

  • /Users
    • /htaylor
      • dbConfigs
        • oracle
          • config.properties
        • mssql
          • config.properties
        • mysql
          • config.properties

However I decide to structure my configuration files, I only need one global variable resource, resource.jdbc.directory, to be referenced by any V2 Receiver to establish a base directory for all resource configuration files on my local computer.


As an example, in the scenario I described above, where the user needs to reference six different databases, three for Project Version A and another three for Project Version B, I can create a set of subdirectories under my base directory to manage my configuration files, and set the subdirectory and resourceName parameters on any V2 Receiver, in either Project Version, with ease and flexibility. For example, on my local computer, I might create the following structure:

  • /Users
    • /htaylor
      • dbConfigs
        • oracleV1
          • config.properties
        • mssqlV1
          • config.properties
        • mysqlv1
          • config.properties
        • oracleV2
          • config.properties
        • mssqlV2
          • config.properties
        • mysqlV2
          • config.properties

I could also set up my structure in a completely different way:

  • /Users
    • /htaylor
      • dbConfigs
        • oracle
          • config.v1.properties
          • config.v2.properties
        • mssql
          • config.v1.properties
          • config.v2.properties
        • mysql
          • config.v1.properties
          • config.v2.properties

Setting up your directory structure really depends on what best suits your needs. For example, the subdirectories could be names of clients or names of releases. The power of the V2 Receivers is that you will have the flexibility to create the directory structure you want with no major management overhead to setting or modifying V2 Receiver parameters.


Lastly, we will eventually deprecate all Receiver V1 versions from our platform. It doesn't mean we're going to remove the V1 Receiver from our GenRocket Receiver Jar; it just means the V1 Receivers will no longer appear on our platform to be selected for use. Thus, all Scenarios that are currently using any V1 version Receiver, will not be affected by the deprecation.