DSL 1 - Introducción al DSL de Icon

Empezamos considerando los datos. Los datos son lo que impulsa el procesamiento y la toma de decisiones en todo IPF.

El primer concepto a considerar es el "Business Data Element" (elemento de datos de negocio). Tiene cuatro propiedades:

Cualquier proyecto MPS puede tener tantos elementos de datos de negocio como necesites. Estos elementos se definen dentro de una "Business Data Library" (biblioteca de datos de negocio), que no es más que una colección de datos relacionados, y se pueden definir tantas bibliotecas como se necesiten.

Durante la vida de un pago, cada elemento de datos de negocio es único y puede actualizarse según sea necesario.

El procesamiento de un pago lo realiza un "Flujo". Un flujo representa un único proceso de negocio de extremo a extremo y está diseñado para especificar la vida de un pago. Un único flujo puede tener muchos caminos, cada uno representando una forma distinta de procesar un pago individual en función de los datos proporcionados. Un flujo contiene varias cosas:

Una definición de cada uno de estos aspectos se describe en las siguientes secciones.

Primero consideramos el "Global State Set". El conjunto de estados globales es un conjunto de estados que representan el estado global de un pago. Se utiliza especialmente cuando un pago puede abarcar múltiples flujos (por ejemplo, si el procesamiento se divide en partes de "iniciación" y "ejecución"), pero también puede aplicar un estado de agrupación general a las partes individuales del flujo para simplificar las transiciones de estado a nivel de pago. Cada estado a nivel de flujo puede mapearse a un estado global, de modo que múltiples estados de flujo puedan considerarse como si dejaran el pago en el mismo estado global general.

El siguiente concepto dentro de nuestro flujo es un "State". Es, sencillamente, un punto de reposo en el flujo por el que el pago puede pasar en su recorrido; por ejemplo, podemos tener un flujo muy simple que vaya de "State A" a "State B".

Un estado tiene varias propiedades:

Cada flujo puede contener muchos estados distintos.

Cuando un flujo pasa de un estado a otro, se denomina "State Transition". En IPF, para que se produzca una transición de estado, el sistema debe recibir un "Event" durante el recorrido de procesamiento del pago. En este caso, es en realidad un tipo específico de evento conocido como "Domain Event". Un evento de dominio es una ocurrencia fáctica y persistida: la llegada de un evento significa que algo explícito ha ocurrido y puede causar algún cambio en el procesamiento de nuestro pago.

Un evento tiene varias propiedades:

Cuando se forma un evento, el sistema comprobará su propio comportamiento para determinar qué acciones deben realizarse. Si bien este comportamiento se explora más adelante en este documento, vale la pena señalar aquí que hay tres ocasiones en las que un evento puede provocar un cambio en el procesamiento; se conocen como condiciones de "Event Criteria" y se definen como:

Después de procesar un evento, la aplicación puede realizar una o más actividades para determinar qué sucede a continuación con un pago. Por ejemplo, al recibir "Event A" podríamos querer hacer una validación y llamar a otra aplicación para que valide nuestros datos.

Para apoyar este procesamiento posterior al evento, el concepto más importante es el "External Domain". Representa algún dominio de negocio —no el del flujo actual— con el que necesitamos interactuar.

Por ejemplo, supongamos que necesitamos hablar con un sistema de sanciones en una parte del flujo. Para ello, modelaríamos ese sistema de sanciones como un dominio externo.

Cada dominio externo consta de los tres tipos de interacción que podemos realizar con él:

Es posible que no queramos llamar a un dominio externo para continuar procesando nuestro flujo. Esto puede ocurrir porque sabemos qué hacer a continuación o podemos calcularlo. Para ello, hay dos conceptos más a considerar:

En este caso, una opción es usar la capacidad "Domain Function" que ofrece el propio flujo. Funciona de forma muy similar a un par petición/respuesta en una llamada a un dominio externo, salvo que en el caso de una función de dominio la propia aplicación IPF es un dominio, por lo que la llamada permanece interna (por ejemplo, crear un dominio externo que represente nuestro flujo actual funcionaría igual que una función de dominio, pero sería una mala representación de la lógica de control real). Así que, cuando llamamos a una función de dominio, esperamos recibir una respuesta y luego esa respuesta se transformará en un evento que podrá provocar procesamiento posterior.

