Introducción
Este tutorial utiliza el dominio de pagos para introducir el flujo del Lenguaje Específico de Dominio (DSL) proporcionado con IPF Studio. Se le presentarán la mayoría de los conceptos en el DSL y utilizará Flow Designer (también conocido como MPS) para crear y actualizar un flujo. Para aprovechar al máximo el tutorial, debe acceder a la ipf-ba-tutorial-app utilizando MPS - una vez que tenga acceso a MPS debe comenzar en el paso 1. Se le proporcionan ejemplos de cómo debería verse el modelo al final de cada paso en MPS.
| Paso | Descripción | Caso de Uso | Comentarios | Diagrama de Flujo | Conceptos de diseño introducidos en este paso |
|---|---|---|---|---|---|
1 |
A simple payment flow involucrando una instrucción de pago de un Deudor que se completa inmediatamente |
Al recibir la instrucción, el primero state es un Completado State creando un flujo de negocio muy simple |
|
INITIATION BEHAVIOUR STATE FLUJO |
|
2 |
La instrucción refleja los datos que usted esperaría ver para un payment flow |
Agregue un Pacs008 al business data biblioteca |
|
BUSINESS DATA BIBLIOTECA |
|
3 |
El Agente de Deudores es notificado cuando se ha procesado un pago. |
|
DOMINIO EXTERNO NOTIFICACIÓN ACCIÓN |
||
4 |
El Agente de Deudores es notificado cuando se ha procesado un pago con un Pacs002. |
Como arriba |
MAPPING FUNCIÓN AGGREGATE FUNCTION |
||
5 |
La Cuenta del Deudor en la instrucción se valida mediante una llamada al sistema del Agente de Deudores. |
El sistema de Deudores proporcionará una respuesta Aceptada o Rechazada, lo que resultará en que la instrucción sea rechazada y el flujo se termine, o en que el flujo continúe. |
|
SOLICITUD/RESPUESTA COMPORTAMIENTO DE ENTRADA EVENT DEFINICIÓN EVENT COMPORTAMIENTO VALIDACIÓN DEL MODELO VISTA GRÁFICA INTENCIONES |
|
6 |
The Customer Credit Transfer La solicitud está desagregada y los elementos de datos incluidos en la Solicitud de Validación de Cuenta del Deudor. La Respuesta de Validación de Cuenta del Deudor incluye nuevos datos. |
|
IMPORTANDO |
||
7 |
El pago se envía a un esquema que proporciona un acuse de recibo (o fallo técnico) y luego el resultado de la validación de la instrucción. Cuando una instrucción es rechazada por el CSM, también proporcionarán una razón para la falla. |
Las respuestas serán Aceptar o Rechazar. Las posibles razones para una instrucción rechazada se proporcionarán como un código ISO. |
|
BIBLIOTECA DE CÓDIGOS DE RAZÓN RESPUESTA NO COMPLETADA EN CUALQUIER EVENT COMPORTAMIENTO |
|
8 |
Si el Banco Acreedor y el Banco Deudor son el mismo, entonces un pago no debe ir al esquema, sino ser registrado directamente. |
Deberá añadir la reserva.state. Actualice el flujo existente para añadir la reserva. Se añadirá el Agente Deudor y el Agente Acreedor.business data. |
|
DECISIONS |
|
9 |
Maneje el escenario, cuando valide una cuenta deudora, se podrían proporcionar una serie de respuestas diferentes en lugar de un simple verdadero o falso. |
Respuestas posibles: Cuenta Válida, Cuenta Aceptada, Cuenta Inválida, Cuenta Bloqueada. Las dos primeras respuestas son un 'aprobado' y las dos últimas respuestas son un 'rechazado'. |
|
BIBLIOTECA DE CÓDIGOS DE RESPUESTA |
|
10 |
Los pagos se verifican en busca de sanciones, lo cual es un subflujo reutilizable. |
Se creará un Sub Flujo y se añadirá a Event Comportamiento en dos lugares |
|
SUB FLUJO |
|
11 |
El pago se enriquece con datos sobre el Agente Deudor que se encuentran dentro de la aplicación. |
Se creará una Función de Dominio y se añadirá a Event Comportamiento. Business Data se actualizará para que se utilice el Agente Deudor enriquecido en la Notificación |
|
FUNCIÓN DE DOMINIO ENRIQUECIMIENTO DE ENTRADA |