backend.properties

Configuration of all of the backend queries can be found in the backend.properties file. There can be several backends and a unique name should be given to all of them. In this example the name of the backend is customerdata. Three configuration nodes are needed for backend queries to work: input, output and config. They all use a similar JSON-style notation where an attribute set of name/value pairs is included inside curly brackets. There is also a fourth configuration node for transformations, which is optional.

input

input describes the parameters that the backend gets in a request during the registration. For example:

customerdata.input = { "user.email": "Email", "user.accountnumber": "AccountNumber" }

In this example the lower case parameters user.email and user.accountnumber are the same that are given in registration's user input fields. The parameters Email and AccountNumber are the translated parameter names that are added to the URL in the sent REST request. The parameter user.password will contain the unencrypted password as entered by the user.

output

output describes the parameters that the backend sends back in the response. For example:

customerdata.output = { "/customer/lastname": "user.surname", "contract": "user.contractnumber" }

In this example the parameter /customer/lastname is an XPath expression for parsing data from the response. This data is put to a field with the name surname. If the left side value is not an XPath expression the value is interpreted as an element name and the contents of each element with the name in the response document are taken to Ubisecure CustomerID.

The information returned from the backend may be shown to the user by adding similarly named fields to the registration's user input fields that are used after the backend request. If the fields are not visible, the information is still saved after the registration.

The key is mandatory but the parameter values are optional. For example:

customerdata.output =

In this example, no output returned by the backend is used for the registration. This could be used to call external APIs to trigger external actions that do not set or change user attributes.

config

config describes the configuration parameters that are needed to make the request. This key is mandatory. For example:

NOTE: Configuration keys must be written in lower case letters.


customerdata.config = { \
	"url": "http://localhost:7080/backend", \
	"timeout": "3000", \
	"defaultparams": { "authcode": "123" }, \
	"langcode": "locale", \
	"statuscode": "/customer/status", \
	"statusmapping": { "OK": "OK", "NOT_OK": "ERROR", "CRITICAL": "STOP" }, \
	"username": "basicAuthUsername", \
	"password": "basicAuthPassword", \
	"method": "GET", \
	"message": { "status-code" : "*", "body-or-header" : "header", "location" : "code", "use-as-key" : "true" } \
	}

transform

transform points to the XSLT file. For example:

customerdata.transform = transform.xslt

See Backend queries - CustomerID for instructions concerning how to transform backend responses to the Ubisecure CustomerID XML schema in order to be able to make more detailed data modifications.

Backend related language keys in messages_xx.properties

If registration is stopped, user is redirected to feedback page.

backend.feedbackPage.title = Registration was interrupted
backend.feedbackPage.feedback = Continuing of registration is not possible. Please, contact customer support.

This error is shown if backend response don't include one.

backend.feedbackPage.error = Backend connection received an error.

These errors are shown if timeout occurs or response status code is other than HTTP 200 when requesting backend.

backend.internalerror = Backend connection failed.
backend.timeout = Backend connection failed, try again later.

An example of the localization of the messages returned and addressed by the message parameter.

backend.mybackend.message.500 = Internal failure. Try again later.
backend.mybackend.message.usernotfound = User not found.
backend.mybackend.message.invalidid = The provided id was erronous.

For instance, if the query of the backend named mybackend returns a HTTP 500 status, the message mapping would map to the backend.mybackend.message.500 key according to the following configuration:

{ "status-code" : "500", "body-or-header" : "header", "location" : "code" }

Another example: The following backend response with status code 400

<error><message>invalidid</message></error>

would map to the backend.mybackend.invalidid key according to the following configuration:

{ "status-code" : "500", "body-or-header" : "body", "location" \
: "/error/message" }

Backend related parameters in eidm2.properties

The registration.N.userinfo.backend property defines when and which backend request is made. First parameter describes after which user information field step the backend is called. The second parameter describes the name of the backend configuration (in backend.properties). The registration.N.summary.backend property defines the backend that is used in the summary step.

registration.N.userinfo.backend = 1:customerdata
registration.N.summary.backend = summaryBackend