LoadBalancerInterceptor does not become active

Workflows
1

I’m currently updating the workflow artifact to A12 2022.06.
But I’m facing a problem with inter-service communication in workflows. In order to use logical URLs with concrete hostnames, the RestTemplates used must have a LoadBalancerInterceptor.

The rest template for the inter-service communication (Camunda,…) is initialized in the class com.mgmtp.a12.connector.rest.GenericRestConnector. Interceptors are also placed here.

In my case, if you debug the start of workflows, you can see that the GenericRestConnector is initialized twice.

Once from the RestServerConnectorAutoConfiguration:

RestServerConnectorAutoConfiguration > RestServerConnectorFactoryBuilder > RestServerConnectorFactory > GenericRestConnector
here the LoadBalancerInterceptor is added to the template

Once from the UaaRestClientConfig (from workflows!):

UaaRestClientConfig > UAARestClientFactoryBuilder > UAARestClientFactory > RestServerConnectorFactory > GenericRestConnector
here the LoadBalancerInterceptor is not added to the template

Apparently the second RestTemplate is then used when communicating with Camunda and the host is not resolved. This leads to

org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http://kunden-camunda/engine-rest/process-definition":
participant-camunda; nested exception is java.net.UnknownHostException: participant-camunda
    at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:785)

The documentation mentions that interceptors simply have to “live” in the Spring context to be automatically added to any rest template used.
This does not appear to be the case.

Another approach to adding an interceptor is described here: https://www.baeldung.com/spring-rest-template-builder. This worked with previous versions of A12 workflow, but it doesn’t seem to work in the current one either.

How do I add a LoadBalancerInterceptor to each rest template?

2

Hello, this has been considered as a bug in Workflows and shall be fixed in Workflows 8.0.8 in A12WF-980. I will let you know here when it is released. Thanks for reporting.

3

Thank you for your reply. Do you have any advice for a workaround until 8.0.8 of Workflows is released? Can you roughly estimate when the new version with the bug fix will be released?

4

Hi @mathias-early-ravine,
unfortunately I have no advice for a workaround.
But the bug fix will be in the upcoming Workflows release, which is scheduled for the end of next week. Though please keep in mind that this can vary a bit.

5

Hi all,

This is fixed in version 8.0.9 which has been released today.

@mathias-early-ravine Please give it a try and let us know if this fixes the issue. Thanks!

6

Thank you for the fix! It does indeed fix the issue.

However, we are seeing a minor and a bigger issue with the new version.

a) The transitive dependency com.mgmtp.a12.formengine:formengine-model:34.8.1 is not available in the geta12-artifactory yet. We helped ourselves with the latest version available 34.7.0.

b) I created a new topic for this: Error creating bean WorkflowsProperties

One final question: will there be an update to https://geta12.com/releases-overview/#/workflows with regard to the last two patch-versions? I already noticed some not-so-minor changes (e.g. kotlin 1.6 > 1.7, camunda 7.17 > 7.18).

Thanks again for your support!

7

Hi @anon67142020,

I’m glad the fix worked!

Regarding some of the open points:

  1. Apparently, there was an issue with the form engine 34.8.1 release that may cause this issue. In Workflows 8.1.2, we integrated 34.8.2 which should fix it.
  2. We’ll have to investigate the WorkflowsProperties issue
  3. We downgraded back to Camunda 7.17 in Workflows 8.1.1. Camunda makes conflicting statements about their release policy…we will avoid Camunda minor upgrades in non-breaking releases in the future.
  4. How exactly does a minor Kotlin upgrade affect you?

Thanks for your input!

8

@psommerhoff thanks for your answer.

Could you elaborate a bit on the downgrade auf Camunda?

We are about to go productive with 2022.06.4.1 - including Camunda 7.18.

We’ve already made some changes regarding dependencies.

Specifically we are using

  • the correct 7.18-spring-boot-starters (not the old ones included in the distribution)
  • a downsized set of groovy-dependencies

Updating the starters made it necessary to “downgrade” the Jackson-dateformat:

    @Bean
    public ServletContextInitializer initializer() {
        return servletContext -> {
            servletContext.addListener(new CustomJacksonDateFormatListener());
            servletContext.setInitParameter("org.camunda.bpm.engine.rest.jackson.dateFormat", "yyyy-MM-dd'T'HH:mm:ss");
        };
    }

(the standard dateformat is yyyy-MM-dd’T’HH:mm:ss.SSSZ since Camunda 7.8, but workflows / client is working with yyyy-MM-dd’T’HH:mm:ss)

We don’t see any issues with Camunda 7.18 (yet).

9

Hi @anon67142020,

In A12 Workflows ^8.1.1, we integrate Camunda 7.17. However, if you already upgraded successfully to Camunda 7.18 within your project, that is also fine and will work with the other components.

By the way, we will also integrate the proper spring-boot-starters because we realized the community extensions have been incorporated into official ones. Once that’s done, you won’t need to override those dependencies anymore.

10

Hi @anon67142020,

Just a quick update here: as of 2023.02, the community extensions have been removed so that you’ll be able to remove your workaround.