feat(odata): support v1 element template variable format#132
Open
vringar wants to merge 2 commits into
Open
Conversation
There was a problem hiding this comment.
Pull request overview
Adds backward compatibility to the SAP OData connector so it can handle the legacy v1 (pre-batch) element template variable shape where requestDetails.requestType is missing, by rebinding via a fallback model and converting to the current request format.
Changes:
- Introduces
FallbackODataConnectorRequestto bind the v1 flat variable structure and convert it toODataConnectorRequest(wrapping aSimpleRequest). - Updates
ODataConnector.execute()to detectrequestDetails == nulland re-bind using the fallback model (with an INFO log when used). - Adds test infrastructure + fixture (
hotfix.json) and new binding tests covering the legacy input shape.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
odata-connector/src/main/java/io/camunda/connector/sap/odata/model/FallbackODataConnectorRequest.java |
New fallback request record with validation annotations and conversion to the v2 request structure. |
odata-connector/src/main/java/io/camunda/connector/sap/odata/ODataConnector.java |
Adds runtime fallback re-binding when v1 inputs cause requestDetails to deserialize as null. |
odata-connector/src/test/java/io/camunda/connector/sap/odata/BaseTest.java |
New shared test helper for loading JSON test cases as strings. |
odata-connector/src/test/java/io/camunda/connector/sap/odata/OutboundBaseTest.java |
New helper for creating an OutboundConnectorContextBuilder with secrets. |
odata-connector/src/test/java/io/camunda/connector/sap/odata/HotfixBindingTest.java |
New parameterized tests documenting the binding issue and validating fallback binding + conversion. |
odata-connector/src/test/resources/hotfix.json |
New legacy-input fixture used by the binding tests. |
93f0c69 to
826fbfd
Compare
b0c5b53 to
5481cf4
Compare
5481cf4 to
55041ba
Compare
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds backward compatibility so the OData connector can process variables sent by v1 (pre-batch) element templates in addition to the current v2 format. Both the v2 task type (with fallback detection) and the legacy v1 task type are supported.
Problem
The v1 element template sends variables in a flat structure (
destination,oDataService,entityOrEntitySet,httpMethod.*,payload) without therequestDetails.requestTypediscriminator that the v2 connector expects. Whencontext.bindVariables(ODataConnectorRequest.class)receives v1 input, it silently setsrequestDetails = null, causing runtime failures downstream.Additionally, some customer deployments use the legacy task type
io.camunda:sap:odata:outbound:(with trailing colon) which no v2 worker listens for.Approach
Two complementary mechanisms ensure v1 templates work regardless of which task type they use:
Fallback in
ODataConnector(typeio.camunda:sap-odata:2): After binding, ifrequestDetailsisnull, the connector re-binds usingFallbackODataConnectorRequestand converts to a standard request. This catches v1 templates that happen to target the v2 task type.LegacyODataConnector(typeio.camunda:sap:odata:outbound:): A separate connector class registered via SPI that directly binds flat v1 variables throughFallbackODataConnectorRequestand delegates toODataRequestExecutor.Changes
FallbackODataConnectorRequest.java@NotEmpty,@Pattern,@Valid) and conversion toODataConnectorRequestLegacyODataConnector.javaio.camunda:sap:odata:outbound:ODataConnector.javarequestDetailsis null after bindingOutboundConnectorFunction(SPI)LegacyODataConnectorto service loaderpom.xmls4-v1-get.bpmnBaseTest.javaOutboundBaseTest.javaHotfixBindingTest.javahotfix.jsonTesting
Unit tests
3 parameterized tests in
HotfixBindingTest:ODataConnectorRequestbinding producesrequestDetails = nullfor v1 input (documents the problem)FallbackODataConnectorRequestbinding succeeds with typedHttpMethodinstancestoODataConnectorRequest()correctly converts fallback → canonical requestE2E validation on BTP (SaaS 8.7 cluster)
s4-v1-get.bpmn(task typeio.camunda:sap-odata:2, flat variables). Logs confirmed fallback triggered and OData request constructed correctly.io.camunda:sap:odata:outbound:.LegacyODataConnectorpicked up the job, bound flat variables, and executed the OData request successfully.