Al igual que una petición, la función de dominio tiene varias propiedades:

La segunda opción es un "Additional Event" (evento adicional): también pueden usarse para avanzar el flujo.

Cuando se genera un evento adicional, el sistema lo procesará como si hubiera sido recibido en la aplicación a través de una instrucción o una respuesta.

Añadámoslos a nuestro diagrama:

¿Y si queremos ejecutar lógica condicionalmente? Por ejemplo, puede que solo queramos ejecutar una comprobación de fraude si el valor del pago es superior a 50 £. En este caso podemos usar una "Decision".

Una decisión nos permite ejecutar lógica y, posteriormente, tomar rutas de procesamiento diferentes en función del resultado de esa decisión. Una decisión tiene varias propiedades:

Las decisiones se almacenan dentro de una "Decision Library". Las bibliotecas son independientes del flujo y, por tanto, la misma decisión puede usarse en múltiples flujos.

Podemos usar una decisión en dos lugares:

Añadamos esto a nuestro diagrama:

Otra utilidad útil a considerar es la "Aggregate Function" (función de agregado). Una función de agregado es una pieza de lógica que puede ejecutarse tras la recepción de un evento para realizar algún tipo de cálculo sobre los datos recibidos. Estos datos se consideran "en vuelo" y, por lo tanto, no se persisten en la aplicación.

Un buen ejemplo es un contador que registra cuántas veces ha ocurrido algo durante un flujo: cada vez que se llama a la función, se puede actualizar ese contador. El resultado de la función de agregado pasa a estar disponible más adelante en el flujo.

Otro buen caso de uso es realizar un mapeo de datos para transformar los datos en algo que pueda usarse aguas abajo.

Añadamos la función de agregado a nuestro diagrama:

Los siguientes conceptos a considerar son dos tipos de agrupación. Para separar la lógica que necesitamos cuando procesamos una entrada al sistema (desde una respuesta o instrucción) y generamos el evento, de la lógica requerida al procesar el comportamiento del sistema basado en ese evento, tenemos dos conceptos de agrupación:

Lo siguiente a considerar son segmentos del flujo reutilizables.

Por ejemplo, considera una comprobación de sanciones que podría necesitarse en varios lugares del flujo. Podríamos especificar cada sección del flujo por separado y escribir la lógica cada vez, pero lo ideal sería poder reutilizar la lógica común. Aquí es donde se introduce el concepto de "Subflow".

Un subflujo es un componente de flujo reutilizable. Es esencialmente igual que un flujo en que tiene estados, input behaviours y event behaviours. Sin embargo, un subflujo no tiene vida propia y solo se usa como mecanismo de reutilización y, por tanto, DEBE estar contenido dentro de un flujo exterior. Al llamar a un subflujo, es muy similar en comportamiento a recibir un evento:

Lo clave a entender aquí es que, en lugar de movernos a un estado y luego llamar a una acción como en el procesamiento normal, aquí nos movemos a un pseudoestado que actúa como punto de entrada en el subflujo. El "control" del flujo se cede al subflujo; a partir de ese momento, procesará sus input y event behaviours hasta que alcance un estado terminal en el subflujo. Cuando alcanza un estado terminal, el control vuelve al flujo que lo llamó con un resultado que es el nombre del estado terminal. Esto puede utilizarse para el procesamiento posterior.

Ten en cuenta que, para lograr la reutilización del subflujo en múltiples lugares, cuando un subflujo se coloca dentro de un flujo principal, sus estados se mostrarán como "<subflowid> <subflow state name>", donde <subflowid> es el nombre del pseudoestado del flujo llamante y <subflow state name> es el nombre del estado dentro del subflujo.

Finalmente, también es posible llamar directamente a un flujo desde otro. En este caso, el control se cede al flujo secundario y se espera un resultado de ejecución de vuelta. El flujo hijo puede informar al flujo padre de que ha alcanzado cualquier estado. Lo más común es que esto ocurra cuando se alcanza un estado terminal y el flujo hijo ha terminado el procesamiento, pero también permite realimentación desde el flujo hijo para estados intermedios antes de que finalice. Esto ofrece la posibilidad de pasar el control de ida y vuelta entre hijo y padre según sea necesario.