... | ... | @@ -152,7 +152,14 @@ This picture shows how each workflow was configured in the 3 implementations: |
|
|
|
|
|
|
|
|
# Recommendation
|
|
|
Abstract away the workflow components and create a "Plug-and-play" workflow architecture as follows.
|
|
|
Abstract away the workflow components and create a "Plug-and-play" workflow architecture as follows:
|
|
|
### Workflow service should be Workflow engine agnostic (to support Plug-n-Play architecture)
|
|
|
- Remove airflowRunId property from WorkflowStatus class in org.opengroup.osdu.workflow.model
|
|
|
- Workflow service and workflow engine two-way communications via workflowId generated by Workflow service core implementation
|
|
|
- Workflow engine to update workflow status by calling Workflow service with workflowId (e.g. finished, failed, etc.)
|
|
|
- The committee should contribute and leverage shared Python Libraries for transformation and enrichment business logic
|
|
|
Add Workflow client in [osdu_api Python SDK](https://community.opengroup.org/osdu/platform/system/sdks/common-python-sdk)
|
|
|
|
|
|
|
|
|
|
|
|
(On July 6th, the PMC voted to go ahead with Airflow as the default implementation for now, so this recommendation will not be adopted)
|
... | ... | |