Tema del Casos de uso

ESPECIFICACIÓN DE CASO DE USO: CU-C0001-Obtener Datos del producto

1. Descripción

Este caso de uso tiene como objetivo obtener la información de la cuenta del cliente, el producto, incluyendo el titular de la cuenta.

2. Actor(es)

CtaDepTrnInqV1 (Proxy), TIPO : Servicio Virtualizado

3. Flujo de Eventos

3.1. Flujo Básico

1. El caso de uso inicia cuando recibe la petición del actor “PxCtaDepTrnInqV1”
2. El servicio BsCtaDepTrnInq envía los parámetros de entrada al servicio virtualizado CtaDepTrnInqV4 (MBSIMO-30)
3. El servicio virtualizado CtaDepTrnInqV4, se comunica con el servicio BackEnd “SISTEMATIC” devuelve una trama de salida, para obtener con toda la información de la cuenta del producto y el cliente. Finalmente, devuelve una trama de salida con dicha información  al servicio BsCtaDepTrnInq.
4. El servicio BsCtaDepTrnInq toma los datos que necesita y los devuelve al proxy..

. CONSIDERACIONES

En el punto 2,  al obtener datos de una cuenta diferente a la que invoca (Usuario Destino): El parámetro de categoría de producto se infiere, por su longitud, a través del número de cuenta destino ingresado. Entre los tipos de cuenta: Cta. corriente y Cta. de Ahorros.

3.2. Subflujos

3.3. Flujos Alternativos

•  El Operador de ventas registrara clientes nuevos
• El Operador de ventas realizara consultas de clientes, productos y  pedidos.

4. Precondiciones

• El usuario debe estar autenticado.
• Los parámetros de la aplicación deben de haberse cargado correctamente.

5. Poscondiciones

• El sistema mostrara un mensaje indicando que el pedido ha sido guardado exitosamente

6. Puntos de Extensión

7. Requisitos Especiales

1. Error de validaciones

1. Este escenario ocurre cuando ocurre un error en las validaciones que se realizan previo a la llamada del servicio.

2.El sistema estará preparado para recibir dos tipos de errores:

1. Error Tratado:

Son los errores que se crean cuando no cumplen alguna validación.

Para este tipo de error, se crean excepciones específicas para devolver como respuesta al canal que hizo la petición. En este caso, se devolvería la excepción con un código de error y un mensaje tipificado.

1. Error No Tratado:

Son los errores que se crean debido a algún error inesperado en alguna de las validaciones.

En este caso se devolverá en la excepción un código y un mensaje de error genérico, como respuesta al canal que hizo la petición, y se dejará constancia de este error mediante el envío traza al Log.

1. Error en el servicio

1. Este escenario ocurre cuando ocurre un error en el servicio  o este recibe un error del Servicio Virtualizado que debe manejar y devolver al canal que realizó la petición.

2. El sistema estará preparado para recibir dos tipos de errores:

• Error Tratado:

Son los errores que se crean debido a algún comportamiento que va en contra del funcionamiento del servicio. Para este tipo de error, se crean excepciones específicas para devolver como respuesta al canal que hizo la petición.

En este caso, se devolvería la excepción con un código de error y un mensaje tipificado.

• Error No Tratado:

Son los errores generados por un comportamiento anómalo del servicio.

Para estos errores se han creado excepciones con un Código y Mensaje de error genérico que se devolverán al canal. Estos errores también capturarán errores que puedan generarse a la hora de llamar al Servicio BackEnd de “Obtener Usuario” (SISTEMATIC) y que no puedan ser interpretados por el servicio.

ESPECIFICACIÓN DE CASO DE USO: CU-I0002-Obtener Tipo de Cambio

1. Descripción

Este caso de uso tiene como objetivo obtener el tipo de cambio.

2. Actor(es)

CambioMonInqV1 (Proxy), TIPO : Servicio Virtualizado

3. Flujo de Eventos

3.1. Flujo Básico

1. El caso de uso inicia cuando recibe la petición del actor “CambioMonInqV1”
2. El servicio envía los parámetros de entrada al servicio virtualizado CambioMonInqV1 (XR71)
3. El servicio virtualizado devuelve una trama de salida, con toda la información del tipo de cambio.
4. El servicio toma los datos que necesita y los devuelve al proxy.

3.2. Subflujos

3.3. Flujos Alternativos

•  El Operador de ventas registrara clientes nuevos
• El Operador de ventas realizara consultas de clientes, productos y  pedidos.

4. Precondiciones

• El usuario debe estar autenticado.
• Los parámetros de la aplicación deben de haberse cargado correctamente.

5. Poscondiciones

• El sistema mostrara un mensaje indicando que el pedido ha sido guardado exitosamente

6. Puntos de Extensión

7. Requisitos Especiales

Tiempo de Expiración

En el punto 3, tener en consideración que el valor devuelto (Tipo de cambio) por el BackEnd, tiene un tiempo de expiración  de aprox. 15 minutos para realizar una operación. En caso, se pase el tiempo indicado se rechazara la operación.

Error de validaciones

1. Este escenario ocurre cuando ocurre un error en las validaciones que se realizan previo a la llamada del servicio.

2. El sistema estará preparado para recibir dos tipos de errores:

• Error Tratado:

Son los errores que se crean cuando no cumplen alguna validación.

Para este tipo de error, se crean excepciones específicas para devolver como respuesta al canal que hizo la petición. En este caso, se devolvería la excepción con un código de error y un mensaje tipificado.

• Error No Tratado:

Son los errores que se crean debido a algún error inesperado en alguna de las validaciones.

