Introducción
Este tutorial utiliza el dominio de pagos para presentar el lenguaje específico de dominio de flujos (DSL) que ofrece IPF Studio. Conocerás la mayoría de los conceptos del DSL y usarás Flow Designer (también conocido como MPS) para crear y actualizar un flujo. Para sacarle el máximo partido al tutorial, deberías acceder a ipf-ba-tutorial-app mediante MPS; una vez tengas acceso a MPS, empieza por el paso 1. En MPS se te proporcionan ejemplos de cómo debería verse el modelo al final de cada paso.
| Paso | Descripción | Caso de uso | Comentarios | Diagrama de flujo | Conceptos del diseñador introducidos en este paso |
|---|---|---|---|---|---|
1 |
Un flujo de pago sencillo que implica una instrucción de pago de un Deudor que se completa inmediatamente |
Tras recibir la instrucción, el primer estado es un estado Completado, creando un flujo de negocio muy simple |
|
COMPORTAMIENTO DE INICIACIÓN ESTADO FLUJO |
|
2 |
La instrucción refleja los datos que cabría esperar ver en un flujo de pago |
Añadir un Pacs008 a la biblioteca de datos de negocio |
|
BIBLIOTECA DE DATOS DE NEGOCIO |
|
3 |
El Agente del Deudor es notificado cuando se ha procesado un pago |
|
DOMINIO EXTERNO NOTIFICACIÓN ACCIÓN |
||
4 |
El Agente del Deudor es notificado cuando un pago ha sido procesado con un Pacs002 |
Como arriba |
FUNCIÓN DE MAPEО FUNCIÓN DE AGREGADO |
||
5 |
La cuenta del Deudor en la instrucción se valida llamando a un sistema del Agente del Deudor |
El sistema del Deudor proporcionará una respuesta Accepted o Rejected, lo que hará que la instrucción sea rechazada y el flujo termine, o que el flujo continúe. |
|
PETICIÓN/RESPUESTA COMPORTAMIENTO DE ENTRADA DEFINICIÓN DE EVENTO COMPORTAMIENTO DE EVENTO VALIDACIÓN DEL MODELO VISTA DE GRÁFICO INTENCIONES |
|
6 |
La Solicitud de Transferencia de Crédito del Cliente se desagrega y los elementos de datos se incluyen en la Petición de Validación de Cuenta del Deudor. La Respuesta de Validación de Cuenta del Deudor incluye datos nuevos |
|
IMPORTACIÓN |
||
7 |
El pago se envía a un esquema que proporciona un acuse de recibo (o fallo técnico) y posteriormente el resultado de la validación de la instrucción. Cuando una instrucción es rechazada por el CSM, también proporcionará un motivo del fallo. |
Las respuestas serán Accept o Reject. Los posibles motivos de una instrucción rechazada se proporcionarán como un código ISO. |
|
BIBLIOTECA DE CÓDIGOS DE RAZÓN RESPUESTA NO COMPLETANTE COMPORTAMIENTO ANTE CUALQUIER EVENTO |
|
8 |
Si el Banco del Acreedor y el Banco del Deudor son el mismo, entonces un pago no debe ir al esquema, sino contabilizarse directamente |
Habrá que añadir un estado de contabilización. Actualiza el flujo existente para añadir la contabilización. Se añadirán datos de negocio del Agente del Deudor y del Agente del Acreedor. |
|
DECISIONES |
|
9 |
Gestionar el escenario en el que, al validar una cuenta deudora, podrían proporcionarse varias respuestas en lugar de un simple verdadero o falso |
Posibles respuestas: Account Valid, Account Accepted, Account Invalid, Account Blocked. Las dos primeras son un 'aprobado' y las dos segundas un 'fallo' |
|
BIBLIOTECA DE CÓDIGOS DE RESPUESTA |
|
10 |
Los pagos se revisan por sanciones mediante un subflujo reutilizable. |
Se creará un subflujo y se añadirá al comportamiento de evento en dos lugares |
|
SUBFLUJO |
|
11 |
El pago se enriquece con datos sobre el Agente del Deudor que se guardan en la aplicación |
Se creará una función de dominio y se añadirá al comportamiento de evento. Se actualizarán los datos de negocio para que el Agente del Deudor enriquecido se utilice en la notificación |
|
FUNCIÓN DE DOMINIO ENRIQUECIMIENTO DE ENTRADA |