DSL 12 - Usando custom datos empresariales

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¿datos empresariales?

Los datos comerciales personalizados son los tipos de datos que podemos crear en nuestras bibliotecas de datos comerciales. Si recuerda, en la biblioteca actual que configuramos teníamos:

Así que aquí estábamos utilizando el tipo de dato predefinido "CashAccount" 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 elemento de datos empresariales para mostrar cómo puede ser utilizado 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 configurar las características apropiadas de la clase. Puede agregar la dependencia de lombok añadiéndola a la pom.xml:

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
</dependency>

¡Importante!

Una restricción clave aquí es que, dado que los puntos de datos suministrados deben ser almacenados en los eventos, ellos DEBEN ser serializables en json. Business Data se persiste en eventos en forma de json.*

Ahora que hemos construido nuestra clase, necesitamos asegurarnos de que se ha creado y añadido a la configuración de mps. Para hacer esto, simplemente debe reconstruir el proyecto:

mvn clean install

Añadiendo el custom datos

Añadamos un nuevo elemento de datos empresariales 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 Archivo Invalidar Caches y luego inténtelo 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 elemento de datos empresariales debería verse así:

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 elemento de datos empresariales 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, deberemos 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 que la solución funcione. Inicie la aplicación como se indicó anteriormente (las instrucciones 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 analicemos los diferentes eventos que se han recibido. Si ahora presentamos el pago en el Developer GUI y muestre la vista de flujo (buscar por id de unidad de trabajo, 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 evento "Flujo Iniciado" del flujo de iniciación, veremos que ahora tiene el nuevo objeto de datos de ejemplo disponible al final de la definición del evento:

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 el dominio raíz), este módulo es responsable de incorporar dependencias externas. Cuando usted cree su propio proyecto más adelante utilizando el generador de plantillas, esta carpeta seguirá siendo creada 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 nuestros propios tipos de Java e importándolos como custom elementos de datos empresariales.
Reutilizando otros tipos de Java externos importándolos a través de Maven dependencies.

Ahora que ha configurado y revisado la reutilización de tipos de Java, analicemos la siguiente etapa de reutilización.- xref:shared_1.adoc[DSL 13 - Uso de conceptos compartidos (Parte Uno - Dentro de una Solución)]