Documentation
  • Introduction
  • Installation
    • Docker Container
      • Database
      • Deployment Modes
      • Docker Environment Variables
      • Deploy on AWS
      • Deploy on Digital Ocean
    • First Steps After Installation
      • Add New Application
      • Publish Application
      • Use Application
  • Usage
    • Send Request To Endpoint
    • Request From Web Form
    • Web Form Controls Having Multiple Values
    • Web Form With File Upload
    • HTML Snippet embedded with Java Script
    • Authentication
    • Environments
    • Debug Mode
  • Configuration
    • Application Directory Structure
      • endpoints.xml
      • security.xml
      • email-sending-configuration.xml
      • service-portal-endpoint-menu-items.xml
      • Directory: data-source-post-processing
      • Directory: data-sources
      • Directory: data-source-xslt
      • Directory: fonts
      • Directory: http-xslt
      • Directory: parameter-xslt
      • Directory: static
      • Directory: transformers
      • Directory: xml-from-application
    • Endpoint Parameter
    • Types of Endpoints
      • Endpoint to Return XSLT Transformation
      • Endpoint to Return Content From Url
      • Endpoint to Return Static File
      • Endpoint to Return OOXML
      • Endpoint to Redirect Request
      • Forwarding Between Endpoints
      • Conditional Success Action
      • Error Case
    • Data Source Transformation
      • Load Parameter Values as a Data Source
      • Load Data From a Local XML File
      • Load Data from any REST-API
      • Load Data From Databases
      • List AWS S3 keys
      • Load AWS S3 object
      • Additional Useful Data Source Types
      • Transformation Options
      • Data Source Post-Processing
      • Using Parameter Placeholders in Data Sources
      • On-Demand Incrementing Number
      • Writing Transformation Input/Output to AWS S3
    • Parameter Transformation
      • Parameter Transformation Input
      • Parameter Transformation Output
    • Tasks
      • HttpRequest Task
      • Email Task
      • Create Shortlink Task
      • Request Log Task
      • Conditional Tasks
      • Parallel or Subsequent Execution of Tasks
      • Intermediate Values
    • PDF Created With XSLT
      • Embedding Fonts
      • Embedding Images
    • OpenEndpoints XSLT Specifics
Powered by GitBook
On this page
  • Parameters must be defined in the endpoints.xml file
  • Multiple parameters supplied with the same name
  • System Parameters
  • AWS Secrets
Export as PDF
  1. Configuration

Endpoint Parameter

PreviousDirectory: xml-from-applicationNextTypes of Endpoints

Last updated 1 year ago

A request contains any number of GET or POST parameters.

The values supplied by the user for these parameters are used in various places. For example, if you are fetching XML from a URL, parts of the whole of the URL may be the value of a parameter. The syntax for this is ${param}. The braces are, in contrast to many other systems, mandatory.

Note that for security or technical reasons replacement is not always possible. See the specific sections for the various configuration elements where parameter replacement occurs.

Case Sensitivity

Parameter names are case-sensitive. That means, the "firstname" is not the same as "Firstname". Case sensitivity is default behaviour in XML.

Parameters must be defined in the endpoints.xml file

Which parameters the user may supply must be defined in the endpoints.xml file; any parameter sent to the server which is not defined there is an error.

The simplest form of a parameter definition in endpoints.xml is <parameter name="foo">. This means the user must supply a value that parameter as a GET or POST parameter like ?foo=value in the request; not doing so is an error. (A request parameter transformation allows to submit parameters not defined in the request. For details please refer to section .)

<endpoint-folder>
    <parameter name="foo"/>
    ...
</endpoint-folder>

Adding a default value makes the parameter optional. If the user doesn't supply anything, the default value will be used.

<endpoint-folder>
    <parameter name="foo" default-value="some-value"/>
    ...
</endpoint-folder>

Parameters are defined, in the simplest case, directly under the root <endpoint-folder> node of endpoints.xml. Parameters under the root <endpoint-folder> node are available for all endpoints defined in the file.

An endpoint-folder can contain zero or many other endpoint-folders

It is possible to use "cascading" endpoint-folders. In this case, endpoint-folders and endpoints are arranged in a hierarchy so that certain aspects may be defined once and inherited to all children. The structure is thus a mandatory root <endpoint-folder> which may contain any number children <endpoint-folder> and <endpoint> elements.

Multiple parameters supplied with the same name

The HTTP standard allows multiple GET parameters to be supplied with the same name, like

...?param=foo&param=bar

In this case, all those values are concatenated into the same parameter. The default separator is two pipe characters ||.

In the example above, the parameter value would be foo||bar.

The default separator be overridden with the multiple-value-separator attribute:

<endpoint-folder multiple-value-separator=",">
    ...
    <endpoint name="foo" multiple-value-separator=";">
        ...
    </endpoint>
</endpoint-folder>

Note that this property will be inherited in the hierarchy of endpoint-folders. That means it can be overwritten by subordinate folders or endpoints.

System Parameters

There are certain parameters which are always available, and are not provided by the client. These can also be used with the same ${param} syntax.

  • ${request-id} - this system parameter returns the globally unique id of the request, assigned by OpenEndpoints during the request.

AWS Secrets

It is possible to load secrets from the AWS Secrets Manager and make them available via ${foo} parameters, for example in the SMTP configuration.

The relationship between ${foo} parameters, and which secret they are backed by, is specified in the optional secrets.xml file, checked in at the root of the application directory.

<aws-secrets region="us-east-2">
    <secret parameter-name="foo" aws-secret="my-aws-secret"/>
    <secret parameter-name="bar" aws-secret="other-aws-secret"/>
</aws-secrets>

Note, not all secrets need to actually need to exist in the AWS Secrets Manager. An error is produced only if the parameter (and thus the secret) is actually used. This is to allow “if” statements in the configuration, executing certain commands only on certain environments. If the configuration is executed on a different environment, the secret need not exist, as that part of the “if” statement is never executed.

Secrets are fetched each request. This allows for easy secret rotation. No caching of secrets between requests occurs, and no restart of the application is necessary in the case of updating a secret within AWS Secrets Manager to a new value.

JSON-style secrets, which the AWS Management Console web application creates by default, are not supported. The value of a secret is assumed to be plain text.

Parameter Transformation