PROVIDER_SIDE

All the reverse entity references for this entity

The interface for the service is provide via HTTP API and it is described fully in Github: https://github.com/fmidev/smartmet-plugin-timeseries/wiki/Using-the-Tim…

Operations

The interface for the service is provided via HTTP API. Message exchange pattern is request-response type. Typically the user makes a request to the server and in response gets the time series file to a single desired point.

Idempotent
NON_IDEMPOTENT
Synchronous
SYNCHRONOUS
TI Protocol Methods
HTTP GET
Processing Consideration
Behaviour
Interface Binding Description

The user interface of the service is provided as a time series download service via HTTP. Message exchange pattern is request-response type. Typically the user makes a request to the server and in response gets the time series file to a single desired point.

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

The interface for the service is provided as a GRIB2 download service via HTTP and it is described fully in Github: https://github.com/fmidev/smartmet-plugin-download/wiki/SmartMet-plugin…

Operations
Behaviour
Interface Binding Description

The interface for the service is provided as a GRIB download service via HTTP. Message exchange pattern is request-response type. Typically the user makes a request to the server and in response gets a GRIB file.

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

The interface for the service is provided as a GRIB2 download service via HTTP and it is described fully in Github: https://github.com/fmidev/smartmet-plugin-download/wiki/SmartMet-plugin…

Operations

The interface for the service is provided as a GRIB download service via HTTP. Message exchange pattern is request-response type. Typically the user makes a request to the server and in response gets a GRIB file.

Idempotent
NON_IDEMPOTENT
Synchronous
SYNCHRONOUS
TI Protocol Methods
HTTP GET
Processing Consideration
Behaviour
Interface Binding Description

The interface for the service is provided as a GRIB download service via HTTP. Message exchange pattern is request-response type. Typically the user makes a request to the server and in response gets a GRIB file.

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

Subscription management interface.The service consumer is able to subscribe and unsubscribe to the arrival sequence information and by using the same interface, the consumer is able to send problem reports.

Operations

Operation to log a problem in the DSNA monitoring system

Idempotent
IDEMPOTENT
Synchronous
SYNCHRONOUS
Precondition
To have a valid certificate
TI Protocol Methods
SOAP over HTTPS: SOAP 1.1 / HTTP 1.1 / TLS 1.2 / TCP / IPv4
Operation Message
Processing Consideration
Interface Binding Description

SOAP over HTTPS: SOAP 1.1 / HTTP 1.1 / TLS 1.2 / TCP / IPv4

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

Interface role

The Subscription Management interface allows the management of subscriptions to the other services by External Users. External Users are able to receive the information of their interest generated by the ASM Support Systems and provided via the interfaces. Each interface applies filtering options in order to ensure data provision aligned with the requirements of the External User.

The interface allows for the creation and deletion of subscriptions to consume data from all other ASM service interfaces. A client may create a subscription to a single topic with each request but only one subscription per topic may be created at a time. In response the client will receive the name of an AMQP message queue. The name can then be supplied when creating subscriptions for additional topics to use the same queue. The client can consume the messages from the queue with the given name.

Figure 7 in Section 2.4.2.1 provides an overview of the Subscription Management interface

The elements in the data model are described in full detail in section 2.7.4.

Information Exchange Flow

The diagram in Section 2.4.2.2 presents the information exchange flow for the Subscription Management interface.  

Interface Functions

The Service interface performs the following functions:

o   Creating a Subscription introduces a new Subscription into the ASM Support System.

o   Starting a Subscription starts an existing Subscription in the ASM Support System.

o   Stopping a Subscription stops an existing Subscription in the ASM Support System.

o   Deleting a Subscription allows for deletion of an existing Subscription.

o   Listing existing Subscriptions provides access to existing Subscriptions in the ASM Support System for the External User.

ASM-INTF-SUBS-010: ASM Service shall be supported by the Subscription Management interface to manage the subscriptions

ASM-INTF-SUBS-020: The Subscription Management interface shall support the following operations:

