Registry Overview

The purpose of an SDMX Registry is to store and disseminate SDMX Structures. The term used to describe the information in the Registry is ‘Structural Metadata’ as it is metadata used to describe the structure of information.

The purpose of the structural metadata is to describe various parts of the statistical lifecycle, such as data collection, data dissemination, templates which describe data set.

An SDMX Registry is not intended to store or disseminate datasets, just the metadata used to understand the datasets. A Registry does however have a Registration mechanism, whereby a data provider registers the URL of a dataset for a particular data domain.

Click HERE to read about the terminology used to describe the structural metadata, as well as how each type of structure is used in the statistical lifecycle.

Uploading Structures

The Fusion Registry supports structure upload from the HTML UI, the Maintenance Tool, and to the web service itself.

Uploads can be SDMX Registry Interface Documents, SDMX Structure Documents, SDMX-EDI documents, or XLSX documents. In addition the Maintenance Tool supports upload of CSV codelists. With the exception of XLSX all upload entry points support the file to be compressed in ZIP format.

The HTML UI upload panel allows structures to be queried directly from a URL. The URL must resolve to a document containing information in any of the supported import formats.

Maintenance Tool

Structure Creation

The Maintenance Tool provides a consistent way to maintain structures, so the workflow to create one structure will be similar for all other structure types. This example provides a simple example of structure creation with the addition of a codelist. To navigate to the codelist page, click Item Schemes --> Code Lists.

showing selection of Codelists

To do this click on the 'Item Scheme/Codelists' button and then the [plus] icon to add a new Codelist, this will result in a pop-up window appearing allowing the user to enter information about the Codelist such as Id and Name.

All "maintainable" structures have the information shown above. Each needs at least an ID and a Name. The Registry generates the URN. The "Final" will set the object to a final state and it can only be changes in a minor way (such as adding a "Valid To" date or changing a "Description").

On clicking 'Save' the pop-up dialog will close and the Modifications panel containing the new Codelist will be expanded from the bottom of the page. The codelist does not need to be committed to the registry at this point. The modification panel can be collapsed to hide it from view, but it is important to note that until the codelist has been Committed to the Registry, all changes will be local.

Note: It is also possible to save structures by clicking the icon next to the structure in the list, as shown below.

Note: For more complex structures such as Data Structures the modifications panel will not show the new structure until it is deemed to be valid by the UI. In this instance a warning icon will be displayed next to the structure, which on roll over will show the required sub-structure to the user.

Adding a Language

Most Name and Description fields in the Registry allow for multilingual text. In order to add a new language for these fields, the language selector can be used. This process is described below.

  1. The change language selector. Use this drop-down list to change the language that the name and description fields are for.
  2. Change language, quick view. This horizontal display of languages shows which languages are currently present for this structure. In the example the Codelist has a name in both English (en) and French (fr). The highlighted entry is the language currently being displayed. Clicking on a language will change the selection.
  3. Multilingual field. This highlights that the given input field is capable of taking text in multiple languages.
  4. Copy URN. The URN is a unique identifier for each ‘identifiable’ structure in the Registry. The URN is generated by the Registry and is a concatenation of Structure Type, the Agency Id of the Agency maintaining the structure, the Id of the structure, the version of the structure and any sub Ids. As the URN is generated by a pre-determined algorithm, it is not editable by the user. It is not generated until the structure is committed to the Registry. The icon shown is the copy URN button, and clicking it will copy the value of the URN to the user’s clipboard.

Addition of Sub Structures

Most Structure types have sub structures, for example a Codelist contains Codes, Concept Schemes contain Concepts, a Data Structure contains Dimensions and Attributes. To create a sub structure, ensure the parent structure is selected and then click the add icon for the sub-structure.

Showing the 'add' button

Clicking on the add icon will create a pop-up dialogue window.

Create New Code dialog box

Enter the details and click on "Save" to save the new sub-structure to the parent structure.

Showing the structure in the Registry

More complex structures follow exactly the same process for creation, as can be seen below in the creation of a Dimension for a Data Structure.

Showing complex structures creation process

The above image shows the options available for a Dimension in a Data Structure Definition.

  1. The Concept to be used. This must identify the Agency owning the Concept Scheme that contains the Concept (maintenance agency), the Concept Scheme, and the Concept.
  2. If the representation is coded the maintenance agency of the Codelist, and the Codelist.
  3. The type of Dimension (Normal, Measure, or Time)

