Datos y Mapping
Los datos están en el core de procesamiento de IPF ya que impulsa el procesamiento y decision realizando a lo largo de IPF. Vale la pena leer esta sección sobre datos y persistencia temas relacionados así como los conceptos de Flo-lang.
Business Data
Desde una perspectiva de Flo-lang y flujo de orquestación, el primer concepto que consideramos es el "Business Data Elemento". Tiene cuatro propiedades:
-
"Nombre"
-
"Descripción"
-
Data Type" - el data type puede ser cualquier java tipo, ya sea clases estándar como String, Integer, etc. o sus propios tipos personalizados.
-
Data Category" - un campo opcional, los valores posibles son un conjunto enumerado que se refiere al tipo de datos que está siendo representado por este BusinessDataElement. Este Data Category la etiqueta es utilizada por varios componentes de IPF, como IPF Data Egress y Operational Data Store, que puede registrar automáticamente los datos capturados de Process Flow s automáticamente, dependiendo de la Data Category. Las categorías son:
-
ESTRUCTURA_DE_DATOS_DE_MENSAJE - Estos son datos que provienen de mensajes financieros externos, a menudo modelados como ISO20022 Componentes del Mensaje.
-
ESTRUCTURA_DE_DATOS_DE_PROCESAMIENTO - Datos que se relacionan con el procesamiento de pagos, como metadatos e información sobre el tipo de pago. Esta categoría también se utiliza para custom data type s.
-
IDENTIFICADOR_ADICIONAL - Esto se aplica a los elementos de datos que representan identificadores adicionales que deben asociarse con el pago.
-
PAGO (Obsoleto)- Estos son datos de pago que están modelados como ISO20022 componentes de mensaje dentro de IPF.
-
PROCESAMIENTO_DE_PAGOS (Obsoleto)- Estos son datos que se relacionan con el procesamiento de pagos, como la meta-información y la información sobre el tipo de pago.
-
Cualquier MPS el proyecto puede tener tantas diferentes business data elementos según sea necesario. Estos elementos están definidos dentro de un "Business Data Biblioteca" que es simplemente una colección de relacionados business data y tantos diferentes business data Las bibliotecas pueden definirse según sea necesario.
IPF proporciona una serie de configuraciones predefinidas business data bibliotecas. Por defecto, a cualquier proceso se le asigna la biblioteca "error" que proporciona elementos predeterminados para manejar fallos en el flujo, a saber:
Los conceptos de razón y response codes se discuten más adelante en este documento. |
Dentro de la duración de un pago cada business data el elemento es único y puede ser actualizado según sea necesario.
Mapping Funciones
La siguiente utilidad a considerar es la "Función de Mapeo". Un mapping Una función es un conjunto de lógica que se utiliza para transformar business data elementos en diferentes business data elementos. Pueden ser utilizados en ejemplos de uno a uno, uno a muchos o muchos a muchos.
| Mapping La función puede vivir globalmente (es decir, estar disponible para todos los flujos) o ser localmente restricted a un solo flujo. |
Hay tres situaciones diferentes que mapping se pueden utilizar funciones, y estas se describen a continuación:
Generando datos sobre Event Recibo (Aggregate Functions)
El primer caso de uso para un mapping la función es cuando se necesita realizar algún tipo de lógica cuando un event se recibe y/o al dato recibido en un event para uso posterior en un flujo. Este tipo de mapping La función a menudo se denomina " Aggregate Function.
Un buen ejemplo de esto es un contador que registra el número de veces que algo ha ocurrido durante un flujo.- cada vez que se llama a la función, podemos actualizar ese contador. El resultado de la Aggregate Function entonces se vuelve disponible para el flujo.
Los datos generados como parte de la mapping aquí se considera "en vuelo" y, por lo tanto, *no es persistido por la aplicación*. Cuando se utiliza aquí, la función se reproducirá durante la recuperación, por lo que se debe tener cuidado al calcular valores dinámicos como fechas. |
Incluido en el diagrama, podemos ver el contexto de la Aggregate Function después del Event pero antes State transición
Enriqueciendo event datos (Enriquecimiento de Entrada)
Este mapping La función del caso de uso es cuando usted desea generar (o actualizar)business data elementos que deben almacenarse en un recibido event. Esto se denomina a menudo "Enriquecedor de Entrada".
El punto clave a entender en la diferencia con el tipo "agregado" de mapping arriba es que estos datos se añadirán a la event y persistió. Esto significa, por ejemplo, que se enviará y estará disponible dentro del processing data flujo para uso fuera de IPF.
Un buen ejemplo de utilizar una función de Enriquecimiento de Entrada es donde el event requiere datos que se fusionan con los datos disponibles en el agregado. Una forma de ejecutar este tipo de requisito sería realizar una obtención de agregado desde fuera del dominio y luego actualizar la entrada antes de enviarla. Con una función de enriquecimiento de entrada, esto se puede hacer de manera mucho más ordenada sin la sobrecarga de recuperar el agregado.
Añadiendo la función de Enriquecimiento de Entrada, esto está enriqueciendo el event data:
| Una vez que un mapping La función ha sido utilizada en un event de esta manera, los datos que produce se tratan igual que cualquier otro dato recibido en el event. |
Calculando datos para enviar a una acción
Este caso de uso para un mapping La función es invocarla como parte del envío de datos a un sistema descendente. Esto permite la manipulación de un punto de datos existente en el momento del envío o la generación de datos que no se proporcionan en el flujo pero que son necesarios para realizar una llamada de acción descendente.
| Como el tipo agregado de mapping por encima, estos datos son transitorios y no se persisten, su duración es puramente para la invocación de la acción. |