commerce-xapi-services – Normalización de Direcciones Geográficas
Endpoint
Endpoint: /v1/normalizeAddress
Método: GET
Versión: 1.0.2
Tipo de API: Experience API (XAPI)
Categoría: Geographic Address Management
Estándar TM Forum: TMF673 v4
Equipo Responsable: ETB Development Team
Contacto: development@etb.com.co
Fecha de Creación: 2025-01-08
Última Actualización: 2025-01-08
Control de Versiones del Documento
| Versión Documento | Versión API | Fecha | Autor | Descripción de Cambios |
|---|---|---|---|---|
| 1.0.0 | 1.0.2 | 2025-01-08 | ETB Development Team | Documentación inicial del servicio |
Proceso de Detección de Cambios
OBLIGATORIO: Antes de actualizar el documento, realizar las siguientes verificaciones:
Verificar Existencia del Documento:
bashls -la docs/services/commerce-xapi-normalizeAddress-v1.mdComparar Información Básica:
- Endpoint actual vs anterior
- Método HTTP actual vs anterior
- Versión API actual vs anterior
- Versión del documento actual vs anterior
Detectar Cambios Específicos:
- Cambios en endpoints o rutas
- Cambios en métodos HTTP
- Cambios en parámetros de request/response
- Cambios en esquemas de datos
- Cambios en dependencias
- Cambios en configuraciones
- Cambios en documentación
Actualizar Tabla de Control de Versiones:
- Si NO hay cambios: Mantener tabla existente
- Si HAY cambios: Agregar nueva fila con:
- Versión documento incrementada
- Versión API actual
- Fecha actual
- Autor actual
- Descripción detallada de cambios detectados
Ejemplos de Descripción de Cambios:
- "Documentación inicial del servicio"
- "Actualizado endpoint de /v1/oldEndpoint a /v1/newEndpoint"
- "Agregado nuevo parámetro 'newParam' en request"
- "Cambiado método de POST a GET"
- "Actualizada versión de API de 1.0.1 a 1.0.2"
- "Agregada nueva dependencia 'new-service'"
- "Corregido ejemplo de cURL con nuevos headers"
- "Actualizada documentación de errores"
1. Resumen del Servicio
El servicio commerce-xapi-services proporciona funcionalidades de normalización y georreferenciación de direcciones geográficas según el estándar TM Forum TMF673 v4. El endpoint /v1/normalizeAddress permite consultar direcciones vecinas luego de normalizar y georreferenciar, aplicando manejo de mensajes estándar.
Características Principales:
- Normalización de direcciones geográficas
- Georreferenciación automática
- Cumplimiento con estándar TMF673 v4
- Integración con servicios internos de ETB
- Manejo de errores estándar TM Forum
2. Descripción Funcional
El servicio actúa como una capa de experiencia (XAPI) que orquesta la normalización de direcciones geográficas. Recibe parámetros de entrada que incluyen la dirección a normalizar, código de municipio y código de departamento, y retorna información normalizada y georreferenciada.
Flujo de Procesamiento:
- Recepción de request con parámetros de dirección
- Validación de parámetros requeridos
- Transformación de datos para servicio interno
- Invocación al servicio commerce-papi-services
- Procesamiento de respuesta
- Transformación y retorno de datos normalizados
3. Casos de Uso
Caso de Uso Principal: Normalización de Dirección
Descripción: Un cliente requiere normalizar una dirección para verificar cobertura de servicios.
Flujo:
- Cliente envía dirección con parámetros requeridos
- Sistema valida parámetros de entrada
- Se normaliza la dirección según estándares internos
- Se georreferencia la ubicación
- Se retorna información normalizada con coordenadas
Parámetros de Entrada:
address: Dirección a estandarizar (requerido)municipalityCod: Código de municipio (requerido)departamentCod: Código de departamento (requerido)
4. Especificación de Contrato
4.1 Endpoints y Métodos
| Endpoint | Método | Descripción | Estándar |
|---|---|---|---|
/v1/normalizeAddress | GET | Normalización de direcciones geográficas | TMF673 v4 |
4.2 Esquemas de Datos (JSON Schema)
Request Schema
json
{
"type": "object",
"properties": {
"address": {
"type": "string",
"description": "Dirección a estandarizar",
"example": "Diagonal 159B 14a 40 int 21",
"required": true
},
"municipalityCod": {
"type": "string",
"description": "Código de Municipio asociado a la dirección",
"example": "11001",
"required": true
},
"departamentCod": {
"type": "string",
"description": "Código de departamento asociado a la dirección",
"example": "11",
"required": true
}
},
"required": ["address", "municipalityCod", "departamentCod"]
}Response Schema
json
{
"type": "object",
"properties": {
"Success": {
"type": "boolean",
"description": "Indicador de éxito de la operación",
"example": true
},
"DataList": {
"type": "any",
"description": "Lista de datos (opcional)",
"example": null
},
"DataArray": {
"type": "any",
"description": "Array de datos (opcional)",
"example": null
},
"DataSingle": {
"type": "object",
"properties": {
"Addresses": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {
"type": "string",
"description": "Identificador único de dirección",
"example": "612802304622340077"
},
"fullAddress": {
"type": "string",
"description": "Dirección detallada",
"example": "CL 94A 67A 74 LC 18"
},
"Direccion_Actual": {
"type": "string",
"description": "Dirección inicial o base",
"example": "CL 94A 67A 74"
},
"residentialType": {
"type": "string",
"description": "Estrato Catastro",
"example": "6"
},
"municipalityCode": {
"type": "string",
"description": "Id Municipio",
"example": "11001"
},
"Check": {
"type": "boolean",
"example": false
}
}
}
}
}
},
"Message": {
"type": "string",
"description": "Mensaje informativo",
"example": ""
},
"Results": {
"type": "integer",
"description": "Número de resultados",
"example": 0
},
"MessageObj": {
"type": "any",
"description": "Objeto de mensaje (opcional)",
"example": null
}
}
}4.3 Ejemplos de Request / Response
Request Example
bash
GET /v1/normalizeAddress?address=Diagonal%20159B%2014a%2040%20int%2021&municipalityCod=11001&departamentCod=11Response Example (Success)
json
{
"Success": true,
"DataList": null,
"DataArray": null,
"DataSingle": {
"Addresses": [
{
"id": "612802304622340077",
"fullAddress": "CL 94A 67A 74 LC 18",
"Direccion_Actual": "CL 94A 67A 74",
"residentialType": "6",
"municipalityCode": "11001",
"Check": false
}
]
},
"Message": "",
"Results": 1,
"MessageObj": null
}Response Example (Error)
json
{
"code": "400",
"reason": "Invalid field value",
"message": "The value provided for 'address' is not valid.",
"status": "Bad Request",
"referenceError": "ERR-NA-001",
"timestamp": "2025-01-08T16:52:00Z",
"@type": "Error",
"@baseType": "Entity",
"@schemaLocation": "https://etb.com.co/schema/Error"
}4.4 Códigos de Error
| Código | Descripción | Causa |
|---|---|---|
| 400 | Bad Request | Parámetros inválidos o faltantes |
| 404 | Not Found | Recurso no encontrado |
| 405 | Method Not Allowed | Método HTTP no permitido |
| 406 | Not Acceptable | Content-Type no aceptado |
| 415 | Unsupported Media Type | Tipo de medio no soportado |
| 500 | Internal Server Error | Error interno del servidor |
| 501 | Not Implemented | Funcionalidad no implementada |
| 503 | Service Unavailable | Servicio no disponible |
4.5 Comandos cURL para Postman
Ejemplo Básico
bash
curl -X GET \
'https://commerce-xapi-services-qa.us-e2.cloudhub.io/v1/normalizeAddress?address=Diagonal%20159B%2014a%2040%20int%2021&municipalityCod=11001&departamentCod=11' \
-H 'Content-Type: application/json' \
-H 'X-Correlation-ID: 12345678-1234-1234-1234-123456789012'Ejemplo con Headers de Autenticación
bash
curl -X GET \
'https://commerce-xapi-services-qa.us-e2.cloudhub.io/v1/normalizeAddress?address=Diagonal%20159B%2014a%2040%20int%2021&municipalityCod=11001&departamentCod=11' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
-H 'X-Correlation-ID: 12345678-1234-1234-1234-123456789012' \
-H 'X-Request-ID: 87654321-4321-4321-4321-210987654321'5. Métricas y SLA
Métricas de Rendimiento
- Response Time: < 2 segundos (95th percentile)
- Availability: 99.9%
- Throughput: 1000 requests/segundo
- Error Rate: < 0.1%
SLA (Service Level Agreement)
- Uptime: 99.9% mensual
- Response Time: < 2 segundos para requests válidos
- Error Rate: < 0.1% para requests válidos
- Recovery Time: < 5 minutos para recuperación de errores
6. Dependencias y Compatibilidad
6.1 Dependencias Internas
- commerce-papi-services: Servicio interno para normalización de direcciones
- etb-common-lib: Librería común de ETB para funcionalidades compartidas
- audits-oracle-sapi-services: Servicio de auditoría y logging
6.2 Dependencias Externas
- Mule Runtime 4.4.0: Plataforma de ejecución
- Java 17: Runtime de Java
- Anypoint Platform: Plataforma de gestión de APIs
6.3 Compatibilidad
- Mule Runtime: 4.4.0
- Java: 17
- Protocolos: HTTPS, HTTP
- Plataformas: CloudHub, Anypoint Platform
6.4 Modelos Base Utilizados
Descripción: Documenta los modelos de datos base y patrones de respuesta utilizados en el servicio.
- geographicAddress: Modelo base para direcciones geográficas según TMF673
- error-response: Modelo estándar de errores según TM Forum
- request_headers: Trait para headers de request estándar
- Queryparams: Modelo para parámetros de consulta
6.5 Utilidades y Servicios Comunes
Descripción: Identifica las utilidades, librerías y servicios comunes utilizados por el servicio.
- etb-common-lib: Librería común de ETB con utilidades compartidas
- mule-apikit-module: Módulo para manejo de APIs con RAML
- mule-http-connector: Conector HTTP para comunicaciones
- mule-sockets-connector: Conector de sockets para comunicaciones
6.6 Patrones de Diseño Implementados
Descripción: Documenta los patrones de diseño arquitectónico y de código utilizados.
- API Gateway Pattern: Patrón de puerta de enlace para APIs
- Orchestration Pattern: Patrón de orquestación para flujos de datos
- Error Handler Pattern: Patrón de manejo centralizado de errores
- Configuration Pattern: Patrón de configuración externalizada
- TLS Security Pattern: Patrón de seguridad con certificados TLS
6.7 Componentes Reutilizados
Descripción: Lista los componentes, módulos o funcionalidades reutilizadas de otros servicios.
- HTTP Request Configuration: Configuración reutilizada para requests HTTP
- Error Handler: Manejador de errores reutilizado
- Logging Sub-Flow: Subflujo de logging reutilizado
- Audit Client: Cliente de auditoría reutilizado
- TLS Context: Contexto de seguridad TLS reutilizado
6.8 Referencias Cruzadas
Descripción: Documenta las referencias y relaciones con otros servicios, APIs o sistemas.
- commerce-papi-services: Servicio interno para procesamiento de direcciones
- audits-oracle-sapi-services: Servicio de auditoría y logging
- Anypoint Platform: Plataforma de gestión de APIs
- CloudHub: Plataforma de ejecución en la nube
- TM Forum TMF673: Estándar de gestión de direcciones geográficas
7. Diagramas
7.1 Arquitectura Global por Capas
Diagrama de Arquitectura de Alto Nivel
mermaid
graph TB
subgraph "Capa de Presentación/API"
A[Cliente/Consumidor]
B[Load Balancer]
C[API Gateway]
end
subgraph "Capa de Orquestación/Flujo"
D[Flujos de Mule]
E[Transformaciones]
F[Lógica de Negocio]
end
subgraph "Capa de Integración"
G[Conectores HTTP]
H[Conectores Database]
I[Conectores Externos]
end
subgraph "Capa de Datos"
J[Base de Datos Principal]
K[Cache/Redis]
L[Almacenamiento]
end
subgraph "Capa de Seguridad"
M[OAuth Provider]
N[Rate Limiting]
O[Encryption]
end
subgraph "Capa de Monitoreo"
P[Logging]
Q[Métricas]
R[Alertas]
end
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
F --> H
F --> I
G --> J
H --> J
I --> K
C --> M
M --> N
N --> O
D --> P
P --> Q
Q --> RDiagrama de Arquitectura por Capa Específica
OBLIGATORIO: Generar diagrama específico para cada capa identificada:
Capa de Presentación/API:
mermaid
graph LR
subgraph "Capa de Presentación"
A1[Controller]
A2[Validaciones]
A3[Documentación API]
A4[Headers Management]
end
A1 --> A2
A2 --> A3
A3 --> A4Capa de Orquestación/Flujo:
mermaid
graph LR
subgraph "Capa de Orquestación"
B1[Flujo Principal]
B2[Subflujos]
B3[Transformaciones]
B4[Error Handlers]
end
B1 --> B2
B2 --> B3
B3 --> B4Capa de Integración:
mermaid
graph LR
subgraph "Capa de Integración"
C1[HTTP Connectors]
C2[Database Connectors]
C3[External APIs]
C4[Protocol Handlers]
end
C1 --> C2
C2 --> C3
C3 --> C47.2 Flujo de Datos por Capa
Diagrama de Flujo Detallado del Proceso
OBLIGATORIO: Generar diagrama de flujo que muestre el proceso completo:
mermaid
flowchart TD
A[Request Incoming] --> B{Validar Headers}
B -->|Válido| C[Autenticar Token]
B -->|Inválido| D[Error 401]
C -->|Válido| E[Validar Request Body]
C -->|Inválido| F[Error 403]
E -->|Válido| G[Procesar Request]
E -->|Inválido| H[Error 400]
G --> I[Transformar Datos]
I --> J[Invocar Servicios Externos]
J --> K{¿Éxito?}
K -->|Sí| L[Transformar Response]
K -->|No| M[Error 500]
L --> N[Log Response]
N --> O[Return Response]
M --> P[Log Error]
P --> Q[Return Error]Diagrama de Flujo por Capa Específica
OBLIGATORIO: Generar diagrama de flujo para cada capa:
Flujo de Presentación:
mermaid
flowchart TD
A1[Request HTTP] --> B1[Validar Content-Type]
B1 --> C1[Extraer Headers]
C1 --> D1[Validar Autenticación]
D1 --> E1[Parse Request Body]
E1 --> F1[Validar Parámetros]
F1 --> G1[Enviar a Orquestación]Flujo de Orquestación:
mermaid
flowchart TD
A2[Recibir Request] --> B2[Validar Lógica de Negocio]
B2 --> C2[Transformar Datos]
C2 --> D2[Invocar Integraciones]
D2 --> E2[Procesar Respuestas]
E2 --> F2[Transformar Response]
F2 --> G2[Enviar a Presentación]Flujo de Integración:
mermaid
flowchart TD
A3[Recibir Datos] --> B3[Seleccionar Conector]
B3 --> C3[Configurar Request]
C3 --> D3[Ejecutar Llamada]
D3 --> E3[Procesar Response]
E3 --> F3[Retornar Datos]7.3 Diagrama de Clases por Capa
Diagrama de Clases Principal
OBLIGATORIO: Generar diagrama de clases basado en el código analizado:
mermaid
classDiagram
class Request {
+String endpoint
+String method
+Map headers
+Object body
+validate()
+parse()
}
class Response {
+int statusCode
+String message
+Object data
+Map headers
+format()
+validate()
}
class Service {
+String name
+String version
+process()
+validate()
}
class Controller {
+handleRequest()
+validateInput()
+processRequest()
+formatResponse()
}
Request --> Controller
Controller --> Service
Service --> ResponseDiagrama de Clases por Capa Específica
OBLIGATORIO: Generar diagrama de clases para cada capa identificada:
Clases de Presentación:
mermaid
classDiagram
class APIController {
+handleGET()
+handlePOST()
+handlePUT()
+handleDELETE()
}
class RequestValidator {
+validateHeaders()
+validateBody()
+validateParams()
}
class ResponseFormatter {
+formatSuccess()
+formatError()
+addHeaders()
}
APIController --> RequestValidator
APIController --> ResponseFormatterClases de Orquestación:
mermaid
classDiagram
class FlowProcessor {
+processFlow()
+handleTransformations()
+manageErrors()
}
class DataTransformer {
+transformRequest()
+transformResponse()
+validateData()
}
class BusinessLogic {
+applyRules()
+validateBusiness()
+processLogic()
}
FlowProcessor --> DataTransformer
FlowProcessor --> BusinessLogic7.4 Diagramas de Secuencia para Casos de Uso
Diagrama de Secuencia Principal
OBLIGATORIO: Generar diagrama de secuencia para el flujo principal:
mermaid
sequenceDiagram
participant C as Cliente
participant G as Gateway
participant A as API
participant O as Orquestación
participant I as Integración
participant D as Base de Datos
participant E as Servicio Externo
C->>G: Request HTTP
G->>A: Validar Headers
A->>A: Autenticar Token
A->>O: Procesar Request
O->>I: Invocar Servicios
I->>D: Consultar Datos
D-->>I: Retornar Datos
I->>E: Llamada Externa
E-->>I: Response Externa
I-->>O: Consolidar Datos
O-->>A: Response Procesado
A-->>G: Formatear Response
G-->>C: Response FinalDiagramas de Secuencia por Caso de Uso
OBLIGATORIO: Generar diagramas de secuencia para casos de uso específicos:
Caso de Uso: GET Request
mermaid
sequenceDiagram
participant C as Cliente
participant A as API
participant V as Validator
participant P as Processor
participant R as Response
C->>A: GET /v1/normalizeAddress
A->>V: Validar Request
V-->>A: Validación OK
A->>P: Procesar GET
P->>P: Ejecutar Lógica
P-->>A: Datos Procesados
A->>R: Formatear Response
R-->>A: Response Formateado
A-->>C: 200 OK + DataCaso de Uso: Error Handling
mermaid
sequenceDiagram
participant C as Cliente
participant A as API
participant V as Validator
participant E as ErrorHandler
participant R as Response
C->>A: Request Inválido
A->>V: Validar Request
V->>E: Error Detectado
E->>E: Procesar Error
E->>R: Formatear Error
R-->>A: Error Formateado
A-->>C: 4xx/5xx + Error Details7.5 Diagramas de Estados
Diagrama de Estados del Servicio
OBLIGATORIO: Generar diagrama de estados basado en el análisis del código:
mermaid
stateDiagram-v2
[*] --> Inicializado
Inicializado --> Configurado
Configurado --> Listo
Listo --> Procesando
Procesando --> Completado
Procesando --> Error
Error --> Listo
Completado --> Listo
Listo --> [*]7.6 Diagramas de Despliegue
Diagrama de Despliegue por Ambiente
OBLIGATORIO: Generar diagrama de despliegue basado en configuraciones:
mermaid
graph TB
subgraph "Ambiente de Desarrollo"
D1[API Dev]
D2[DB Dev]
D3[Cache Dev]
end
subgraph "Ambiente de QA"
Q1[API QA]
Q2[DB QA]
Q3[Cache QA]
end
subgraph "Ambiente de Producción"
P1[API Prod]
P2[DB Prod]
P3[Cache Prod]
P4[Load Balancer]
end
D1 --> D2
D1 --> D3
Q1 --> Q2
Q1 --> Q3
P4 --> P1
P1 --> P2
P1 --> P38. Plan de Retiro (Sunset)
No aplica actualmente. El servicio está en desarrollo activo y no hay planes de retiro programados.
9. Políticas y Dependencias
Políticas de Seguridad
- Autenticación: OAuth2 con tokens Bearer
- Autorización: Basada en roles y permisos
- Encriptación: TLS 1.2+ para comunicaciones
- Rate Limiting: Configurado para prevenir abuso
Políticas de Calidad
- Validación: Validación estricta de parámetros de entrada
- Logging: Logging completo de todas las operaciones
- Auditoría: Auditoría automática de todas las transacciones
- Monitoreo: Monitoreo continuo de métricas y alertas
Dependencias Críticas
- commerce-papi-services: Servicio interno crítico
- etb-common-lib: Librería común esencial
- Anypoint Platform: Plataforma de gestión crítica
10. Logs y Auditoría
Configuración de Logging
- Framework: Log4j2
- Nivel: INFO para operaciones normales, ERROR para errores
- Formato: JSON estructurado
- Retención: 30 días en QA, 90 días en producción
Auditoría
- Servicio: audits-oracle-sapi-services
- Eventos: Todas las transacciones
- Datos: Request, response, timestamps, usuario
- Retención: 1 año en producción
Métricas de Logging
- Request Count: Número total de requests
- Error Rate: Porcentaje de errores
- Response Time: Tiempo de respuesta promedio
- Throughput: Requests por segundo
11. Calidad, Monitoreo y Pruebas
Métricas de Calidad
- Code Coverage: > 80%
- Performance: < 2 segundos response time
- Reliability: 99.9% uptime
- Security: Sin vulnerabilidades críticas
Monitoreo
- Health Checks: Endpoint de salud disponible
- Alertas: Configuradas para métricas críticas
- Dashboards: Disponibles en Anypoint Platform
- Logs: Centralizados y monitoreados
Pruebas
- Unit Tests: Cobertura de código
- Integration Tests: Pruebas de integración
- Performance Tests: Pruebas de rendimiento
- Security Tests: Pruebas de seguridad
12. Ciclo de Vida y Roadmap
Estado Actual
- Versión: 1.0.2
- Estado: En desarrollo activo
- Ambiente: QA disponible
- Documentación: En proceso de actualización
Roadmap Técnico
- Q1 2025: Optimización de rendimiento
- Q2 2025: Nuevas funcionalidades de georreferenciación
- Q3 2025: Mejoras en validación de direcciones
- Q4 2025: Integración con nuevos servicios
13. Restricciones de Diseño
Restricciones Técnicas
- Mule Runtime: Limitado a versión 4.4.0
- Java: Requiere Java 17
- Memoria: Limitaciones de memoria en CloudHub
- Conectividad: Dependiente de servicios internos
Restricciones de Negocio
- Estándares: Debe cumplir TMF673 v4
- Performance: Response time < 2 segundos
- Disponibilidad: 99.9% uptime requerido
- Seguridad: Cumplimiento de políticas de seguridad
14. Control de Versiones de la API
Cambios Detectados en esta Actualización
Fecha: 2025-01-08 Versión Anterior: N/A Cambios Identificados:
- Documentación inicial del servicio
Historial de Versiones de la API
| Versión API | Fecha de Release | Tipo de Cambio | Descripción del Cambio | Autor | Impacto en Clientes |
|---|---|---|---|---|---|
| 1.0.2 | 2025-01-08 | PATCH | Documentación inicial del servicio | ETB Development Team | BAJO |
Tipos de Cambio:
- MAJOR: Cambios incompatibles hacia atrás (nuevas versiones principales)
- MINOR: Nuevas funcionalidades compatibles hacia atrás
- PATCH: Correcciones de bugs compatibles hacia atrás
Impacto en Clientes:
- ALTO: Requiere migración de datos o cambios en clientes
- MEDIO: Cambios en contratos pero compatibles hacia atrás
- BAJO: Mejoras internas sin impacto en clientes
15. Referencias
Documentación Técnica
- TM Forum TMF673: Estándar de gestión de direcciones geográficas
- MuleSoft Documentation: Documentación oficial de MuleSoft
- Anypoint Platform: Documentación de la plataforma
Estándares y Especificaciones
- RAML 1.0: Especificación de API
- JSON Schema: Esquemas de datos
- HTTP/HTTPS: Protocolos de comunicación
- OAuth2: Estándar de autenticación
Herramientas y Plataformas
- Anypoint Studio: IDE de desarrollo
- CloudHub: Plataforma de ejecución
- Anypoint Platform: Plataforma de gestión
- Maven: Gestión de dependencias
16. Estándares TM Forum
16.1 APIs Relacionadas y Compliance
CRÍTICO: Revisar la documentación oficial del TM Forum en https://www.tmforum.org/oda/open-apis/directory para extraer información actualizada y precisa.
| Categoría TM Forum | API Específica | Código TMF | Versión | Estado de Implementación | Compliance |
|---|---|---|---|---|---|
| Geographic Address APIs | Geographic Address Management API | TMF673 | v4 | IMPLEMENTADO | COMPLETO |
| Product APIs | Product Catalog Management API | TMF620 | v4, v5 | NO_APLICA | NO_CUMPLE |
| Product APIs | Product Inventory Management API | TMFxxx | v4, v5 | NO_APLICA | NO_CUMPLE |
| Service APIs | Service Activation Management API | TMFxxx | v4 | NO_APLICA | NO_CUMPLE |
| Customer APIs | Customer Management API | TMFxxx | v4, v5 | NO_APLICA | NO_CUMPLE |
16.2 Análisis de Compliance por Estándar
| Estándar TMF | Descripción | Versión Implementada | Porcentaje Compliance | Observaciones |
|---|---|---|---|---|
| TMF673 | Geographic Address Management | v4 | 95% | Implementación completa con normalización y georreferenciación |
| TMF620 | Product Catalog Management | NO_APLICA | 0% | No aplica para este servicio |
| TMF675 | Geographic Coverage Management | v4 | 80% | Parcialmente implementado en endpoint /geographicCoverage |
16.3 Comandos de Análisis TM Forum
CRÍTICO: Consultar la documentación oficial del TM Forum para información actualizada.
bash
# CRÍTICO: Detectar estándares TM Forum en el código
grep -r "TMF[0-9]*" . 2>/dev/null || echo "No se encontraron códigos TMF"
grep -r "tmforum\|TM Forum" . 2>/dev/null || echo "No se encontraron referencias TM Forum"
# IMPORTANTE: Buscar implementaciones de APIs específicas
grep -r "loyalty\|catalog\|inventory" . 2>/dev/null || echo "No se encontraron APIs de producto"
grep -r "customer\|service\|activation" . 2>/dev/null || echo "No se encontraron APIs de servicio"
# OPCIONAL: Verificar versiones de compliance
grep -r "v4\|v5\|version" . 2>/dev/null || echo "No se encontraron versiones específicas"
# CRÍTICO: Consultar documentación oficial TM Forum
# URL: https://www.tmforum.org/oda/open-apis/directory
# Verificar APIs disponibles y estándares actuales16.4 Referencias TM Forum
CRÍTICO: Incluir referencias a la documentación oficial del TM Forum.
- Documentación Oficial TM Forum: https://www.tmforum.org/oda/open-apis/directory
- Geographic Address APIs Directory: https://www.tmforum.org/oda/open-apis/directory
- Geographic Address Management API: TMF673 - https://www.tmforum.org/oda/open-apis/directory
- Geographic Coverage Management API: TMF675 - https://www.tmforum.org/oda/open-apis/directory