No Results
Custom Connection and Feed Types
Article Contents

edgeWeb ships with generic web content and web data connection and feed types.  For many purposes – and really just about any purpose when combined with custom authentication and content rules – these are sufficient.  However, for convenience and clarity, and when it comes to packaging customizations, it makes sense to define custom connection and feed types for specific integrations.

Custom connection types make it easy to create and administer edgeWeb configurations by:

  • allowing sensible default values to be specified for each connection property – the most useful examples of this are pre-defining the Destination property with the usual port for the application and selecting a suitable custom SSO Handler
  • defining additional properties specific to the application the connection is for
  • although properties cannot be completely removed, they can be marked hidden and not required, which has the same effect
  • identifying (and hence filtering) the feed types allowed to be connected to nodes of the connection type

Being able to define custom feed types has the same set of advantages as for connection types, though in this case there is more obvious scope for defining additional properties.

As of edgeCore 1.1, type definitions are generated when an adapter is loaded, based on the abstract definitions in appdef.json.  The types are automatically registered with edgeCore so that they are available for pipeline configurations.  A single connection type is generated from the overall application definition.  Various definitions possible are detailed in appdef.json.

Type Definitions

The adapter types are defined in appdef.json, which (since edgeSuite 2.1) is found in the appdefs/<adapter-name> directory of the adapter (for backward compatibility, it can also be located in webrules/<adapter-name>).  The feedDefs field lists feed definitions for the adapter.  Each entry in the versionDefs list restricts the feed types that apply to each supported version of the application.

Web Content Feeds

"feedDefs": [
  {
    "doClass": "WebContentFeedDefDO",
    //"extendsType": "GenericWebContentFeed", -> this is the default for WebContentFeedDefDO, so doesn't need to be defined
    "name": "ExampleBase",
    "displayName": "FeedType.ExampleBase.DisplayName",
    "rule": "Example",
    "startUri": "/",
    "appProperties": [
      {
        "doClass": "AppPropertyDefDO",
        "name": "hideHeader",
        "type": "Boolean",
        "required": "false",
        "displayName": "FeedType.Example.hideHeader.DisplayName",
        "helpText": "FeedType.Example.hideHeader.helpText",
        "defaultValue": "false",
        "isParseable": "false"
      }
    ]
  },
  {
    "doClass": "WebContentFeedDefDO",
    "extendsType": "ExampleBase",
    "name": "ExampleSearch",
    "displayName": "FeedType.ExampleSearch.DisplayName",
    "rule": "Example",
    "startUri": "/search?key={nodeVar.exampleSearchTerm}",
    "appProperties": [
      {
        "doClass": "AppPropertyDefDO",
        "name": "hideHeader",
        "defaultValue": "true"
      }
    ],
    "nodeVars": [
      {
        "doClass": "AppFeedNodeVarDefDO",
        "name": "exampleSearchTerm",
        "defaultValue": "change_me",
        "constraintName": "Unbounded String"
      }
    ]
  }
],

An example of defining feeds for a web adapter is above.  This illustrates the main types of things that can be defined:

  • The feed’s basic properties:
    • Its name (an identifier), and its display name (translatable)
    • The default content rule to be selected
    • The default URL for the feed’s initial request
    • A key piece of information when defining new feed types is the extendsType field – this allows us to reuse existing definitions, potentially overriding attributes.
  • Additional properties – the example, in this case, defines a boolean flag which allows the administrator to toggle whether or not the application’s header/banner will be displayed when it is included on an EdgeCore page.  The Application Definition file describes the attributes that define a new property.
  • Node variables – you can see that the startUri property for the second feed defined has a reference to a node variable.  This variable needs to be defined.  This is done through the nodeVars list, which allows node variables to be defined, as long as they use existing constraints (whose definition could potentially be included as part of the adapter).

A number of the string fields above can optionally reference a translatable string by specifying a key for the message catalog.

Web Data Feeds

Since 2.1, web data adapters can be defined, that define web data feed types.  Web data feed types are defined using the WebDataFeedDefDO class.  This has all the attributes of the WebContentFeedDefDO, but also allows us to define parserType, and a list of headers that should be included with HTTP requests made on behalf of the feed.  Other properties specific to web data feeds can be overridden via appProperties.

"feedDefs": [
  {
    "doClass": "WebDataFeedDefDO",
    "name": "MyAppREST_JSON",
    "displayName": "FeedType.MyAppREST_JSON.DisplayName",
    "rule": "MyAppREST",
    "parserType": "JSON",
    "headers": {
      "doClass": "KeyValuePairsDO",
      "pairs": [
        {"doClass":"KeyValuePairDO","key":"Content-Type","value":"application/json"},
        {"doClass":"KeyValuePairDO","key":"Accept","value":"application/json"}
      ]
    },
    "appProperties": [
      {
        "doClass": "AppPropertyDefDO",
        "name": "jsonPath",
        "defaultValue": "$.data.items.*"
      }
    ]
  }
]

 

Terms | Privacy
×