Integración DB cliente único

# Integración DB cliente único  ## Control de Versiones | Versión | Fecha | Autor | Revisor | Descripción del Cambio | |--|--|--|--|--| |1.0|20210415|Luis Arismendi/Francisco.Higuera|Jed Horne|Emisión| ## 1 Introduccion  Este documento trata sobre la integración de la aplicación para La14 y su CRM, la idea es poder trabajar una base de datos de usuarios actualizada tanto para la aplicación como para el sistema interno del cliente. Para esto contamos con el apoyo de endpoints para crear, actualizar y consultar la información de un usuario registrado en el CRM de La14, y la idea es implementar esta comunicación con el objetivo de tener ambos lados actualizados. Las interacciones que existiran para esta funcionalidad es la siguiente: * Usuario: Es la persona que se registrada o no en el CRM e interactua con nuestra aplicación. * Aplicación: Se refiere al E-commerce que se estará desarrollando para La14. * Backend: Es la aplicación que corresponde solo al backend del E-commerce. * Cliente: Es el cliente de este proyecto La14. * CRM: Es el sistema orientado al equipo de ventas donde centralizan la información de los clientes ## 2 Motivación  * Construir un documento que sirva de referencia técnica para el equipo que ejecute esta integración y facilite su comprensión. * Realizar este desarrollo desde el backend del E-commerce en Django. * Que se pueda crear, actualizar y consultar la información de un usuario del CRM de La14 para sincronizar ambos lados cliente-aplicación en los diferentes procesos como registro y login. * Para la migración de los usuarios existentes del lado del cliente, tenemos dos ideas: * Utilizar un API para validar la existencia y a su vez la autenticación del usuario, para luego proceder a guardar esta información en la DB de la aplicación. * Construir un ETL para actualizar la información de usuario en la DB de la aplicación. ## 2.1 Lluvia de Ideas * Necesitamos crear los flujos y las interacciones de nuestra aplicación con el CRM de La14. * La implementación la queremos hacer desde el Backend en Django. * Se requiere realizar una autenticación entre el Backend y el API del CRM de La14, además de realizar la comunicación de manera segura. * Se puede analizar procesos en base a eventos para mejorar el performance de la aplicación. ## 3 Propuesta de implementación  La propuesta consiste en implementar procesos de comunicación con el CRM de La14 para el registro, autenticación y actualización de usuario. ### 3.1 Lo siguiente es el flujo de registro de nuevo usuario: |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Quiere registrarse en el E-commerce |**2.** Envía email, password, nombre, apellido, dirección, entre otros |||**3.** Se valida y ajusta la geolocalización con **DANE** |||**4.** Valida si el usuario esta registrado |||**5.** El usuario no existe |||**6.** Se autentica con el CRM para realizar consultas [POST] https://url-crm/login ||||**7.** Autenticación exitosa con el API del CRM, retorna el token de autenticación basic |||**8.** Se valida si el usuario existe en el CRM [GET] https://url-crm/consultar-usuario ||||**9.** Se responde que el usuario no existe |||**10.** Ya que el usuario no existe se crea en CRM [POST] https://url-crm/crear-usuario |||**11.** Se crea el usuario en CRM ||||**12.** Se responde que el usuario fue creado exitosamente |||**13.** Luego de creado en CRM se crea en Backend La14 |||**14.** Se envía un email de confirmación del usuario |||**15.** Se responde con éxisto la petición ||**16.** Se redirije a la confirmación del correo del usuario |**17.** Se ingresa el código de validación enviado al correo ||**18.** Se confirma y se reenvia al Dashboard del usuario |**19.** El usuario tiene acceso a su Dashboard **Consideraciones:** * **3.** DONA es el Departamento Administrativo Nacional de Estadística que establece códigos para geolocalización, ciudades, departamentos, entre otros. * **5.** En este paso se confirma que el usuario no existe en la DB del backend. * **7.** Luego de esta autenticación, podemos realizar consultas al API del CRM. * **14.** Este punto es propuesto por seguridad, de esta forma podremos validar que el usuario tiene acceso al correo suministrado. * **17.** Este proceso usa el método de verificación por código de validación, se puede evaluar casos bordes como por ejemplo, si el usuario no ingresa dicho código. ### 3.2 Flujo de Registro de usuario existente en CRM pero no en el E-commerce: |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Quiere registrarse en La14 ||**2.** Envía email, password, nombre, apellido, dirección, entre otros. |||**3.** Se valida y ajusta la geolocalizacion con **DANE** |||**4.** Valida si el usuario esta registrado |||**5.** El usuario no existe |||**6.** Se autentica con el CRM para realizar consultas [POST] https://url-crm/login ||||**7.** Autenticación exitosa con el API del CRM, retorna el token de autenticación basic |||**8.** Se valida si el usuario existe en el CRM [GET] https://url-crm/consultar-usuario ||||**9.** Se responde que el usuario si existe. |||**10.** Se crea el usuario en Backend ||||**11.** Se actualiza la informacion del CRM? |||**12.** Se envía un email de confirmación del usuario |||**13.** Se responde con éxisto la petición. ||**14.** Se redirije a la confirmación del correo del usuario |**15.** Se ingresa el codigo de validacion enviado al correo ||**16.** Se confirma y se reenvia al Dashboard del usuario |**17.** El usuario tiene acceso a su Dashboard Consideraciones: * **3.** DONA es el Departamento Administrativo Nacional de Estadística que establece códigos para geolocalización, ciudades, departamentos, entre otros. * **9.** En este paso cambia un poco los siguientes pasos en comparación con el flujo anterior porque no se requiere crear el usuario en el CRM. * **11.** Existe la duda que hay que validar con el cliente si se debe actualizar la información del usuario en el CRM o como no se ha verificado el correo, este paso no se debe realizar en este u otros puntos. ### 3.3 Flujo registro de usuario con CRM sin servicio |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Quiere registrarse en La14 ||**2.** Envía email, password, nombre, apellido, dirección, entre otros. |||**3.** Se valida y ajusta la geolocalización con **DANE** |||**4.** Valida si el usuario esta registrado |||**5.** El usuario no existe |||**6.** Se autentica con el CRM para realizar consultas [POST] https://url-crm/login ||||**7.** Servicio no encontrado |||**8.** Se valida la respuesta y al recibirse un error |||**9.** Se retorna un error al cliente ||**10.** Se muestra error de autenticación, intente más tarde |**11.** El usuario no tiene acceso al Dashboard **Consideraciones:** * **3.** DONA es el Departamento Administrativo Nacional de Estadística que establece códigos para geolocalización, ciudades, departamentos, entre otros. * **7.** El servicio del CRM esta caido. ### 3.4 Flujo autenticación exitosa |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Quiere autenticarse en La14 ||**2.** Envio email y password con formatos validados al Backend |||**3.** Valida si el usuario esta registrado |||**4.** El usuario existe y la autenticación es exitosa |||**5.** Se crea la sesion del usuario |||**6.** Se responde con existo la petición ||**7.** Se crea la sesion del usuario ||**8.** Se redirije al Dashboard del usuario |**9.** El usuario tiene acceso a su Dashboard ### 3.5 Flujo autenticación fallida |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Quiere autenticarse en La14 ||**2.** Envio email y password con formatos validados al Backend |||**3.** Valida si el usuario esta registrado |||**4.** El usuario no existe y la autenticación es fallida |||**5.** Se responde la petición con usuario o contraseña invalida ||**6.** Se muestra el mensaje de error de usuario o contraseña invalida |**7.** El usuario no se pudo autenticar en La14 ### 3.6 Flujo Editar usuario |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Yo como usuario quiero editar mi usuario en La14 ||**2.** Envio nombre, apellido, sexo, estado civil, entre otros |||**3.** Se valida si el usuario esta autenticado |||**4.** Se valida y ajusta la geolocalizacion con **DANE** |||**5.** Valida si el usuario esta registrado |||**6.** El usuario no existe |||**7.** Se autentica con el CRM para realizar consultas [POST] https://url-crm/login ||||**8.** Autenticación exitosa, retorna las token de autenticación |||**9.** Se valida si el usuario existe en el CRM [GET] https://url-crm/consultar-usuario ||||**10.** Se responde que el usuario no existe |||**11.** Ya que el usuario no existe se crea en CRM [POST] https://url-crm/crear-usuario ||||**12.** Se crea el usuario en CRM ||||**13.** Se responde que el usuario fue creado exitosamente |||**14.** Luego de creado en CRM se crea en Backend La14 |||**15.** Se envía un email de confirmación del usuario |||**16.** Se responde con éxisto la petición ||**17.** Se redirije a la confirmación del correo del usuario |**18.** Se ingresa el código de validación enviado al correo ||**19.** Se confirma y se reenvia al Dashboard del usuario |**20.** El usuario tiene acceso a su Dashboard ### 3.7 Flujo peticion al Backend de un usuario no autenticado |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Yo como usuario quiero editar mi usuario en La14 ||**2.** Envio nombre, apellido, sexo, estado civil, entre otros. |||**3.** Se valida si el usuario esta autenticado |||**4.** Usuario no autenticado ||**5.** Se redirije a Login |**6.** Se puede ver la pagina de Login ### 3.8 Flujo editar usuario con servicio CRM no encontrado |Users|Web/App E-commerce|Backend E-commerce|CRM La14| |---|---|---|---| |**1.** Quiere editar su usuario en La14 ||**2.** Envía nombre, apellido, sexo, estado civil, entre otros |||**3.** Se valida si el usuario esta autenticado |||**4.** Se valida y ajusta la geolocalización con **DANE** |||**5.** Valida si el usuario esta registrado |||**6.** El usuario no existe |||**7.** Se autentica con el CRM para realizar consultas [POST] https://url-crm/login ||||**8.** Servicio no encontrado |||**9.** Se valida la respuesta y al recibirse un error |||**10.** Se retorna un error al cliente ||**11.** Se muestra error de editar usuario, intente más tarde |**12.** El usuario no puede editar su información **Consideraciones:** * **4.** DONA es el Departamento Administrativo Nacional de Estadística que establece códigos para geolocalización, ciudades, departamentos, entre otros. * **8.** El servicio del CRM esta caido. ## 4 Métricas * Tiempo de procesamiento. * Cantidad de transacciones. * Tiempo de envío al CRM. * Tiempo de respuesta del CRM. ## 5 Riesgos e inconvenientes * Uno de los inconvenientes comunes en el uso de utilizar apirest es que el backend no mantiene el estado del usuario, por lo que en cada petición se debe anexar un token o varios, según los niveles de seguridad que se requieran. * Como toda implementación se debe tomar en consideración la curva de aprendizaje que exige comprender los parámetros de entrada y salida con respecto a la apirest que se necesita consumir, lo que implica tiempo de desarrollo. ## 6 Alternativas * Entre otras alternativas se tiene implementar una arquitectura de microservicios así como esta planteada en el documento [Arquitectura Backend Plataforma de Pago](https://hackmd.io/HAvw3iSJSxuMa-x-46PqSA). ## 7 Impacto potencial y dependencias * Registro de clientes en el sistema. * Con la conexión con un servicio externo al backend del ecommerce la seguridad puede ser afectada, por lo que se deben tomar las consideraciones respecto al este tema. ## 8 Preguntas sin resolver * Se podría realizar los ajustes configurables de manera que un mismo servicio del sistema, pueda consumir apirest con otros endpoints y con otras estructuras de datos. * De momento, desconocemos que CRM utiliza el cliente, y los protocolos de seguridad de su API. * Se espera la confirmación del proceso de migración de usuarios o de confirmación de autenticación. * Disponibilidad y límites del servicio. ## 9 Ideas futuras * Implementar un módulo CRM que permita mayor control y seguimiento de los clientes y clientes potenciales, así como incluir estrategias de marketing digital para ganar mayor cantidad de clientes. Dicho módulo evitaría la interacción con sistemas de terceros para realizar éstas funciones, reduciría los riesgos de seguridad en las comunicaciones y se garantizaría mayor consistencia de la información. ## 10 Conclusión * La implementación de una interacción efectiva entre el sistema y el CRM, permitirá tener la información de los clientes actualizada en ambos sistemas, asimismo garantizar la consistencia de los datos. * En este mismo orden, cada sistema realizará su objetivo con datos sincronizados y de manera independiente, así el sistema realizará de manera óptima el proceso de venta online e igualmente por su parte el CRM su control y seguimiento de clientes. * También se conseguira realizar autenticación, registro y actualización de los usuarios de manera asociada entre el E-commerce y el CRM. ## 11 Estimaciones - Listado de tareas para implementar esta propuesta: | Tarea | Puntos | Equipo | | --- | --- | --- | | Adecuar modelo de clientes según requerimientos | 5 | Backend | Generar migraciones | 3 | Backend | Integración con CRM | 5 | Backend | Adecuar registro de usuario | 5 | Backend | Adecuar edición de usuario | 5 | Backend | Adecuar autenticación de usuario | 5 | Backend * Tiempo total: * 3 semanas