o   createSubscription,

o   startSubscription,

o   stopSubscription,

o   deleteSubscription,

o   listSubscriptions.

 

Operations

This operation is intended to create a subscription in the ASM Support System in response to a request from an External User. As a result, a subscription is either created in the local ASM Support System and the External User is notified, or a subscription is not created and an appropriate error message is transmitted to the External User.

It is down to the implementation as to whether or not subscriptions need to be remade at any other subsequent connection.

Associated messages

ASM-INTF-SUBS-030: The createSubscription operation shall receive and process the SubscriptionCreationRequest message from an External User.

ASM-INTF-SUBS-040: If no queue name is provided in the SubscriptionCreationRequest message the service shall assign a queue name to the External User subscription.

ASM-INTF-SUBS-050: If an active queue name is provided in the SubscriptionCreationRequest message the service shall reuse this queue name for the External User subscription.

Note: The queue name allows for connection to an Advanced Message Queuing Protocol (AMQP) message queue.

ASM-INTF-SUBS-070: The service shall apply the filters defined in the SubscriptionCreationRequest to all data notified via the AMQP message queue.

ASM-INTF-SUBS-080: The createSubscription operation shall validate the SubscriptionCreationRequest message against the following criteria which must be met:

o   All mandatory data for SubscriptionCreationRequest message are provided

o   The requestor does not have an existing PAUSED or ACTIVE subscription for the same topic.

o   If a queue name is set in the SubscriptionCreationRequest message it must match an existing queue name belonging to the requestor.

o   The filters provided in the SubscriptionCreationRequest message must be applicable to the topic being subscribed for. Acceptable filters are defined by the query operation in this document that maps to the subscription topic. 

ASM-INTF-SUBS-090: If the subscription request is valid, the createSubscription operation shall transmit the details of the newly created subscription, including the name of the AMQP queue to be used, in the SubscriptionCreationReply message to the requesting External User. 

ASM-INTF-SUBS-100: The subscription shall always be created in the ‘PAUSED’ state.

ASM-INTF-SUBS-110: If the request or the resulting subscription is not valid, the createSubscription operation shall transmit an appropriate error in the SubscriptionCreationReply message to the requesting External User.

ASM-INTF-SUBS-115: The service provider should define a TTL (Time-To-Live) for messages of each subscription topic.

Note: The definition of these messages can be found in section 2.7.3 Interface Messages.

Idempotent
NON_IDEMPOTENT
Synchronous
SYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Processing Consideration

This operation is intended to start a subscription process in the ASM Support System in response to a request from an External User. As a result, a subscription process is either started in the local ASM Support System and the External User starts receiving subscribed data, or a subscription is not started, and an appropriate error message is transmitted to the External User. Once the subscription has started HeartbeatTechnicalMessages may be sent by the ASM Support System.

Associated messages

ASM-INTF-SUBS-120: The startSubscription operation shall receive and process the SubscriptionCreationRequest message from an External User.

ASM-INTF-SUBS-130: The startSubscription operation shall validate the SubscriptionStartRequest message against the following criteria which must be met:

o   All mandatory data for SubscriptionStartRequest message are provided,

o   The identified subscription to be started must belong to the requestor,

o   The identified subscription to be started must be PAUSED.

ASM-INTF-SUBS-140: If the request is valid, the startSubscription operation shall return the SubscriptionStartReply message to the requesting External User.

ASM-INTF-SUBS-150: The SubscriptionStartReply message shall contain the details of the subscription, including the name of the queue to be used and the state which will be ‘ACTIVE’.                             

ASM-INTF-SUBS-160: If the request is not valid, the startSubscription operation shall transmit an appropriate error in the SubscriptionStartReply message to the requesting External User.

ASM-INTF-SUBS-163: HeartbeatTechnicalMessages should be published at least every maximum-message-interval once the subscription is in state ‘ACTIVE’.