Documentation on how to create more complex structures is provided in the other User Guides supplied in the Registry product download.

Multi-Lingual Support

In the previous section, it was described how to create structures with names and descriptions in more than one language. When browsing the Registry contents, it is also possible to view the names of the structures in a given language. In order to view structures in a language other than English (which is the default), make sure the Registry is set to ‘Show Labels’ and click on the language drop-down to select a different language.

Showing language selection

The language drop-down will only display the languages for which the Registry is maintaining languages. So adding a Codelist with a French Name will cause this drop down to contain both an English (en) and a French (fr) entry. If a default language is selected that is not supported by some structures, then this will be made clear in the UI by a label being displayed next to a structure that is showing a different language from the one that has been selected as shown below where French (fr) is the default language selected.

French is selected as the default language to show, but the data provider only contains English

Currently the Registry does not support multilingual labels on error messages.

Maintaining Structures in Excel

It is possible to navigate and maintain the contents of the Fusion Registry using the FusionXL plugin for Microsoft Excel®. Please see the FusionXL User Guide for more information.

If you are unable to use the FusionXL plugin, it is still possible to export structures in Excel format from the Fusion Registry. It is also possible to directly upload an Excel documents to the Fusion Registry using the file upload facility. The documents must be in the format as detailed in the FusionXL User Guide.

Structure History/Rollback

The modification history for each maintainable structure is recorded in the Fusion Registry along with ah copy of a SDMX representation of the structure at that point in time. This is true for structures modified through both the FlashUI and SDMX Web Service Interface.

It is possible to view the history of each modification for a structure, along with the date the modification occurred, and the user who modified the structure. To view the historical modifications for a structure, select the structure, and click the [clock] icon, which will open a window like the one shown below:

showing modification history for a structure

It is possible to download any previous version as a 2.1 SDMX message by selecting the transaction and clicking on the ‘Download’ button. Furthermore the structure can be restored to a previous transaction. To rollback a structure, select the transaction to roll back to and click ‘Restore’. The Fusion Registry will then attempt to restore to the selected transaction. If security is enabled then this action can only be performed by an Admin or Agency user.

The restore of a structure is in fact a resubmission to the Fusion Registry of the SDMX structure as it was defined in the previous transaction. The rollback undergoes the same validation rules as if the SDMX document was uploaded directly to the Registry web service. The Registry validation rules may reject the restore, for example it will be rejected if the structure in the previous transaction references a structure which was subsequently deleted from the Fusion Registry.

If the restore is a success then the new transaction will be added to the list, and this transaction will be made available on the RSS feed.

showing the historical modifications for a structure which has been restored at various points

Note: If the Fusion Registry detects that a submitted structure does not differ in any way from the current structure then it will be removed from the submission. In the case that the structure is rolled back to an exact copy of itself, the registry will take no action, and there will be no transaction recorded.

PUSH and PULL to Endpoints

The Fusion Registry Technical page describes how to add the location of known SDMX Web Services to the Fusion Registry. Each of these locations has an alias, collectively as Endpoints. The Flash UI provides the means to PULL structures from an Endpoint into the Local Registry. It also provides the means to PUSH structures from the Local Registry to an Endpoint.

See the Fusion Registry Technical page which discusses setting up an endpoint location. In setting up an endpoint it is possible to PULL structures for one or more Agencies from the endpoint into the local Registry. When viewing these structures they will be marked as external as denoted by the icon.

showing codelists which are marked as externally maintained

Although structures can be external, the Fusion Registry holds a local copy, and it is possible to modify the local copy of the structure. If an external structure is locally modified it will be marked as out of sync, this is denoted by the [black square] icon as shown below.

showing the external Frequency (1.0) codelist which has been locally modified to change the name

It is possible for any structure, or structures to be PUSHED back to the endpoint, this may be because the structure is locally modified, or because the structure is new. Alternatively, a structure may be PULLed from an endpoint. To PUSH or PULL a structure select the structure and click on the [double arrow] icon, this will open a pop-up dialogue window as shown below.

showing the PUSH/PULL dialogue for the codelist CL_ACTIVITY_ISIC4

