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.