ASM-INTF-SUBS-165: HeartbeatTechnicalMessages should be postponed if a subscription message is sent to the queue before the maximum-message-interval expires.

ASM-INTF-SUBS-167: The service provider should define a maximum-message-interval defining the interval between HeartbeatTechnicalMessages published to the queue.

ASM-INTF-SUBS-168: The service provider shall pause a subscription and publish a SubscriptionTechnicalMessage if any message published to the queue expires. 

Note: The definition of these messages can be found in section 2.7.3 Interface Messages.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Processing Consideration

This operation is intended to stop a subscription process in the ASM Support System in response to a request from an External User. As a result, a subscription process is either stopped in the local ASM Support System and the External User stops receiving subscribed data, or a subscription is not stopped and an appropriate error message is transmitted to the External User. Once the subscription has stopped HeartbeatTechnicalMessages can be stopped by the ASM Support System.

Associated messages

ASM-INTF-SUBS-170: The stopSubscription operation shall receive and process the SubscriptionStopRequest message from an External User.

ASM-INTF-SUBS-180: The stopSubscription operation shall validate the SubscriptionStopRequest message against the following criteria which must be met:

o   All mandatory data for SubscriptionStopRequest message are provided,

o   The identified subscription to be stopped must belong to the requestor,

o   The identified subscription to be stopped must be ‘ACTIVE'.

ASM-INTF-SUBS-190: If the request is valid, the stopSubscription operation shall return the SubscriptionStopReply message to the requesting External User.

ASM-INTF-SUBS-200: The SubscriptionStopReply message shall contain the details of the subscription, including the name of the queue to be used and the state which will be ‘PAUSED’.                             

ASM-INTF-SUBS-210: If the request is not valid, the stopSubscription operation shall transmit an appropriate error in the SubscriptionStopReply message to the requesting External User.

ASM-INTF-SUBS-215: The stopSubscription operation may optionally stop the HeartbeatTechnicalMessages while the subscription is in the state PAUSED by adding the attribute heartbeatEnabled with the value false to the StopSubscriptionRequest.

ASM-INTF-SUBS-217: The server should publish a SubscriptionTechnicalMessage to the subscription queue when the server itself has PAUSED the subscription, independent of the external user requesting to PAUSE the subscription via the stopSubscription operation. 

Note: The definition of these messages can be found in section 2.7.3 Interface Messages.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to section 2.5 Technologies
Processing Consideration

This operation is intended to delete a subscription in the ASM Support System in response to a request from an External User. As a result, a subscription is either deleted in the local ASM Support System and the External User is notified, or a subscription is not deleted and an appropriate error message is transmitted to the External User.  If a subscription is deleted and no other subscriptions reference its message queue then the queue will be deleted.

Associated messages

ASM-INTF-SUBS-220: The deleteSubscription operation shall receive and process the SubscriptionDeletionRequest message from an External User.

ASM-INTF-SUBS-230: The deleteSubscription operation shall validate the SubscriptionDeletionRequest message against the following criteria which must be met:

o   All mandatory data for SubscriptionDeletionRequest message are provided

o   The identified subscription to be deleted must belong to the requestor.

 ASM-INTF-SUBS-240: If the request is valid, the deleteSubscription operation shall return confirmation that the subscription has been deleted in the SubscriptionDeletionReply message to the requesting External User.

ASM-INTF-SUBS-250: If the request is valid and the subscription’s queue is no longer in use by any other subscriptions, the queue shall be deleted.

ASM-INTF-SUBS-260: If the request is not valid, the deleteSubscription operation shall transmit an appropriate error in the SubscriptionDeletionReply message to the requesting External User.

Note: The definition of these messages can be found in section 2.7.3 Interface Messages.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Processing Consideration

This operation is intended to allow the External User to list the subscriptions currently established for that specific External User.

This method returns all the subscriptions owned by the calling External User.

Associated messages

ASM-INTF-SUBS-270: The listSubscriptions operation shall receive and process the SubscriptionListRequestSubscriptionDeletionRequest message from an External User.