The PUSH/PULL dialogue will allow a structure to be either submitted (PUSHed) or resynchronized (PULLed) from a Service. The structure can be PUSHed or PULLed from any Sdmx service, even if it is not the service from where the structure originated. If the service has security enabled, then a username and password must be entered. These security credentials will be passed to the endpoint service using Basic Authentication as specified by the HTTP/1.0 specification .

The PUSH/PULL detail allows the specification of which structures are sent or retrieved from the endpoint. The options are:

PUSH/PULL detail


Structure Only

Only send or retrieve the selected structure

Structure + descendants maintained by the same agency

Send/retrieve the selected structure including all the structures that are referenced by the selected structure and their references (and so on). Do not include any structures maintained by another agency in the submission.

This option is useful if the agency that owns the structure does not own all the structures that the structure references (for example a DSD may reference multiple codelists from multiple agencies).

Structure + all descendants

Send/retrieve the selected structure including all the structures that are referenced by the selected structure and their references (and so on). Do not filter any structures.

On successful PUSH or PULL of a structure it will be marked as external and in sync. It is important to note that the Fusion Registry will not detect changes to the structure if they are made on the external service.

Registering Data Sources

A Registered data source defines where data can be found from a particular Data Provider for a particular Data Flow. This is called a Provision Agreement. A data flow references a Data Structure Definition (DSD), which is the structure used to describe the structure of the data in terms of the dimensionality and coding schemes. Constraints may be added to the Data Structure the Dataflow, the Provision Agreement, and the Data Provider. A Constraint limits the series keys and/or the codes that are valid for a data set. The use of Constraints is described in more detail in the SDMX standard.

A Data Provider is responsible for Registering a datasource for the Provision Agreement. The Provision Agreement can be thought of as an agreement for a data provider to provide data for a given data flow. To Register a data source click on the ‘Data Registrations’ button.

Selecting Data Registrations

This will display a page as shown below.

Options for Viewing and Managing Data Registrations

Click on "Manage Registrations".

Selecting a Provision Agreement for a Data Registration

The list of Provision Agreements that relate to the currently logged on Data Provider will be shown.

Click on a Provision Agreement and then on “Register New Datasource”

Click on "Register New Datasource"

You will be prompted for the following information:

Creating a Registered Data Source

