Basic concepts

The Veloconnect specification assumes the following model: Data are exchanged between a client (typically, a retailer's merchandise management program) and a server (typically, a wholesaler's or manufacturer's merchandise management program) in order to trigger certain business transactions such as ordering of goods. For the purposes of these business transactions, the client represents the buyer, and the server represents the seller.

Communication between client and server, as well as the resultant "ancillary effects" can be divided roughly into three layers:

• Transport: Transmission of data according to established standard protocols, such as http.

• Message: Syntax of transmitted data; rules determining the order in which data are to be transmitted.

• Business transaction: Meaning of transmitted data; which business transactions are triggered; what relationship do transmitted data have with existing merchandise management systems.

The subject of this specification is the layers comprising message and business transaction. Data syntax is determined by means of an XML schema. The sequence of messages is discussed and detailed in the overview further below. Also provided there are definitions for the business transaction layer, as necessitated by this specification. Particularly because data exchange via a Veloconnect interface is meant to trigger business transactions in the real world, such as ordering of goods, it is necessary to explicitly state the tacit conditions which play a role in the transition between the layers comprising message and business transaction. In addition, the buyer will make decisions on the basis of the information provided to them; they should therefore be able to rely on the transmitted information's quality and unambiguity (a common source of misunderstandings here are quantities and prices.)

Messages between the client and server are exchanged in operations. In an operation, the client submits a request to the server and receives a response from it. Request and response are defined as XML documents. More precisely: Prescribed for each message is the root element from the XML schema defined in the specification.

More complex message exchange scenarios, in which the server must retain state information, are modelled as Transactions. A transaction consists of several operations occurring in a precisely defined sequence. State-related information on the server, such as order data or the results of an item search, is referenced via a TransactionID relayed from one operation to the next.

The manner in which a message is delivered (transport layer) is determined by the binding which defines the protocol used for transmission and how to serialize the message.

Specified for each operation and transaction is whether it is mandatory or optional. The degree of commitment can also be formulated by requiring selection of at least one of several operations or transactions, or by making one operation enforce further operations. A Veloconnect-compliant server must implement a mandatory operation in at least one binding.

Mandatory operations include the GetProfile operation which allows a client to determine which transactions and operations a server supports with which bindings.