It is common for an adapter to have different behavior depending on the version of the application it is connecting to.  This may be through necessity – authentication may have changed, and a new SSO handler might need to be implemented.  Or it may be optional – a newer version of the application might support new features, which the adapter would like to make available in a certain way.  The application may have changed so much from one version to the next that a new or separate adapter is warranted.  Normally though, if the application’s name and purpose are unchanged, then the edgeWeb framework is able to facilitate a single adapter supporting the different versions.

A couple of different approaches can be taken to supporting different versions, but at a minimum – for clarity – each supported major version of the target application should be listed in the version mappings field of appdef.json.  If one version can be supported using the same set of authentication and content handling rules, then define the earlier version in the versionDefs list and add the earlier version, as well as a mapping for the later version to the earlier version to the versionMappings field.  The example in the section below illustrates how you might do this.

There might be slight differences between versions, but they don’t warrant creating completely separate authentication and/or content rules.  In this case, rules can contain conditional logic based on the value of the appVersion property of the connection (referenced via ctx.connection in rule methods).  An example of this is below:

this.onResponse = function(ctx) {
 
 
    var appVersion = ctx.connection.getAllProperties().getPropertyValue("appVersion");
    if (appVersion && appVersion.indexOf("1.1") != -1) {
        // version specific logic, for example:
        copyCookieToClient(ctx, "csrftoken");
    }
 
 
    // TODO version independent processing
}

If versions use completely different authentication, then create separate SSO rules, and specify them in separate versionDefs entries.
For complex or large adapter rules where there is the possibility for sharing code, it is possible to break them up and reuse them with loadRule calls, as below:

loadRule("MyAppCommon");
 
var MyAppV2 = function(appContext) {
 
    this.baseRule = new MyAppCommon(appContext);
 
    this.onRequest = function(ctx) {
 
        // common processing
        this.baseRule.onRequest(ctx);
 
 
        // TODO version dependent processing
    };
 
 
    // and so on..
 
 
};

Version Definitions

Each supported version of the application that requires different JavaScript rules or feed types will require a separate entry in the versionDefs field in appdef.json.  Equivalent versions can be mapped in the versionMappings field.  The versionMappings field lists all the versions that we want the administrator to be able to select from in the connection editor for our adapter.  The version field in versionMappings is used to look up versionDefs, it is possible to list a version definition without it being able to be selected in the connection editor, so make sure it is present in versionMappings.

"versionDefs": [
  {
    "doClass": "AppVersionDefDO",
    "version": "1.0",
    "destination": "http://change_me:4321",
    "ssoHandler": "ExampleSso",
    "rules": [
      "Example",
      "BaseWeb"
    ],
    "feedTypeNames": [
      "ExampleBase",
      "GenericWebContentFeed"
    ],
    "defaultFeedTypeName": "ExampleBase"
  }, {
    "doClass": "AppVersionDefDO",
    "version": "2.0",
    "destination": "http://change_me:4321",
    "ssoHandler": "ExampleSso",
    "rules": [
      "Example",
      "BaseWeb"
    ],
    "feedTypeNames": [
      "ExampleBase",
      "ExampleSearch",
      "GenericWebContentFeed"
    ],
    "defaultFeedTypeName": "ExampleBase"
  }
],
 
"versionMappings": [
  { "doClass": "AppVersionMappingDO", "version": "1.0" },
  { "doClass": "AppVersionMappingDO", "version": "1.1", "mapsTo": "1.0" },
  { "doClass": "AppVersionMappingDO", "version": "2.0" }
]

In the (contrived) example above, we support three versions of the application: 1.0, 1.1, and 2.0.  The search feature is only available in version 2.0 of the application, so we have separate version definitions for 1.0 (also used for 1.1, as per the second version mapping) and 2.0 (which includes the ExampleSearch feed).