The numbered items in the above image are as follows:

  1. The last date this registration was updated. This will be automatically generated by the Registry if not provided. The "valid from" and "valid to" dates are optional.
  2. Indexing. These checkboxes, if checked, will cause the Registry to create a Content Constraint for the Registered data source. The contents of the Constraint depend on what is being indexed. The indexes are as follows:
    • Dataset – creates an index of each unique code that has data reported against it for each dimension.
    • Time Series – creates an index of each series contained in the dataset.
    • Attributes – creates an index of each unique code that has data reported against it for each attribute.
    • Reporting Period – creates an index of data start and data end dates.
  3. The data source URL which must be a valid URL.
  4. The data source type which has the following options:
    • REST – An SDMX compliant RESTful web service as described in the SDMX web services guide. The Registry will verify this is a valid data source by performing a data query.
    • Web Service – an SDMX compliant SOAP web service, currently the Registry is not capable of verifying of indexing this type of data source.
    • File – this must be a valid SDMX data file retrievable via the given data source URL.
  5. After confirmation, the Registration will be committed to the Registry. The Registry will automatically create an Id for the Registration, and if indexing was chosen then a Content Constraint will also be created and stored with the same id as the Registration. Removing the Registration will also have the effect of removing the Content Constraint.

    Current Registrations can be viewed by Data Structure, Dataflow, Data Provider and Provision Agreement.

    Viewing Data Registrations

    Subscription & Notification

    Users may subscribe to structure or data changes in Fusion Registry. This is useful if a user, or indeed a computer system, wishes to be automatically informed of Registry changes. The Subscription Dialog is shown in the image below:

    The Subscription Dialog

    To receive Subscription notification events, users do not need to have an account with either Fusion Registry or Fusion Security. They must simply provide a valid e-mail address and select the agencies and structure events on which they wish to receive notification. Having done so a confirmation e-mail will be sent to the e-mail address. This e-mail will contain a confirmation link, and once the user clicks on this link their subscription will be activated.

    When a structure is modified within Fusion Registry then all of the subscribers who are registered to receive notification for that structure and that Agency will receive a notification e-mail informing them of the change.

    There are options at the bottom of this dialog allowing a user to see what notification events the user has subscribed to. If the user wishes to no longer receive notifications, then there is an unsubscribe option at the bottom of this dialog. For both options, the user must simply specify their e-mail address and the Fusion Registry will send an e-mail instructing them of what to do next.

    If a user wishes to modify their subscription, then opening this dialog and selecting the desired agencies and structures, clicking submit and following the e-mail instructions, will have the effect of replacing their existing subscription.

    Rather than receiving an e-mail, a user may wish that notification is sent via HTTP Post. The user must still specify an e-mail address in the text box of the Subscription dialog (so that they can receive the confirmation e-mail) but in this scenario, the user should un-check the “Receive notification by e-mail” checkbox and then check the “Receive notification by HTTP Post” checkbox. An entry field will be displayed allowing the user to enter the URL of the location they wish notification to be sent to. This is shown in the image below:

    Once the user confirms their subscription request by e-mail, then notifications will then be published to the specified URL.

    Web Service

    The Fusion Registry supports RESTful GET and POST via the URL:


    There is also a RESTful Web Service that supplies auto-increment functionality. This is available via the URL:

    http:// [server]:[port]/ws/rest/auto

    The auto-increment Web Service will, if necessary, update the version numbers of POSTed structures if there is a collision with existing structures within the Fusion Registry.

    RESTful POST

    The POST protocol can be used to submit SDMX-ML documents to the Fusion Registry. An SDMX StructureDocument can be POSTed in any version of SDMX. Additionally the web service supports SDMX RegistryInterfaceDocument submissions, and SDMX-EDI Structure submissions. Documents submitted via POST must have the content type set to either application/text or application/xml.

    Auto Increment API

    If posting to the auto-increment web service, the Registry will process the submission to determine if any of the submitted structures already exist in the Registry. If the structures do exist, then the service will determine if any modifications have been made to the submitted structure and, if so, whether the modification is minor or major. In the instance where a modification has been made, the auto increment service will increment the version number of the submitted structure and in turn any referencing structures. The auto increment rules are as follows:

    • If a structure is submitted that does not yet exist in the Registry no action is taken
    • If the structure already exists then the version number of the submitted structure is incremented, meaning the existing structure remains unchanged
    • A minor version increment is performed if the structure does differ in the identifiable composite structures. For example, a codelist with exactly the same codes (a code is identifiable as it has a URN)
    • A major increment is performed if the submitted structure has an additional identifiable or has had an identifiable removed. For example a codelist may have had a code removed
    • A minor version increment is a .1 increase. For example 1.2 becomes 1.3 (or 1.3.2 becomes 1.4)
    • A major version increment is a full integer increase. For example version 1.0 becomes 2.0 (or 1.4 becomes 2.0)
    • Any structures that cross reference the existing structure will also have a minor version increment and the references will be updated to reference the latest structure. This rule is recursive, so any structures that reference the references are also updated. This rule will also apply if the referencing document is the same structure submission, as long as the referencing structure in the submission has had the reference modified.

    POST Example (Java)

    To POST a document from machine code, ensure the content-type HTTP header is set to application/text set Accept-Encoding to gzip if your application is able to handle compressed responses.

    The following code is a Java snippet for POSTing a document to the Fusion Registry

    String xml = ";//some XML to POST
    String webService = "";
    URL url = new URL(webService);
    URLConnection urlc = url.openConnection();
    urlc.addRequestProperty("Content-Type", "application/text");
    //Optionally support gzip
    urlc.addRequestProperty("Accept-Encoding", "gzip");
    //Optionally provide authentication credentials
    urlc.addRequestProperty("Authorization", authDetails);
    //Optionally provide accept response type
    urlc.addRequestProperty("Accept", responseType);
    PrintStream ps = new PrintStream(urlc.getOutputStream());
    InputStream response = urlc.getInputStream();

    RESTful GET

    The GET protocol is used to query the Registry contents and conforms to the SDMX Web Services Guidelines specification. The Fusion Registry supports some additional parameters over and above what is defined in the SDMX guidelines, and additionally support is given to query for Registrations via REST, both are documented below.

    The Fusion Registry provides an interactive User Interface to simplify the creation of a REST query, this is available in the HTML UI. As Fusion Registry structures are public there are no restrictions on what can be queried, and there is no requirement to provide security information.

    GET Structures

    The Fusion Registry supports all parameters as defined in the SDMX Web Services Guidelines. Additional support is given for the following parameters.


    Allowable Content




    If set to true creates partial Codelists in the response based on constraints information in the Fusion Registry.

    The pre-requisite is that the query must be for a single constrainable structure (Provision Agreements, Dataflow, or Data Structure) and include references.


    1.0, 2.0, 2.1, edi

    Specifies the response version of the SDMX standard.

    Note: Also supported is the use of content negotiation to define the response version, this is described in the SDMX Web Services Guidelines.

    GET Registrations

    Registration queries via REST are NOT specified in the SDMX Web Services Guidelines. The Fusion Registry supports a query via a POST document (RegistryInterface QueryRegistrationRequest). The Fusion Registry also specifies a REST query in order to offer a simpler API.

    The entry point is:


    The following parameters are used to identify a registration by specifying what structure(s) the registration references (directly or indirectly).


    Allowable Content


    Referenced structure


    Defines the structure type that is referenced by the following parameters


    A string compliant with the SDMX common:NCNameIDType

    The agency maintaining the referenced structure.


    A string compliant with the SDMX common: IDType

    The id of the referenced structure.

    NOTE: For a data provider this is the id of the provider, not the provider scheme. For a single registration this is the id of the registration


    A string compliant with the SDMX common:VersionType

    The version of the referenced structure.

    Note: This is not relevant if the referenced structure is dataprovider or registration.


    Query String



    All Registrations


    All Registrations for ESTAT


    All Registrations for the data provider DE (Germany) for the Agency WB (world Bank)


    The Registration with the id uudi1236

    Parameters used to further describe the desired results

    The following query parameters are used to further describe the desired results, once the resource has been identified.


    Allowable Content



    Common: TimePeriodType, as defined in the SDMXCommon.xsd schema. Can be expressed using xs:gYear (ex: 2008), xs:gYearMonth (ex: 2008-01), xs:date (ex: 2008-01-01), xs:dateTime (ex:2008-01-01T01:18:59+01:00) and the SDMX period type (ex: 2008-Q1). In case the : or + characters are used, the parameter must be percent-encoded by the client11.

    Returns any registrations which have been updated before the given date.


    Same as above

    Returns any registrations which have been updated after the given date.


    Query String



    Returns all registrations updated since 2008


    All Registrations for ESTAT updated after 2008-01-01

    GET Example (Java)

    The following code is a Java snippet for GETing a document from the Fusion Registry

    String restQuery = "";
    URL url = new URL(restQuery);
    URLConnection urlc = url.openConnection();
    //Optionally support gzip
    urlc.addRequestProperty("Accept-Encoding", "gzip");
    //Optionally provide accept response type
    urlc.addRequestProperty("Accept", responseType);
    InputStream response = urlc.getInputStream();

    Reference Resolution

    The REST query supports a query for one or more structures by defining the structure type, agency id, id, and version of the structure(s) to be returned. Once the Fusion Registry has determined which structure(s) match this criteria it will then, if requested, resolve any referenced structures. There are six types of reference resolution requests which are described below:

    1. None (do not resolve any references)
    2. Children
    3. Descendants
    4. Parents
    5. Parents and Siblings
    6. All

    References Children

    "Children" refers to any structures which are directly referenced from the target structure. For example a Dataflow must reference a Data Structure. The Data Structure is considered a child of the dataflow, in this context. A structure may have more than one child; for example a Data Structure may reference may Codelists and many Concepts . The diagram below shows a tree like structure which represents a hierarchy of structures. This diagram illustrates what would be returned if a dataflow was queried, with references=children.

    Showing a REST query where references=children

    References Descendants

    "Descendants" refers to the structures which are referenced from the target structure, including all the children of those structures, and their children etc. Setting the references parameter to descendants will bring back the ‘whole tree’ in the hierarchy starting from the target structure.

    Showing a REST query where references=descendants

    References Parents

    "Parents" refers to the structures that directly reference the target structure. This does not include the parents of those parents. Unlike traversing down the hierarchy which can traverse down to all the descendants, the references parameter only provides support for traversing 1 level up the structure hierarchy.

    Showing a REST query where references=parents

    References Parents and Siblings

    "Parents and Siblings" is quite a complex type of reference resolution. It brings back the immediate parents of the referenced structure, and for each parents, their immediate children are returned. These child structure of the parents, are deemed as the siblings of the target structure. This can be seen in the diagram below, where the queried structure is a Codelist. The parent of the codelist, in this scenario, is the Data Structure. The children of the data structure, are the codelist and concept.

    Showing a REST query where references=parentsandsiblings

    References Specific

    It is possible to choose a specific structure type to include in the references. This allows the user to specify which structure type should be returned in the reference resolution. The structure type must directly reference, or be referenced by the target structure, either as a parent, or a child. The allowable arguments are defined in section 4.3.1 of the Web Services Guidelines.

    Showing a REST query where references=codelist

    References All

    If "references" is set to ALL, then the parents and children of the target structure will be returned.


    The Fusion Registry supports SOAP queries via the following URL.


    The Web Service Definition Language (WSDL), which describes the functionality offered by the service, is available at the following URL.


    The SOAP interface as defined by the WSDL is much richer than the REST interface with the WSDL specifying more operations and more functionality than provided by the REST service. However it is important to state that the Fusion Registry currently only supports a sub-set of the available functionality declared by the WSDL. The most useful functionality has been supported allowing the most-common SOAP queries to be performed.

    As a rule of thumb, the SOAP interface supports the equivalent level of functionality that the REST interface provides.

    SOAP Functionality

    The following methods are supported and will return the appropriate structure:

    • getCategorisation
    • getCategoryScheme
    • getCodelist
    • getConceptScheme
    • getConstraint
    • getDataflow
    • getDataSchema
    • getHierarchicalCodelist
    • getMetadataflow
    • getMetadataStructure
    • getOrganisationScheme
    • getProcess
    • getProvisionAgreement
    • getReportingTaxonomy
    • getStructures
    • getStructureSet

    Detail Level of Returned Structures

    An important area where the implementation of the SOAP interface is incomplete, is in the detail level of the structures being returned by the SOAP query. The SOAP WSDL provides the ability to specify the detail level on the structure being directly queried for, and also the SOAP WSDL provides the ability to specify the detail level on any referenced structures. This goes beyond the level of detail that the REST Web Service provides.

    For each of these detail levels there are 4 possible options: Full, Stub, CompleteStub or "no value specified". To provide a simple implementation, the Fusion Registry SOAP interface does not really support the "CompleteStub" parameter but will instead supply a Stub when it is appropriate to do so. The table below shows what will be returned through the combination of the "References" Detail and the "Return Details" detail. Whatever the combination of detail levels, there are only 4 possible outcomes:

    1. Full – All available information for all artefacts will be returned
    2. All Stubs – All artefacts will be returned as stubs
    3. Reference Stubs – Only referenced artefacts will be returned as stubs
    4. Error: Unsupported – An error will be thrown by the SOAP interface

    “References” Detail




    Not Specified

    “Return Details” Detail



    Reference Stubs

    Reference Stubs



    Error: Unsupported

    All Stubs

    All Stubs

    All Stubs


    Error: Unsupported

    All Stubs

    All Stubs

    All Stubs

    Not Specified


    Reference Stubs

    Reference Stubs


    So, through specifying settings at the References and Return Details level, the SOAP interface can return structures in full or as stubs.

    Reference Resolution

    A further setting within the “References” element allows further specification of the scope of which references are returned. The available values are:

    1. None (do not resolve any references)
    2. Children
    3. Descendants
    4. Parents
    5. ParentsAndSiblings
    6. All
    7. SpecificObjects (e.g. Codelist)

    These options are the same as that of the REST interface.


    If security is enabled, then a POST action must include security credentials in order to authenticate the user. User credentials must be provided using Basic Authentication, as described in the HTTP/1.0 specification.

    Note: As basic authentication includes the username and password in the header of the HTTP message it is strongly recommended to POST documents using the HTTPS protocol which will encrypt the entire message.