Add support for generating code to send MuleSoft Dataweave Transformations to TriggerMesh

[cab105]

I introduced a new runtime flag for spring-boot-migrator called sbm.muleTriggerMeshTransformEnabled that will modify the generated mule-to-boot recipe for handling DataWeave transformations to stream the transformation to TriggerMesh's Dataweave Transformer.

The generated code works best when the service runs inside a Kubernetes cluster leveraging Knative's Sink Binding to associate the the newly migrated service to the TriggerMesh Dataweave transformation, however the service can run on it's own by setting the K_SINK environment variable to the exposed transformation service.

I created a gist to demonstrate what an integration within TriggerMesh would look like.

[fabapp2]

@cab105 Thank you for your contribution!

I had three comments. Feel free to ping me if you want to discuss in person?

[cab105]

@cab105 Thank you for your contribution!

I had three comments. Feel free to ping me if you want to discuss in person?

Thank you for taking a look at @fabapp2 . Will address the rest template, tabs, and test issues, then resubmit.

[sanagaraj-pivotal]

Could we get an integration test for this feature, please refer this test for info

[fabapp2]

Hi @cab105

Are you facing issues with this? If you like we can pair to get the last few bits added and this PR merged?

[cab105]

The codebase has been pretty unstable due to the springboot 3 work, but does look like it has now solidified, and am identifying issues with my original test code that need to be addressed. Once that is resolved, then we should be good to go.

[cab105]

Resync from upstream main branch, added unit tests, and migrated the primary dataweave transformation into a template file.

[cab105]

So I've been able to resolve some of my outstanding issues, and have fixed a couple of issues in SBM proper (https://github.com/spring-projects-experimental/spring-boot-migrator/pull/385 and https://github.com/spring-projects-experimental/spring-boot-migrator/pull/373). Given the current Mule integration test that was cited in the comments is disabled due to https://github.com/spring-projects-experimental/spring-boot-migrator/issues/351, I'm wondering if there's anything else that would be required for this PR (save for a resync with upstream)?

[cab105]

I just realize that there must be some way to toggle these translators if boot creates them... but it should not be an application/system property when possible... it should come from the recipe/action... this could be tricky...

It is. I originally used your approach of @Autowired on SbmApplicationProperties, but the unit test doesn't wire in the SbmApplicationProperties resulting in the tests to use the default behavior, and why I explicitly checked/set the System properties where I did. Granted if there was an easier way to pass a flag through the rewrite engine, then I'd be happy, but it appeared to require a lot more refactoring than I felt comfortable to pass the single flag down to the DwlTransformTranslator class.

[fabapp2]

I just realize that there must be some way to toggle these translators if boot creates them... but it should not be an application/system property when possible... it should come from the recipe/action... this could be tricky...

It is. I originally used your approach of @Autowired on SbmApplicationProperties, but the unit test doesn't wire in the SbmApplicationProperties resulting in the tests to use the default behavior, and why I explicitly checked/set the System properties where I did. Granted if there was an easier way to pass a flag through the rewrite engine, then I'd be happy, but it appeared to require a lot more refactoring than I felt comfortable to pass the single flag down to the DwlTransformTranslator class.

The problem is that the test is not a @SpringBootTest and the SbmApplicationProperties would need to be added to the TestProjectContext test harness. But due to the inheritance design it is not (yet) possible.

What about... you leave the property as it is, for now, fix the few comments left and we finally merge this back in? And I will think about a way to remove the need for the application property. Not 💯 sure yet how this will look like though...