BAJADA TECNICA PARA DESARROLLO
ESCENARIO:
COMO potencial usuario mobile
QUIERO crear una cuenta
PARA interactuar con la app.
SINTESIS
Con este objetivo la app mobile pedir� una serie de datos al usuario de forma
interactiva, crear� otros internamente, y luego los enviar� al microservicio de BFF
(Backend For Frontend) para que por intermedio de este se cree la cuenta.
CONSIDERACIONES GENERALES
Durante la etapa de desarrollo y considerando que se debe poder verificar
paulatinamente el avance, se insertar�n puntos de log espec�ficos antes y despues
de cada llamada a los distintos endpoints, y en general en cada punto funci�n para
poder ser seguidos tambi�n por el equipo de QC.
PRECONDICIONES
Los datos a ser enviados desde la app mobile (esperados por el BFF) son los
siguientes:
fingerprint : cadena de caracteres correspondiente a la identificaci�n
un�voca del dispositivo. (En el caso del registro, ser� enviado para asociarlo al
id de la cuenta y en el login para comparaci�n).
username : cadena de caracteres correspondientes al mail del usuario.
password : cadena de caracteres correspondientes a la contrase�a del
usuario.
document_number : cadena de caracteres correspondientes al n�mero de documento
de identidad del usuario (MVP se asume DNI).
phone_area_code : cadena de caracteres correspondientes al c�digo de area
telef�nica del usuario.
phone_number : cadena de caracteres correspondientes al n�mero de tel�fono
del usuario.
IMPLEMENTACION EN BFF (SE ASUME CREADO EL BOILERPLATE QUE VA A CONTENER EL BFF
- ??).
1. API REST A UTILIZAR
En el microservicio mencionado, existir� una API Web de tipo REST, llamada
ms_bff, que ser� la encargada de interactuar entre mobile y backend, con la
finalidad de aliviar los request que haga el primero y realizando las llamadas
necesarias al segundo, y haciendo las transformaciones necesarias para su correcta
devoluci�n a mobile (response).
2. CREACION DE CONTROLLER
Para ello, si no existe, se crear� un Controller en ms_bff con el nombre
accountController, y en caso de existir, se utilizar� este (Trabajar en este punto
colaborativamente con el equipo de Login Argentina/Mexico).
3. CREACION DE METODO PARA RECIBIR LLAMADAS DE TIPO HTTP POST.
a. En el accountController se crear� un m�todo de tipo POST (cuyo nombre ser�
manualRegister).
b. Este m�todo debe ser decorado con un annotation con el siguiente string :
"/register", que es por donde se entrar� desde mobile al BFF.
3.1 PARAMETROS DEL METODO
a. Header: Este m�todo recibir� en su header una cadena de caracteres llamada
"fingerprint", la cual corresponde con el primer dato enviado por la app mobile y
detallado anteriormente.
b. Body: Este m�todo recibir� en su body un JSON con la siguiente estructura (los
datos del lado derecho son solo a modo de ejemplo). :
{
"username" : "username",
"password" : "password"
"document_number": "123 456789",
"phone_area_code": "55",
"phone_number" : "5556789"
}
Es de destacar que ninguno de los datos del JSON pueden ser nulos o vac�os,
siendo raz�n suficiente de rechazo cuando se compruebe dicha situaci�n.
En caso de haberse detectado lo previo, se debe cortar de inmediato el flujo y
devolver un HTTP Status Code 400 (Bad Request) con la siguiente estructura:
{
"error":"400 - Bad Request",
"mensaje":"Los par�metros de entrada no pueden ser nulos ni vac�os."
}
4. ACCIONES A REALIZAR
4.1. LOGUEARSE COMO APLICACION
a. Se debe loguear como aplicacion, para ello se debe realizar una llamada
al endpoint que nos devolvera el token, que es el siguiente:
[Link]
A dicho endpoint se le debe pasar el siguiente parametro en su header:
Content-Type: application/json
Authorization: Basic UHVjaGVBUFAxOlB1Y2hlQVBQMXNlY3JldA== (A SER
REEMPLAZADO POR EL APPLICATION KEY QUE NOS DEBE SUMINISTRAR REDBEE).
A dicho endpoint se le deben pasar los siguientes par�metros en el body:
{
"grant_type" : "client_credentials",
"scope": "read",
"client_secret": "PucheAPP1secret", (A DEFINIR CON REDBEE - URGENTE)
"client_id": "PucheAPP1" (A DEFINIR CON REDBEE - URGENTE)
}
b. Obtencion de token de aplicaci�n.
Con la llamada del punto a, se obtendr� un response similar al siguiente:
{
"access_token": "772b2a27-b5d9-4be1-8844-e1418c2a6cf1",
"token_type": "bearer",
"expires_in": 43199,
"scope": "read"
}
El contenido del access_token devuelto en el JSON debe guardarse en una
variable con la finalidad de ser reutilizado.
4.2 REGISTRO DE CUENTA
Se debe intentar registrar la cuenta llamando al endpoint de backend de
creaci�n de cuentas mediante un POST, pas�ndole el header m�s los par�metros
recibidos en el body:
Header:
Content-Type: application/json
Authorization: bearer 772b2a27-b5d9-4be1-8844-e1418c2a6cf1 (token
devuelto por el logueo como aplicaci�n).
El endpoint del microservicios de cuentas para la creaci�n es el siguiente:
[Link]
accounts (NO FUNCIONA, REDBEE LO DEBE DESARROLLAR EN ESTA ETAPA - FALTA USER STORY
Y ESTIMACIONES)
El body debe ser el siguiente:
"channel": canal_todopago_nuevo (A DEFINIR CON CATALINA/FERNANDO/? -
URGENTE),
"fingerprint": fingerprint,
"identification_number": document_number,
"phones":
{
"area_code": phone_area_code,
"number": phone_number
},
"profiles":
{
"mail": username,
"password": password
},
"type": "CTA_PARTICULAR"
}
Response:
Como respuesta del registro de la cuenta en caso exitoso se obtendr� un json
con la siguiente estructura:
{
"accounts":[
{
"id": 10814,
}]
}
CON ESTE DATO, SABEMOS QUE SE HA CREADO LA CUENTA CON EL ID 10814, DATO QUE
GUARDAREMOS EN UNA VARIABLE.
4.3 INICIO DE SESION
Se debe hacer una llamada reutilizando componentes de BFF al m�todo
accountLogin del mismo controller, pasando los siguientes datos:
Header : el fingerprint del dispositivo
Body:
{
"mail": username,
"password": password
}
Como resultado de esto, se debe obtener un JSON con la estructura que
devuelve el m�todo accountLogin de este mismo controller.