Release Notes

MLE 24.7.0

Neue Funktionen und Verbesserungen

Server-Details in Application Info deaktivieren (FICS-8173)

Es ist jetzt möglich über die property mle.application-info-details-visible zu steuern, ob die Server-Details in der Application Info angezeigt werden sollen.

Umstellung der Anbindung an ICS von OpenFeign auf WebClient (MLE-259)

Generell wurden in diesem Release produktübergreifend alle Client-seitigen Implementierungen von REST-Services, welche auf Spring Cloud OpenFeign basieren, auf Spring WebClient migriert. In MLE betrifft das den IcsClaimExpenditureClient (vorher ClaimClient, s.u.), der Schaden- und Schadenaufwandsdaten zu einem Großschadenereignis ermittelt.

Weiterhin erfolgt die Anbindung des Schadensystems über das ClaimExpenditureRepository. Falls hier eine andere Implementierung als das IcsClaimExpenditureRepository zum Einsatz kommt, die vom IcsClaimExpenditureClient unabhängig ist, sind voraussichtlich keine Anpassungen der Konfiguration nötig.

Eine wesentliche Änderung der Standardimplementierung für ICS ist, dass die Aufgaben des ehemaligen (OpenFeign) ClaimClient nun zwecks besserer Konfigurierbarkeit im Projekt nun auf zwei Klassen aufgeteilt sind: IcsClaimExpenditureClient und WebClient. Der WebClient wird vorkonfiguriert (u.a. mit baseurl und Authentifizierungseinstellungen) an den IcsClaimExpenditureClient übergeben und von diesem benutzt, um die Schnittstelle aufzurufen.

Dem IcsClaimExpenditureClient kann außerdem eine Subklasse von ExpendituresResultDto übergeben werden, in die die empfangenen Daten deserialisiert werden sollen. Bei einer Erweiterung der ausgetauschten Daten im Projekt ist so eine einfache Konfiguration möglich.

Änderungen von Dependencies

Folgende Dependency kann vollständig entfernt werden:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

An ihre Stelle tritt die neue Dependency für Spring Boot Webflux und, abhängig von der Konfiguration im Projekt, der spring-security-oauth2-client:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-client</artifactId>
</dependency>
Umbenennung relevanter Klassen

Um den Unterschied zwischen generischen Klassen und solchen, die speziell für die Interaktion mit einem ICS-Schadensystem gedacht sind, deutlicher zu machen, wurden bei dieser Gelegenheit außerdem ein paar Umbenennungen vorgenommen:

  • ClaimClientIcsClaimExpenditureClient

  • ClaimExpenditureMapperIcsClaimExpenditureMapper

  • RetrieveExpenditureResultDtoExpendituresResultDto

Konfiguration der benötigten Beans

Da OpenFeign vollständig entfernt wurde, kann die Annotation @EnableFeignClients (in der im Projekt äquivalenten Klasse zur MleSampleApplication) ersatzlos entfernt werden.

Die ICS-Standardimplementierung benötigt jetzt drei Beans. Als Muster kann die SampleAutoConfiguration verwendet werden:

@Configuration
public class SampleAutoConfiguration {

    @Bean
    @ConditionalOnProperty(name = "ics-expenditure.enabled", havingValue = "true")
    @ConditionalOnMissingBean(ClaimExpenditureRepository.class)
    public ClaimExpenditureRepository icsExpenditureRepository(IcsClaimExpenditureClient client,
                                                               IcsClaimExpenditureMapper mapper) {
        return new IcsClaimExpenditureRepository(client, mapper);
    }

    @Bean
    @ConditionalOnProperty(name = "ics-expenditure.enabled", havingValue = "true")
    @ConditionalOnMissingBean(IcsClaimExpenditureClient.class)
    public IcsClaimExpenditureClient icsExpenditureClient(WebClient webClient,
                                                          @Value("${ics-expenditure.endpoint:/expenditure}") String expenditureEndpoint) {
        return new IcsClaimExpenditureClient(webClient, ExpendituresResultDto.class, expenditureEndpoint);
    }

    @Bean
    @ConditionalOnProperty(name = "ics-expenditure.enabled", havingValue = "true")
    @ConditionalOnMissingBean(WebClient.class)
    public WebClient icsExpenditureWebClient(WebClient.Builder builder,
                                             @Value("${ics-expenditure.rest-url:http://localhost:8080/ics/rest}") String baseUrl) {
        return builder.baseUrl(baseUrl).build();
    }
}

Bitte beachten: Die Kontextabhängige Erstellung von Beans hat sich in der Beispielanwendung geändert. Siehe dazu auch unten den Abschnitt "Relevante Properties".

