Spring-Boot-Gegenstueck zu novaris-legacy-parent/novaris-claims-mq. Sendet
Schadensmeldungen per Kafka-Request/Reply an ClaimIntakeKafkaListener
(novaris-policy-core-modern) - siehe docs/70-migration/03-messaging-jms-zu-kafka.md.
claims.submission.ClaimSubmissionKafkaClient - der einzige produktive Typ dieses Moduls,
Kafka-Gegenstueck zu ClaimSubmissionClient (JMS-Request/Reply mit fester Antwort-Queue +
JMSCorrelationID). Nutzt Spring Kafkas ReplyingKafkaTemplate, der Reply-Topic- und
Correlation-Header automatisch setzt/ausliest.claims.submission.KafkaClaimClientConfig - Producer-/Reply-Consumer-Infrastruktur fuer
ReplyingKafkaTemplate. Seit Migrationsphase M6 mit aktiviertem Micrometer-Tracing
(setObservationEnabled(true), siehe docs/70-migration/10-observability-tracing.md) -
Correlation-Header und Trace-Kontext sind zwei getrennte Mechanismen, die hier beide aktiv
sind.# aus novaris-modern-parent/:
mvn -pl novaris-claims-modern -am test
ClaimSubmissionKafkaClientTest beweist den vollstaendigen Request/Reply-Roundtrip gegen
einen echten eingebetteten Kafka-Broker (spring-kafka-test, @EmbeddedKafka) - ganz ohne
Docker. Der Antwortende ist ein minimaler Test-Doppelgaenger von ClaimIntakeKafkaListener
(die eigentliche Fachlogik ist bereits in novaris-policy-core-modern unit-getestet).