En este caso se devolverá en la excepción un código y un mensaje de error genérico, como respuesta al canal que hizo la petición, y se dejará constancia de este error mediante el envío traza al Log.

Error en el servicio

1. Este escenario ocurre cuando ocurre un error en el servicio  o este recibe un error del Servicio Virtualizado que debe manejar y devolver al canal que realizó la petición.

2.El sistema estará preparado para recibir dos tipos de errores:

• Error Tratado:

Son los errores que se crean debido a algún comportamiento que va en contra del funcionamiento del servicio. Para este tipo de error, se crean excepciones específicas para devolver como respuesta al canal que hizo la petición.

En este caso, se devolvería la excepción con un código de error y un mensaje tipificado.

• Error No Tratado:

Son los errores generados por un comportamiento anómalo del servicio.

Para estos errores se han creado excepciones con un Código y Mensaje de error genérico que se devolverán al canal. Estos errores también capturarán errores que puedan generarse a la hora de llamar al Servicio BackEnd de “Tipo de cambio” (ACM) y que no puedan ser interpretados por el servicio.

ESPECIFICACIÓN DE CASO DE USO: CU-I0003-Realizar Transferencia

1. Descripción

Este caso de uso tiene como objetivo realizar una transferencia de dinero.

2. Actor(es)

CtaCltTrsf (Proxy -> Transferencia a cuentas propias - Cliente)

CtaTercTrsf (Proxy -> Transferencia a otras cuentas - Terceros)

TIPO : Servicio Virtualizado

3. Flujo de Eventos

3.1. Flujo Básico

1. El caso de uso inicia cuando recibe la petición del actor.
2. Se valida que la operación sea favorito. En caso de que no cuente con el código de favorito se continúa con el siguiente punto, en caso contrario elEl servicio BsCtaTrsf consume el servicio BsVldFav para validar que la operación sea favorita.
3. El servicio BsCtaTrsf CtaTrsf consume el Servicio BsAutnVld para la validación del Token o Pin enviado por el canal.
4. El servicio BsCtaTrsf CtaTrsf consume la funcionalidad FlgRSAVld para validar si la operación realizó el control de riesgo. En caso de no hacerla no se realiza la transferencia y te muestra un mensaje de estado.
5. El servicio BsCtaTrsf CtaTrsf consume la funcionalidad AdicDataInq con la finalidad de obtener toda la data requerida por el servicio virtualizado ProdTrsfV32 y que no ha sido enviada por el canal. Esta información se obtendrá desde la base de datos y se consultará por el canal y la operación. El resultado será un registro en JSON con los siguientes campos:

-        Código de Familia BSC de Cargo

-        Código del Tipo de Cargo

-        Glosa 1 de Cargo

-        Código de Aplicativo Glosas de Cargo

-        Cuentas de Depósito de Cargo - Código Transaccion BCP

-        Código de Familia BSC de Abono

-        Código del tipo de Abono

-        Glosa 1 de Abono

-        Código de Aplicativo Glosas de Abono

-       Cuentas de Depósito de Abono - Código de Transaccion BCP.

1. Se procede a realizar la transferencia correspondiente entre las cuentas mediante la llamada al servicio virtualizado ProdTrsfV32.
2. Si la trasferencia se realizó correctamente, el servicio envía los datos de la transferencia al BsNotifyRSA para que se alimente su Base de Conocimientos.

3.2. Subflujos

3.3. Flujos Alternativos

• El Operador de ventas registrara clientes nuevos
• El Operador de ventas realizara consultas de clientes, productos y  pedidos.

4. Precondiciones

• El usuario debe estar autenticado.
• Los parámetros de la aplicación deben de haberse cargado correctamente.

5. Poscondiciones

• El sistema mostrara un mensaje indicando que el pedido ha sido guardado exitosamente

6. Puntos de Extensión

7. Requisitos Especiales

Error en el PIN introducido

1. Este escenario ocurre cuando el pin introducido en el formulario no es el correcto. (En el punto 32)

2. El servicio recibe un mensaje indicando el resultado fallido.

Error de validaciones

Este escenario ocurre cuando ocurre un error en las validaciones que se realizan previo a la llamada del servicio.

El sistema estará preparado para recibir dos tipos de errores:

• Error Tratado:

Son los errores que se crean cuando no cumplen alguna validación.

Para este tipo de error, se crean excepciones específicas para devolver como respuesta al canal que hizo la petición. En este caso, se devolvería la excepción con un código de error y un mensaje tipificado.

• Error No Tratado:

Son los errores que se crean debido a algún error inesperado en alguna de las validaciones.

En este caso se devolverá en la excepción un código y un mensaje de error genérico, como respuesta al canal que hizo la petición, y se dejará constancia de este error mediante el envío traza al Log.

Error en el servicio

.Este escenario ocurre cuando ocurre un error en el servicio o este recibe un error del Servicio Virtualizado que debe manejar y devolver al canal que realizó la petición.

El sistema estará preparado para recibir dos tipos de errores:

• Error Tratado:

Son los errores que se crean debido a algún comportamiento que va en contra del funcionamiento del servicio. Para este tipo de error, se crean excepciones específicas para devolver como respuesta al canal que hizo la petición.

En este caso, se devolvería la excepción con un código de error y un mensaje tipificado.

• Error No Tratado:

Son los errores generados por un comportamiento anómalo del servicio.

Para estos errores se han creado excepciones con un Código y Mensaje de error genérico que se devolverán al canal. Estos errores también capturarán errores que puedan generarse a la hora de llamar al Servicio BackEnd de “Realizar Transferencia” y que no puedan ser interpretados por el servicio.