Request Type
An element of type vct:RequestType has the following constituents:
Name | Type/occurrence | Description |
|---|---|---|
vct:BuyersID | udt:IdentifierType | Buyer's ID, e.g. customer number. |
vct:Credential | Client authorization; see below. | |
vct:TransactionID | xsd:normalizedString? | Transaction instance identifier. |
vct:IsTest | xsd:boolean? | Indicator as to whether the operation should only be performed as a test (refer to test operation). |
The definition of type vct:credentialtype appears redundant, but is chosen so as to support further authentication mechanisms (such as certificates) possibly resulting from later extensions.
Name | Type/occurrence | Description |
|---|---|---|
vct:Password | xsd:string | Password. |
Defined as a constraint of type vct:RequestType is the type vct:TransactionRequestType; the constraint dictates use of the element vct:TransactionID.
Rule SellersID
The optional SellersID element in requests and responses was provided until Veloconnect 1.1, in case a server hosted a Veloconnect implementation under the same URL for different vendors. Because this option has never been used, and it is also technically easy to separate different vendors on a Veloconnect server implementation via different access URLs, this element may no longer be used from Veloconnect 1.3 onward.
Serialization of RequestType elements
To serialize a URL binding, a request must first be represented as a sequence of parameters. Parameter names are as follows:
RequestName
BuyersID
Password
TransactionID
IsTest
Version
Further parameters might also be specified in the respective definitions of the operations. Serving as the value of each specified parameter is the content of the identically named sub-element of the respective request element, or the name of the element itself in the case of the "RequestName" parameter.
Rule: Version parameter
Only the following values are permissible for the version parameter: 1.0, 1.1, 1.2, 1.3.
Impermissible values for versions are to be ignored by the server.
If a value for a version is permissible, the server responds according to the latest version of the specification which it supports and which is less than or equal to the version specified in the version parameter.
The version parameter has only been introduced with veloconnect 1.3, i.e. servers which only support an older version of the specification ignore this parameter.
Servers which already support veloconnect 1.3 can use this parameter to maximize downward compatibility with clients which do not yet support veloconnect 1.3, by proceeding according to veloconnect 1.1 in an absence of the parameter version.
Clients which already support veloconnect 1.3 should always use the parameter version.