Refactoring WorkflowEngine and WorkflowRunService
Description:
Main goals of refactoring ingestion core:
- Simplify class structure for better maintainability and future improvements.
- Introduce more interfaces with implementations to separate responsibilities.
- Change some method access modifiers for better extensibility.
For example, Airflow v3 support can now be implemented more easily.
The majority of changes were made in core module, with some dependent changes in GC module. Other modules remain unchanged.
Main changes:
- Introduced new interfaces:
-
IAirflowApiClient, to handle Airflow authorization and API calls. -
IWorkflowRunExtension, a dedicated interface for extension methods.
-
- Reorganized Workflow Engine implementation classes by moving shared logic into an abstract class.
- Changed injection of
IWorkflowEngineServicebeans from@Conditionalannotations to a centralized provider class (WorkflowEngineServiceProvider). - These changes allow to simplify the class structure in the GC module.
Detailed changes
-
WorkflowRunServiceImpl: Introduced some protected methods and changed some private methods to protected for future code reuse. -
AirflowWorkflowEngineServiceImplandAirflowV2WorkflowEngineServiceImpl: Refactored these classes by creating a new abstract class,AbstractAirflowWorkflowEngineService, for common code. All distinct code is now placed inAirflowWorkflowEngineServiceImplandAirflowV2WorkflowEngineServiceImpl, which extendAbstractAirflowWorkflowEngineService. -
IWorkflowEngineService: Added a new default method,getVersion(), to the interface. -
CloudConnectedOuterServicesBuilder: Refactored dependencies to depend on theIWorkflowEngineServiceinterface instead of a concrete class for retrieving the version -
WorkflowEngineServiceProvider: Created this new class to provideIWorkflowEngineServicebeans to the Spring context depending on settings (Airflow version). -
IAirflowApiClient: Created a new interface with acallAirflow()method to handle Airflow authorization and API calls. Existing functionality for authorizing Airflow and calling APIs in the workflow-core module has been moved fromAirflowWorkflowEngineServiceImpl,AirflowV2WorkflowEngineServiceImpl, andAirflowV2WorkflowEngineExtensiontoBasicAuthAirflowApiClient, a new implementation ofIAirflowApiClient. -
AirflowV2WorkflowEngineExtension: Simplified. It now only implementsIWorkflowEngineExtension. (Previously, it extendedAirflowV2WorkflowEngineServiceImpland implementedIWorkflowEngineServiceinterface). -
IWorkflowEngineServiceBeans injection: The classesAirflowWorkflowEngineServiceImpl,AirflowV2WorkflowEngineServiceImpl, andAirflowV2WorkflowEngineExtensionare no longer marked as@Serviceclasses. Instead, theWorkflowEngineServiceProviderclass is now responsible for injectingIWorkflowEngineServicebeans. -
IWorkflowRunExtension: Created a new interface and implementationWorkflowRunExtensionImpl. Used inRunDetailsApito callIWorkflowEngineExtensionmethods. -
Injection configuration: The injection configuration has been simplified. Now, a single condition in
WorkflowEngineServiceProvider(depending on theosdu.airflow.version2setting) is used, instead of using@ConditionalOnPropertyannotations onAirflowWorkflowEngineServiceImpl,AirflowV2WorkflowEngineServiceImpl, andAirflowV2WorkflowEngineExtension.
Dependent changes in gc module:
-
GcpComposerAirflowApiClient: Created new class for authorizing Airflow usingComposerIaapClientorComposerV2Client(ComposerClientinterface). - Removed:
GcpComposerAirflowExperimentalEngineServiceImplandGcpComposerAirflowV2EngineServiceImplclasses. - Removed: Condition classes:
ComposerAirflowExperimentalConditionandComposerAirflowV2Condition.
There are no changes in other provider modules.
There are no changes in logic.
Diagram of changes (before and after refactoring):
How to test:
Integration and acceptance tests were performed. All previously passing tests are still passing.
Changes include:
-
Refactor (a non-breaking change that improves code maintainability). -
Bugfix (a non-breaking change that solves an issue). -
New feature (a non-breaking change that adds functionality). -
Breaking change (a change that is not backward-compatible and/or changes current functionality).
Changes in:
-
Common code -
GCP -
Azure -
AWS -
IBM
Dev Checklist:
-
Added Unit Tests, wherever applicable. -
Updated the Readme, if applicable. -
Existing Tests pass -
Verified functionality locally -
Self Reviewed my code for formatting and complex business logic.
Edited by Andrii Osadchuk [EPAM / GCP]