Service Description

 

 

asrv.aero

Space template - use to copy space 

 

 

Until this note is removed the documentation is a work in progress, and revisions to the documentation will not be tracked.

 

Namespace: http://www.asrv.aero/webservices/1.0/

 

Document revisions

Date
Description
Author
yyyy-mm-dd First complete version of the documentationOle Nymoen

 

 

 

1. Introduction

1.1. Overview

This service description defines one service with a set of operations to ?????????????????. All data elements are defined by the Airport Data Dictionary.

 

Short description of service and operations

1.2. Implementation considerations

Any implementation of this service MUST use the WSDL and XSD files provided here: WSDL and XSDs

It is however up to the service provider which data elements to support, and how much data to return for requests spanning a long time period. To enable this most elements are optional. The reason for a service provider to not support all elements might be business rules related to data distribution, that it doesn't have the information, or that it wants to provide information in other (more restricted) ways.

Any service provider should make available documentation about the actual implementation, including:

    • the address of the service.
    • any limitations in the implementation.
    • recommended and allowed polling intervals.

 

1.3. Purpose of this service description

This service description has the following purpose:

      • Describe of service in enough detail for a service provider to implement it.
      • Describe the service so that a client (of this service) developer can use it.
      • Make available the WSDL and XSD files necessary to implement and use the service.
      • Make it possible for relevant people at airports, airlines, handlers and other aviation partners to understand the available functionality and then to decide if to implement/use it or not.

1.4. Intended readership

    • IT architects
    • Developers
    • Business architects
    • Interested parties in the aviation community

2. Service overview

The figure below shows the available operations on the FlightDataRequestService. The operations are described in detail in Service operations. All operations, apart from GetAlerts, have a basic and a full version. The "basic" version return a simplified data set and should be used where suitable to save processing power and bandwidth.

The operations can retrieve the following types of data:

  • Arriving flights
  • Departing flights
  • Turnarounds (arriving and departing flights connected)
  • Flight leg (departure and arrival)
  • Alerts

3. Service operations

3.1. GetFlightDataInbound( flightFilter: FlightFilter ) : GetFlightDataInboundResponse

Returns data about the set of inbound flights that fit the FlightFilter. 

Parameters:

filghtFilter: See definition of FlightFilter under Data entities.

Returns:

 

4. Data entities

4.1. Alert

flightLegIdentifier : FlightLegIdentifier

See definition of FlightLegIdentifier under Data entities.
alertStatusCode : AlertStatusCode

 
alertStatusText : AlertStatusText [0..1]  
active : boolean [0..1]  
alertLevel : AlertLevel [0..1]  

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.

 

4.2. ResponseStatus

statusCode : ResponseStatusCode

ResponseStatusCode indicates if the operation succeeded or failed, and if it failed - why. ResponseStatusText is a textual description of ResponseStatusCode. For all operations the set of response codes must be defined. The actual set is dependent upon the context.

 

  • "OK": Operation succeded.
  • "ERR01":
  • "ERR02":
  • "":
  • "":
  • "ERR99": Other error. "statusText" should describe the error.

 

Must be defined!
In addition there can be implementation specific responses. 
statusText : ResponseStatusText A textual description of ResponseStatusCode.

 

Unable to render {include} The included page could not be found.
 


5. XML Usage

5.1. Nil Values in Schema

For any particular data element, there is an important distinction between the following cases:

(a) the element is missing
(b) the element is present but has a 'nil' attribute assigned to it

In the first case, this means that the sender is supplying no information about the element. This would typically be because no information is available, or because there has been no change in the value of the element. A recipient would not be expected to take any action as a result of this. In particular, it would not be expected to clear any existing value.

In the second case, this means that the sender has explicitly cleared the element. As a result of this, a recipient would typically clear any value that it had previously stored for this element.

The following table shows an example sequence of messages, and the expected actions taken by the data recipient. It should be noted, however, that the action is up to the recipient. The message from the sender is a notification, and not a command for the recipient to take action.

Message contents

Expected action by recipient

aircraftRegistration element missing

Does not set or change aircraft registration value

<aircraftRegistration>ABC123</aircraftRegistration>

Sets the value to ABC123

aircraftRegistration element missing

Does not change the value

<aircraftRegistration xs:nil=’true’>

Clears the aircraftRegistration value

Note that the sender should not use blank data elements such as <aircraftRegistration/> or <aircraftRegistration></aircraftRegistration> as these may cause validation errors. For example, if the schema specifies a format or a minimum length for an element, then a zero-length element will be invalid. This problem does not occur if using the nil attribute.

Note - Where a field is defined as mandatory in the schema, it must not contain a nil value.

6. WSDL and XSDs

 

 

 

 

  • No labels