Editing Webservice CMDI Metadata

From WebLichtWiki

Jump to: navigation, search

For a webservice to be usable in WebLicht it must have an orchestration description in a CMDI format designed for WebLicht webservices. To make this process easier a CMDI orchestration metadata editing tool was created. It can be found here.

Contents

 [hide

Using the COMET editing tool

In the front page you are presented with a choice of uploading an exiting CMDI file or creating a new one either starting from scratch or from an existing CMDI. Once this choice is made you will be redirected to the editing page. This page is split into two sections as described below.

General Information

In this section general information about the webservice is edited. Please make sure to fill all the fields. If any of the fields is highlighted in red, an error has occurred. In the accompanying error message the precise nature of the error will be explained. Pay particular attention to the PID field which must contained a unique PID for your webservice. Some fields are greyed out, that means that they will be filled in automatically.

Orchestration Information

This section is dedicated to the orchestration metadata used by WebLicht to chain the webservice. The orchestration metadata view is split into two tables, one for input and one for output. The editor is designed to assist you in the registration process, but one must still have the basic understanding of the chaining process to edit the orchestration metadata.

Follow these general guidelines when editing orchestration metadata:

  • When creating feature names:
    • use the suggested feature names whenever possible
    • do not use the same feature name twice within the same table (input/output)
  • When creating value names:
    • use the suggested value names whenever possible
    • do not use the same value name twice within a feature

Input value arguments represent the query string parameters value that is being added to the webservice URL when the webservice is executed by WebLicht. The query string parameter name can be specified for any input feature.

  • When editing input value arguments:
    • if a feature has an argument (query string parameter) all its values must have arguments.
    • if a feature has no values it can not have an argument.
    • if a feature has only one value, having an argument makes not sense, since the same query string parameter will be supplied to the webservice all the time, the same effect could be achieved by supplying it in the URL.
  • When editing output value input references:
    • Multiple values cannot refer to the same input value

Error Codes

1 : general information field is empty

- all the fields presented are required and thus cannot be left empty

2 : invalid option selected for a field

- a field has a limited choice of options and an option has been selected which is not one of the valid options

3 : feature/value name is empty

- feature/value name cannot be empty

4 : feature/value name is not unique

- feature name must be unique within a given input or output
- value name must be unique within a feature

5 : type feature must be present

- an input must always have a type feature
- an output must have a type feature only if it replaces the input

6 : input value must have a query string argument value

- a value belonging to a feature having a query string argument must provide a value for this argument

7 : input features having no values or a single value should not have query string arguments

- it makes no sense for a feature having no values to have a query string argument as it will not have a value
- for a feature having a single value the query string parameter will always be the same, thus it could as well be appended to the webservice URL

8 : if an output does not replace an input it should not have the same features

- an output not replacing an input will have all the input features inherited, these can not be overwritten

9 : value must have an input value reference

- a value belonging to a feature having an input feature reference must correspond to a set of this input feature values

10 : multiple output feature values can not reference the same input value

- it us not allowed to reference the same input value more than once within the same input feature

11 : output features having no values or a single value should not have input reference

- it makes no sense for a feature having no values to have an input reference
- for a feature having a single value the value will always be the same, thus an input reference is redundant

12 : references must cover all the referred input feature values

- in case some referenced input feature values are unaccounted for, the output value will be undefined (invalid state)

13 : only one value is allowed, since input reference is not set

- in case an input reference is not set, an output must be deterministic

14 : output has no features

- output must have at least one feature, otherwise the webservice has no effect on the input