-
Notifications
You must be signed in to change notification settings - Fork 0
home
El caso de uso 11 está dedicado a la información relativa a aparcamientos.
Este caso de uso pretende la recopilación y publicación de forma centralizada y homogénea la información en tiempo real relativa a aparcamientos en las ciudades españolas. Los agentes/terceros interesados pueden consumir la información mediante la suscripción. Permite en tiempo real por parte de los suministradores el envío de la información a la plataforma DGT 3.0 sobre la disponibilidad plazas de aparcamiento. Los consumidores podrán publicar la información en sus sistemas de información accesibles por el usuario final permitiendo a este planificar mejor sus desplazamientos y considerar el uso del transporte público.
La plataforma cuenta con dos funcionalidades diferenciadas para la publicación (envío) y para la suscripción (recepción) de información. La primera es a través de una API REST y la segunda a través de un servicio MQTT en tiempo real.
La funcionalidad de publicación requiere de certificados de acceso que deben ser solicitados y suministrados por DGT 3.0. Estos certificados, de no haber sido solicitados ya, se deberán solicitar a soporte@cmobility30.es.
A continuación se muestran las URLs con las que se accede a cada funcionalidad:
| Modo | URL | Descripción |
|---|---|---|
| Publicación | https://pre.cmobility30.es/use-case-11 | Endpoint del entorno de integración de clientes para la publicación (ciertos métodos de publicación serán accesibles para el consumo) |
| Suscripción | ssl://production.cmobility30.es:8883 | Endpoint para la suscripción |
A continuación se describen las dos funcionalidades.
Este caso de uso dispone de una API REST para la publicación (envío) de los datos por parte de las empresas que así lo deseen. En los siguientes apartados se pueden encontrar los detalles de esta:
- Los detalles generales para realizar una petición:
- Información relativa a los métodos específicos del caso de uso:
Nota: Algunos métodos de publicación para la obtención de información también podrán ser utilizados por los consumidores .
Este caso de uso también dispone de un servicio de suscripción (recepción) de datos por parte de las empresas que así lo deseen mediante el protocolo MQTT. A continuación se pueden encontrar los detalles de esta:
MQTT (MQ Telemetry Transport) es un protocolo de mensajería que se usa como un método simple y liviano para transferir datos hacia/desde dispositivos de baja potencia.
El protocolo admite un único patrón de mensajería, el patrón Publicar-Suscribir: cada mensaje es publicado en un tópico al que se debe suscribir para recibir la información.
La suscripción al servicio de este caso de uso deberá ser mediante el tópico:
out_usecase11_free_capacity
En el tópico se publican los eventos en formato JSON. Aquí se puede ver un ejemplo:
{
"cityIne": 50297,
"parkingId": 1,
"parkingName": "Test",
"free": 14,
"timestamp": "2021-03-15T13:34:00.000Z"
}-
cityIne (número entero): identificador del municipio donde se genera el evento según el INE
-
parkingId (número entero): identificador del aparcamiento
-
parkingName (texto): nombre del aparcamiento
-
free (número entero): número de plazas libres del aparcamiento
-
timestamp (fecha UTC): fecha y hora en formato UTC del momento en el que el parking se ha actualizado por última vez. Es necesario que no sea un timestamp futuro con respecto a la hora UTC actual. La fecha debe finalizar con el caracter 'Z' que marca que está en UTC
Ver más información y un ejemplo de conexión aquí.
Además los suscriptores también podrá acceder a los siguientes métodos de publicación de la API REST para la obtención de información:
- Información relativa a los métodos específicos de publicación accesibles:
Nota: La información que se está publicando en el entorno de desarrollo es una simulación con información no real que va cambiando a lo largo del día, de forma que se pueda probar la interface de consumo.
Como se ha indicado anteriormente, todas las respuestas HTTP que no sean 200 – OK, se pueden considerar inválidas. El formato de la respuesta de error es como el siguiente ejemplo:
{
"status": 401,
"code": 1,
"message": "User not found or valid"
}*Esto no aplica para el Caso de Uso 11 - Parkings. La información relativa a los errores en ese caso se puede encontrar aquí.
Estos errores tendrán tres categorías principales:
-
HTTP Status: 401 - Unauthorized
Code Message 1 User not found or valid
-
HTTP Status: 400 - Bad Request
Code Message 0 Authenticate 2 Entity ID not found 3 Missing required property 4 The entity received cannot be proccessed 5 Incorrect token received 6 Expired token received 7 There is an error with the token provided. Please request a new one 8 No token received 9 Required request body is missing 10 Event is marked as expired by timestamp 11 Missing request header 12 Access denied role 13 Unique key violated.In the INE code XXX, the first parkingId available is YYY 14 There is an error in one or more elements 15 Free capacity should not be greater than total capacity 16 Invalid GeoJson 17 GeoJson does not belong to municipality 18 Timestamp can not be future 19 Day of week not valid. Allowed values: 'L','M','X','J','V','S','D' 20 TimeTable should not have duplicated days 21 Inconsistent time range: startTime should be before endTime 22 Inconsistent time range: there is a crossing schedule 23 There was an error when creating the Datex II file 24 There are no parkings in municipality or the provided INE code is not correct
En el caso de obtener un error 3 - Missing required property la respuesta obtenida tendrá un valor en el message que nos indicará los campos que faltan por enviar:
{
"status": 400,
"code": 3,
"message": "[cityIne: must not be null, parkingId: must not be null, timestamp: must not be null]"
}-
HTTP Status: 500 - Internal Server Error
Code Message 25 Internal error