Der WebClient muss außerdem mit weiteren Einstellungen, u.a. für Authentifizierung konfiguriert werden, wie etwa in der folgenden WebClientConfiguration aus der Beispielanwendung (mle-core-sample):

@Configuration
public class WebClientConfiguration {

    @Bean
    public WebClientCustomizer configureWebClients(ClientRegistrationRepository clientRegistrationRepository,
                                                   OAuth2AuthorizedClientRepository authorizedClientRepository,
                                                   @Value("${ics-expenditure.oauth2.client-registration-id:oauth}") String oauth2ClientRegistrationId) {
        return builder -> builder
                .filter(this::setAcceptLanguageHeader)
                .apply(oauth2Configuration(clientRegistrationRepository, authorizedClientRepository))
                .defaultRequest(setRegistrationId(oauth2ClientRegistrationId))
                .filter(ExchangeFilterFunction.ofRequestProcessor(this::checkOAuth2Configured));
    }

    private Mono<ClientResponse> setAcceptLanguageHeader(ClientRequest clientRequest,
                                                         ExchangeFunction exchangeFunction) {
        var languageTag = LocaleContextHolder.getLocale().toLanguageTag();
        var newClientRequest = ClientRequest.from(clientRequest)
                .header(HttpHeaders.ACCEPT_LANGUAGE, languageTag)
                .build();
        return exchangeFunction.exchange(newClientRequest);
    }

    private Consumer<WebClient.Builder> oauth2Configuration(ClientRegistrationRepository clientRegistrationRepo,
                                                            OAuth2AuthorizedClientRepository authorizedClientRepo) {
        return new ServletOAuth2AuthorizedClientExchangeFilterFunction(clientRegistrationRepo, authorizedClientRepo)
                .oauth2Configuration();
    }

    private Consumer<WebClient.RequestHeadersSpec<?>> setRegistrationId(String oauth2ClientRegistrationId) {
        return spec -> spec.attributes(ServletOAuth2AuthorizedClientExchangeFilterFunction
                                               .clientRegistrationId(oauth2ClientRegistrationId));
    }

    private Mono<ClientRequest> checkOAuth2Configured(ClientRequest clientRequest) {
        if (clientRequest.attribute(OAuth2AuthorizedClient.class.getName()).isEmpty()) {
            return Mono.error(illegalStateException("OAuth2 client is not configured correctly."));
        } else {
            return Mono.just(clientRequest);
        }
    }
}
Relevante Properties

Alle relevanten Properties für die Anbindung der ICS-Standardimplementierung sind im Folgenden aufgelistet:

ics-expenditure:
    enabled: false
    rest-url: http://localhost:8080/ics/rest
    endpoint: /expenditure
    oauth2:
        client-registration-id: oauth
    auth:
        username: ics-api
        password: ics-api

Bitte beachten: Das unpassende Präfix claim wurde durch ics-expenditure ersetzt. Die Properties mit dem Präfix spring.cloud.openfeign können gelöscht werden.

Anders als bisher werden in der Standardanwendung keine Beans mehr mit der Annotation @Profile konfiguriert. Stattdessen kommt die Annotation @ConditionalOnProperty zum Einsatz (F10-weite Richtlinie, siehe diesen Blogeintrag). In der Beispielanwendung wird die ICS-Implementierung über das Property ics-expenditure.enabled=true aktiviert. Alternativ kann auch die Datei application-ics.yaml aus dem Beispielprojekt übernommen werden, falls weiterhin das Springprofil ics verwendet werden soll.

Weitere notwendige Änderungen

In Folge des Umstiegs auf F10 Commons 24.7 wird das Interface AppShellConfigurator nun in der Beispielanwendung von der eigenen Klasse MleAppShellConfigurator (statt wie bisher von der Klasse MleSampleApplication) implementiert. Im Projekt muss die Webapp dementsprechend angepasst werden.

Behobene Fehler

Datei MANIFEST.MF in Modul mle-core-business korrigiert (MLE-252)

Im der jar-Datei des Moduls mle-core-business fehlte in der dort enthaltenen Datei META-INF/MANIFEST.MF die Meta-Information zu Faktor-IPS-Typen. Dadurch konnten in Eclipse im Kundenprojekt im Modul mle-core-business enthaltene Aufzählungstypen nicht referenziert werden. Stattdessen kam es in Eclipse zur Fehlermeldung "Der Aufzählungstyp mle.MajorLossEventType, welcher von diesem Aufzählungstyp referenziert wird, existiert nicht".