Feature:Sapbw4Connector

[akashverma0786]

Describe your changes:

Fixes #

I worked on ... because ...

Type of change:

• Bug fix
• Improvement
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation

High-level design:

N/A — small change.

Tests:

Use cases covered

Unit tests

Backend integration tests

Ingestion integration tests

Playwright (UI) tests

Manual testing performed

UI screen recording / screenshots:

Not applicable.

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• My PR is linked to a GitHub issue via Fixes #<issue-number> above.
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.
• For UI changes: I attached a screen recording and/or screenshots above.
• I have added tests (unit / integration / Playwright as applicable) and listed them above.

---

Summary by Gitar

• New Connector Support:
  • Added SapBw4Hana connector support for both database and dashboard services.
  • Created new connection schemas: sapBw4HanaConnection.json for database and sapBw4HanaDashboardConnection.json for dashboard metadata extraction.
• Service Configuration:
  • Registered SapBw4Hana in databaseService.json and dashboardService.json schemas.
  • Added SapBw4HanaQuery as a new dashboardDataModel type.
• Dependencies:
  • Added hdbcli dependency to ingestion/setup.py for the new sap-bw4hana plugin.

_{This will update automatically on new commits.}

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

💡 Edge Case: paginationLimit lacks minimum constraint

paginationLimit is defined as an integer with default 100 but has no minimum constraint. A user could configure 0 or a negative value, which when used to page through BW metadata tables could result in no rows being fetched or an infinite/degenerate pagination loop depending on the connector implementation. Add "minimum": 1 (or a sensible floor) to the schema to prevent invalid configuration values at validation time.

Add a minimum bound to reject non-positive pagination limits.:

"paginationLimit": {
  "title": "Pagination Limit",
  "description": "Number of rows fetched per page when querying BW metadata tables.",
  "type": "integer",
  "minimum": 1,
  "default": 100
}

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Quality: Generated artifacts not propagated (schema-first)

Per the project's schema-first workflow, changes to openmetadata-spec/ must be propagated via make generate so the corresponding generated Java/TypeScript/Python models and UI service-type mappings (e.g. DashboardServiceType/DataModelType enums, SERVICE_TYPE_WITH_DISPLAY_NAME) stay in sync. The PR only contains the spec JSON; the generated code and supporting connector/test-connection files for SapBw4Hana are absent. This is expected for an early draft, but the connector will not be selectable or usable until the generation step is run and the connector implementation/tests are added. Run make generate and include the generated outputs (and connector code + tests) before this leaves draft.

Propagate schema changes to generated artifacts.:

# From the repo root, regenerate models after editing openmetadata-spec/
make generate
# then commit the generated Java/TS/Python sources and add the
# SapBw4Hana connector implementation + test-connection definitions.

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 2 findings

Introduces the SAP BW/4HANA connector with new database and dashboard service schemas. Consider adding a minimum constraint to paginationLimit and ensure generated artifacts are propagated via make generate to complete the schema-first integration.

💡 Edge Case: paginationLimit lacks minimum constraint

📄 openmetadata-spec/src/main/resources/json/schema/entity/services/connections/database/sapBw4HanaConnection.json:51-56 📄 openmetadata-spec/src/main/resources/json/schema/entity/services/connections/dashboard/sapBw4HanaConnection.json:46-51

paginationLimit is defined as an integer with default 100 but has no minimum constraint. A user could configure 0 or a negative value, which when used to page through BW metadata tables could result in no rows being fetched or an infinite/degenerate pagination loop depending on the connector implementation. Add "minimum": 1 (or a sensible floor) to the schema to prevent invalid configuration values at validation time.

Add a minimum bound to reject non-positive pagination limits.

"paginationLimit": {
  "title": "Pagination Limit",
  "description": "Number of rows fetched per page when querying BW metadata tables.",
  "type": "integer",
  "minimum": 1,
  "default": 100
}

💡 Quality: Generated artifacts not propagated (schema-first)

📄 openmetadata-spec/src/main/resources/json/schema/entity/services/databaseService.json:38-39 📄 openmetadata-spec/src/main/resources/json/schema/entity/services/databaseService.json:253-254 📄 openmetadata-spec/src/main/resources/json/schema/entity/services/connections/dashboard/sapBw4HanaConnection.json:1-15

Per the project's schema-first workflow, changes to openmetadata-spec/ must be propagated via make generate so the corresponding generated Java/TypeScript/Python models and UI service-type mappings (e.g. DashboardServiceType/DataModelType enums, SERVICE_TYPE_WITH_DISPLAY_NAME) stay in sync. The PR only contains the spec JSON; the generated code and supporting connector/test-connection files for SapBw4Hana are absent. This is expected for an early draft, but the connector will not be selectable or usable until the generation step is run and the connector implementation/tests are added. Run make generate and include the generated outputs (and connector code + tests) before this leaves draft.

Propagate schema changes to generated artifacts.

# From the repo root, regenerate models after editing openmetadata-spec/
make generate
# then commit the generated Java/TS/Python sources and add the
# SapBw4Hana connector implementation + test-connection definitions.

🤖 Prompt for agents

Code Review: Introduces the SAP BW/4HANA connector with new database and dashboard service schemas. Consider adding a minimum constraint to `paginationLimit` and ensure generated artifacts are propagated via `make generate` to complete the schema-first integration.

1. 💡 Edge Case: paginationLimit lacks minimum constraint
   Files: openmetadata-spec/src/main/resources/json/schema/entity/services/connections/database/sapBw4HanaConnection.json:51-56, openmetadata-spec/src/main/resources/json/schema/entity/services/connections/dashboard/sapBw4HanaConnection.json:46-51

   `paginationLimit` is defined as an integer with default 100 but has no `minimum` constraint. A user could configure 0 or a negative value, which when used to page through BW metadata tables could result in no rows being fetched or an infinite/degenerate pagination loop depending on the connector implementation. Add `"minimum": 1` (or a sensible floor) to the schema to prevent invalid configuration values at validation time.

   Fix (Add a minimum bound to reject non-positive pagination limits.):
   "paginationLimit": {
     "title": "Pagination Limit",
     "description": "Number of rows fetched per page when querying BW metadata tables.",
     "type": "integer",
     "minimum": 1,
     "default": 100
   }

2. 💡 Quality: Generated artifacts not propagated (schema-first)
   Files: openmetadata-spec/src/main/resources/json/schema/entity/services/databaseService.json:38-39, openmetadata-spec/src/main/resources/json/schema/entity/services/databaseService.json:253-254, openmetadata-spec/src/main/resources/json/schema/entity/services/connections/dashboard/sapBw4HanaConnection.json:1-15

   Per the project's schema-first workflow, changes to `openmetadata-spec/` must be propagated via `make generate` so the corresponding generated Java/TypeScript/Python models and UI service-type mappings (e.g. `DashboardServiceType`/`DataModelType` enums, `SERVICE_TYPE_WITH_DISPLAY_NAME`) stay in sync. The PR only contains the spec JSON; the generated code and supporting connector/test-connection files for `SapBw4Hana` are absent. This is expected for an early draft, but the connector will not be selectable or usable until the generation step is run and the connector implementation/tests are added. Run `make generate` and include the generated outputs (and connector code + tests) before this leaves draft.

   Fix (Propagate schema changes to generated artifacts.):
   # From the repo root, regenerate models after editing openmetadata-spec/
   make generate
   # then commit the generated Java/TS/Python sources and add the
   # SapBw4Hana connector implementation + test-connection definitions.

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}