DSL 12 - Usando custom business data
|
Iniciando
El paso del tutorial utiliza la solución "raise_additional_event" del proyecto como su punto de partida. Si en algún momento desea ver la solución a este paso, puede encontrarla en la solución "add_custom_types". |
¿Qué es custom business data?
Custom business data son los tipos de datos que podemos crear en nuestro business data bibliotecas. Si recuerda, la biblioteca actual que configuramos tenía:
Así que aquí estábamos utilizando el "CashAccount" predefinido.data type que proviene del modelo de datos Icon. ¿Qué pasaría si quisiéramos utilizar nuestros propios tipos personalizados?
Para demostrar esto, vamos a crear un nuevo bean y añada esto a un nuevo business data elemento para mostrar cómo se puede utilizar dentro del DSL.
Configuración de DSL
Definiendo el bean
Primero, vamos a crear nuestro custom bean-esto se va a colocar en el proyecto de bibliotecas externas en la raíz del dominio (NOTA - tendrá que crear el src/main/java directorio y utilice el nombre del paquete com.iconsolutions.ipf.tutorial.external).
Creará un bean como sigue:
package com.iconsolutions.ipf.tutorial.external;
import lombok. AllArgsConstructor;
import lombok. Builder;
import lombok. Data;
import lombok. NoArgsConstructor;
import java.io. Serializable;
@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class IpfTutorialBean implements Serializable {
private String stringField;
private int intField;
}
Así que ese es nuestro objeto simple, note que estamos utilizando lombok aquí como una forma abreviada para establecer las características de clase apropiadas. Puede agregar la dependencia para lombok añadiéndola a la pom.xml:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</dependency>
|
¡Importante!
Una clave restriction aquí está que los puntos de datos proporcionados deben ser almacenados en el events, deben ser json serializable. Business Data se persiste en events in json form. |
Ahora que hemos construido nuestra clase, necesitamos asegurarnos de que se ha construido y añadido a la mps configuración, para hacer esto simplemente necesitamos reconstruir el proyecto:
mvn clean install
Añadiendo el custom datos
Vamos a añadir un nuevo business data elemento a nuestro existente Business Data Biblioteca. Usted le dará el nombre de "Ejemplo de Datos" y una descripción de "Datos de ejemplo simples".
Ahora, en la selección de tipo, intente y elija "IpfTutorialBean". Debería encontrar que no está presente.
Para hacerlo disponible, simplemente presione CTRL+R mientras está en el cuadro de selección para abrir la entrada de búsqueda. Luego, marque la casilla de verificación en la parte superior:
Tenga en cuenta que presionar CTRL+R por segunda vez también marcará la casilla.
Consejo Principal Si tiene problemas para ver su nueva clase, intente y luego intente de nuevo.
|
Busque el "IpfTutorialBean" y haga doble clic para agregar.
Luego simplemente escriba "IpfTutorialBean" en el Data Type y ahora debería poder ver y seleccionar nuestro objeto. Una vez hecho, nuestro business data El elemento debe verse como:
Para los propósitos de la prueba, añadamos nuestro punto de datos de muestra a nuestro Initiation Behaviour de nuestro InitiationFlow:
Finalmente, es bueno mirar en la vista del proyecto; si desplazamos hacia abajo en nuestro modelo, podemos ver:
Aquí se muestran todas las clases que han sido incluidas de esta manera.
Eso es todo, hemos añadido un custom business data elemento y lo utilizó para enviarlo en la iniciación.
Java Implementación
Actualizando la iniciación
Para probar esto, simplemente añadiremos el nuevo objeto en nuestra llamada de iniciación. Necesitaremos añadir el punto de datos a nuestro controlador de iniciación; primero, necesitaremos reconstruir para recoger nuestros nuevos cambios:
mvn clean install
Y luego, una vez construido, actualizamos nuestro controlador de iniciación para enviar un nuevo bean:
return Mono.fromCompletionStage(IpftutorialmodelDomain.initiation().handle(new InitiateInitiationFlowInput. Builder(entityId)
.withProcessingContext(ProcessingContext.builder()
.unitOfWorkId(unitOfWorkId)
.clientRequestId(clientRequestId)
.build())
.withPaymentInitiation(samplePain001)
.withExampleData(IpfTutorialBean.builder().intField(7).stringField("Test").build())
.build()).thenApply(done -> InitiationResponse.builder().requestId(clientRequestId).uowId(unitOfWorkId).aggregateId(done.getAggregateId()).build()));
Verificando nuestra solución
Como es habitual, ahora verifiquemos cómo funciona la solución. Inicie la aplicación como se indicó anteriormente (instructions están disponibles en Revisando la solicitud inicial si necesita un repaso!)
Entonces, como es habitual, podemos enviar un pago.
curl -X POST localhost:8080/submit | jq
Esta vez examinemos los diferentes events que han sido recibidos. Si ahora mencionamos el pago en el Developer GUI y muestre la vista de flujo (search by unit of work id, haga clic en ver, haga clic domain events) y debemos ver el conjunto normal de Domain Events. Sin embargo, esta vez si hacemos clic para ver el cuerpo del "Flujo Iniciado" del flujo de iniciación event veremos que ahora tiene el nuevo objeto de datos de ejemplo disponible en la parte inferior de la event definición:
Extendiendo más allá de clases simples
Añadiendo sus propias bibliotecas
También podemos añadir cualquier Maven dependency queremos dar acceso al beans dentro de él. Esto se puede hacer simplemente añadiendo la dependencia en el pom de las dependencias de la biblioteca externa. Proceda y pruebe esto con una biblioteca de su elección y vea si puede hacer que aparezca para usted en MPS!
Ramificación más allá del módulo "external-libraries"
El proyecto tutorial original nos proporcionó un módulo llamado "Bibliotecas extendidas" (bajo domain-root), este módulo es responsable de incorporar dependencias externas. Cuando usted crea su propio proyecto más adelante utilizando el scaffolder esta carpeta aún se construirá para usted. La clave aquí es que este módulo utiliza Maven sombreado para colapsarse a sí mismo y a cualquier dependencia, de modo que MPS puede encontrar los archivos en el class path. Podemos ver esto en el pom de nuestro módulo:
<!-- Shade everything, Maven still is the source of truth for the versions, but we can get a
Smoother MPS experience if it "sees" a single library of dependencies
-->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3. 2. 4</version>
<configuration>
<createDependencyReducedPom>false</createDependencyReducedPom>
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>shaded</shadedClassifierName>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Luego, se hace referencia a la biblioteca externa en el MPS modelo para el proyecto para que se pueda consultar. Podemos hacer esto con cualquier módulo que deseemos.
Conclusiones
En esta sección examinamos:
-
Creando nuestro propio java tipos e importándolos como custom business data elementos.
-
Reutilizando otros externos java tipos importándolos a través de Maven dependencies.
Ahora, habiendo configurado, considere la reutilización de java tipos, analicemos la siguiente etapa de reutilización-xref:shared_1.adoc[DSL 13 - Uso de conceptos compartidos (Parte Uno - Dentro de una Solución)]