Datos y Mapeo
Los datos son el núcleo del procesamiento de IPF, ya que impulsan el procesamiento y la toma de decisiones en todo 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 tipo de dato puede ser cualquier tipo de Java, 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 tipos de datos.
-
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 tantos elementos de datos empresariales diferentes como necesite. Estos elementos se definen dentro de un "Business Data "Library" que es simplemente una colección de datos empresariales relacionados y se pueden definir tantas bibliotecas de datos empresariales diferentes como sea necesario.
IPF proporciona una serie de bibliotecas de datos empresariales preconfiguradas. 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 códigos de razón y respuesta se discuten más adelante en este documento. |
Dentro de la duración de un pago, cada elemento de datos comerciales es único y puede ser actualizado según sea necesario.
Funciones de Mapeo
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 elementos de datos empresariales en diferentes elementos de datos empresariales. Pueden ser utilizados en ejemplos de uno a uno, uno a muchos o muchos a muchos.
| La función de mapeo puede vivir globalmente (es decir, estar disponible para todos los flujos) o estar restringida localmente 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 es necesario realizar algún tipo de lógica cuando se recibe un evento y/o sobre los datos recibidos en un evento para su uso posterior en un flujo. Este tipo de mapping La función se denomina a menudo "Función Agregada".
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 Función Agregada 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 Función Agregada después de la Event pero antes State transición
Enriquecimiento de datos de eventos (Enriquecimiento de Entrada)
Este mapping La función de caso de uso es cuando usted desea generar (o actualizar) elementos de datos comerciales que serán almacenados en un evento recibido. Esto se conoce a menudo como un "Enriquecedor de Entrada".
El punto clave a entender en la diferencia con el tipo "agregado" de mapping Lo anterior es que estos datos se agregarán al evento y se persistirán. Esto significa, por ejemplo, que se enviarán y estarán disponibles dentro del flujo de datos de procesamiento para su uso fuera de IPF.
Un buen ejemplo de utilizar una función de Enriquecimiento de Entrada es cuando el evento 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 tipo enriquecimiento de entrada, esto puede hacerse de manera mucho más ordenada sin la sobrecarga de recuperar el agregado.
Al agregar la función Input Enricher, esto enriquece los datos del evento:
| Una vez que un mapping La función se ha utilizado en un evento de esta manera, los datos que produce se tratan igual que cualquier otro dato recibido en el evento. |
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 a una 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. |