ASM-INTF-SUBS-280: The listSubscriptions operation shall validate the SubscriptionListRequest message to ensure that any subscriptionStates listed in the request are valid.

ASM-INTF-SUBS-290: If the request is valid, the listSubscriptions operation shall return a SubscriptionListReply containing:

- a list of subscriptions owned by the calling External User that match one of the subscription states listed in the SubscriptionListRequest,

- or all subscriptions owned by the calling External User if no subscription states were provided in the SubscriptionListRequest.

Note: The definition of these messages can be found in section 2.7.3 Interface Messages.

Idempotent
NON_IDEMPOTENT
Behaviour
Interface Binding Description

N/A

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

The complete API description is available on MetSafe user portal accessible through a Token. 

Operations

Main production endpoint.

{base_url_prod} is kept confidential for security reason.

Url

{base_url_prod}/expert/vigiaero/

Addressable Resource

Integration is for test purpose.

{base_url_int} is kept confidential for security reason.

Url

{base_url_int}/expert/vigiaero/

Addressable Resource
Behaviour
Interface Binding Description

Https Request Replay with token authentication

Interface Provision Side
Service Interface Binding
Network Interface Binding

The RequestData interface is used by the consumer to finally retrieve the data.

Operations

Make a WFS2.0 request to retrieve data.

Idempotent
IDEMPOTENT
Synchronous
ASYNCHRONOUS
Precondition
For making the request the user has to build the WFS request-link from baseUrl and relPath in the notification message. Furthermore the user needs credential for access.
TI Protocol Methods
http(s) get
Operation Message
Processing Consideration

This is where the consumer finally requests the data.

Url

maps.dwd.de

Behaviour
Interface Binding Description

TI Yellow Profile (?)

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

The SSR code management service allows a client to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr service call), and to clear such code from display in the whole OPS sector.An SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be reserved during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time. When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the SsrCode Distribution service) is sent. As such, subscription to the SsrCode distribution service is mandatory prior the user requesting modifications.

Operations

No operation defined

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Behaviour
Interface Binding Description

AMQP 1.0 content-type header used to specify media type values

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

The sectorisation management service provides any connecting client with the means to perform a re-sectorisation change. Two kind of requests can be made, being: • A request to verify a new sectorisation change (i.e. would the request once executed be valid for the server?), • A request to perform a sectorisation change. When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the Sectorisation Distribution service) is sent. As such, subscription to the Sectorisation distribution service is mandatory prior the user requesting sectorisation modifications.

Operations

No operation defined

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Behaviour
Interface Binding Description

AMQP 1.0 content-type header used to specify media type values

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding

The Flight Bright Management service allows any connecting CWP client to perform inputs related to highlight of a track or flight plan, more specifically: • SSR Bright: o Add an SSR Code to the SSR Bright function for his OPS sector o Cancel all SSR Codes from the SSR Bright function for his OPS sector o Delete one SSR Code from the SSR Bright function for his OPS sector • ModeS Bright: o Add an ModeS callsign to the ModeS Bright function for his OPS sector o Cancel all ModeS callsign from the ModeS Bright function for his OPS sector o Delete one ModeS callsign from the ModeS Bright function for his OPS sector • FPL Bright: o Add a flight to the FPL Bright function for his OPS sector o Delete a flight from the FPL Bright function for his OPS sector o Add a flight to the FPL Bright function of another internal OPS Sector (by specifying an internal flight sector) o Point a flight to an external flight sector / centre When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the Flight Bright Distribution service) on the flight is sent. As such, subscription to the Flight Bright distribution service is mandatory prior the user requesting modifications. Please do note that the distribution of the FlightBright message is OPS sector oriented.

Operations

No Operation Defined

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Behaviour
Interface Binding Description

AMQP 1.0 content-type header used to specify media type values

Interface Provision Side
TI Primitive Message Exchange Pattern
Service Interface Binding
Network Interface Binding