# Alternativas al bloqueo de desarrollo - AIC Entry

La situación Actual con FID y su forma de insertar elementos en CRM no está clara, y debe definirse algún camino alternativo para continuar el desarrollo.

Se planteó la solución de definir un contrato SOAP que sea igual a las definiciones de XML de cada formulario pero FID no puede indicar namespaces de modelos en una SOAP request, deben enviar dentro del elemento ***fidData*** la salida XML del formulario sin modificaciones

Ante esta problemática se plantean las siguientes alternativas.

1. **RENTRY (Versión REST de Entry)**
- **Ventajas**:
- Desarrollo de una nueva versión de Entry denominada REST-ENTRY (RENTRY) que permita la carga facilitada por arquitectura de servcios RESTFull, esto mejora los procesos de comunicación del resto de servicios, como CEDI, AIC, y futuros clientes del servidor.
- Soluciona problemas de comunicación existente
- Mejora el mantenimiento
- Aumenta la velocidad de futuros desarrollos de REntry
- **Desventajas**:
- Implica desarrollo (Grande)
- No sabemos si FID contempla la posibilidad de trabajar con contratos REST(XML)
- No respeta Interoperabilidad

2. **Contrato de Servidor de Facto**
Definir un modelo que respete el estándar SOAP y permita generar una descripción del servicio que incluya todos los modelos en sus respectivos namespaces.
- **Ventajas**:
- No requiere un desarrollo adicional
- Respeta estandares de comunicación
- **Desventajas**:
- Desarrollo recae en la responsabilidad de FID de adaptarse a lo que por estandar es un contrato tipo SOAP (Uso de los namespaces), además de cumplir con el contrato de _interoperabilidad_.

3. **XML Escapado en el body de XMLRequest via (SOAP)**
Solución planteada originalmente por FID, se escapa el XML de salida y se lo envía como texto dentro del elemento **fidData** para ser posteriormente interpretado por Entry.
- **Ventajas**:
- Acuerdo rápido con FID
- **Desventajas**:
- No respeta ningún estándar
- Genera acoplamiento máximo al modelo de FID
- No permite generar una descripción del servicio acorde al modelo que se envía
- Quien consuma el servicio en el futuro vería como una caja negra al elemento `fidData` sin saber exactamente qué es lo que se deba enviar
- Quien consuma el servicio debe escapar un XML
- Del lado del servidor se deben reemplazar los escape characters de XML y posteriormente parsearlo a un modelo segun esté indicado en dos campos del mismo (app y form), esto es un punto mucho más propenso a fallas

4. **Aplanar la jerarquía de clases**
Poner todos los modelos bajo un mismo namespace para eliminar la necesidad de que FID tenga que indicarlos en la SOAP request así posibilitando el envío de la salida XML del formulario sin modificaciones.
- **Ventajas**:
- FID podría mandar el XML tal cual sale de su interfaz y nosotros recibiríamos un objeto SOAP
- Se puede generar una descripción del servicio web que incluya todos los modelos
- **Desventajas**:
- La agrupación lógica y física de los modelos no coinciden, generando incongruencias a nivel de proyecto
- Posibles conflictos de nombres iguales en un mismo namespace (vease 'anexos')
- Descripción del servicio web con conflictos de namespace
- No respeta estandares de agrupamiento de paquetes
- Implica una refactorización de la arquitectura del servicio, la cual afecta a otros clientes

5. **Procesamiento en Batch (No en linea) (Storage and Retrieve)**
FID deberia guardar en una base de datos, los elementos de los tramites de entrada (desconocemos si esto existe actualmente), posteriormente, deberia informarle a AIC que ya se encuentra disponible un nuevo tramite mediante un conjunto de datos basicos (primaryKey), para que este recupere y parsee los datos, para posteriormente insertarlos en CRM.
- **Ventajas**:
- Fin del problema de estandarización
- Solución flexible para futuros desarrollos
- Disminuye el desarrollo y la definición de contratos al maximo
- Permite reintentos (Soluciona el problema de la "inconsistencia de entradas a CRM")
- **Desventajas**:
- Implica que exista un servicio de almacenamiento de los datos de los tramites de entrada persistente en el tiempo.
- Implica un desarrollo de recuperación de la base de datos en AIC
- Implica un único acuerdo en el consumo
- Implica nuevas conexiones (pedidos de reglas)
- Implica parseo de elementos por string.