11.3 Operation Metadata

The following explains how SData encodes the various options in the metadata.

The metadata for an operation can be obtained by appending a $schema segment to the operation’s URL. For example:

http://www.example.com/sdata/myApp/myContract/-/products/$service/computeSimplePrice/$schema 

This URL works like the other SData schema URLs. It SHOULD redirect to an element that is defined in a global schema. The response to a GET on the above URL would typically be:

HTTP 302 Found
Location: http://www.example.com/sdata/myApp/myContract/-/$schema#productComputeSimplePrice 

The operation name has been prefixed by product to avoid a potential name clash with the same operation name in a different URL branch.

The global schema would contain the following element definition:

  <xs:element name="productComputeSimplePrice" 
              type="tns:productComputeSimplePrice--type"
              sme:role="serviceOperation"
              sme:path="products/$service/computeSimplePrice"
              sme:invocationMode="sync" 
              sme:batchingMode="syncOrAsync"/>
  <xs:complexType name="productComputeSimplePrice--type">
    <xs:all>
      <xs:element name="request" type="tns:simplePriceRequest--type" minOccurs="0" />
      <xs:element name="response" type="tns:simplePriceResponse--type" minOccurs="0" />
    </xs:all>
  </xs:complexType>
 
  <xs:complexType name="simplePriceRequest--type">
    <xs:all>
      <xs:element name="productID" type="xs:string" sme:label="Product ID" />
      <xs:element name="customerID" type="xs:string" sme:label="Customer ID" />
      <xs:element name="quantity" type="xs:decimal" sme:label="Quantity" />
    </xs:all>
  </xs:complexType>
 
  <xs:complexType name="simplePriceResponse--type">
    <xs:all>
      <xs:element name="unitPrice" type="xs:decimal" sme:label="Unit Price" />
      <xs:element name="quantityPrice" type="xs:decimal" sme:label="Quantity Price" />
      <xs:element name="discount" type="xs:decimal" sme:label="Discount" />
      <xs:element name="tax" type="xs:decimal" sme:label="Tax" />
    </xs:all>
  </xs:complexType>

  This schema follows the standard guidelines for SData schemas, with a few additional conventions and extensions:

• The operation type MUST be defined as an <xs:all> group with two elements called request and response (names are imposed). If the operation doesn’t have any input parameters, the request element MUST be omitted. If it doesn’t return any result, the response element MUST be omitted.

• SME (Simple Metadata Extension) attributes are used to encode the options. They are prefixed by sme: in the example.

The SME extensions used to encode service operation options are now described:

Attribute	Values	Applies to	Description
role	serviceOperation	operation element	Differentiates this element from "resource kind" elements.
path	relative URL	operation element	Relative URL to start the operation.
invocationMode	sync async syncOrAsync	operation element	Indicates whether the operation can be started synchronously, asynchronously or in both modes.
unsupported	true false (default)	operation element	Is the operation part of a global contract that it is not supported by this specific provider?
batchingMode	none sync async syncOrAsync	operation element	Does the operation start in batch mode, and how does it do this? Batching of service operations is similar to batching of CRUD operations. Requests and responses are feeds rather than single entries. See Batching section.
hasTemplate	true false (default)	operation element	Does the service provide a $template URL for this operation? See Operation Template section for details.
tags (1.1)	comma separated string	operation element	List of tags that apply to the operation. SData does not impose any predefined list of tags. Instead, each contract is free to define its own list of tags.

This schema fragment is the equivalent of web service definition language (WSDL) in the SData world.

SData providers MUST describe their service operations in the schema, in the format specified above.

---