Skip to main content
Banking OS connectors are vendor-agnostic Camel K integrations packaged as Quarkus apps and Helm charts. Building one means setting up the project, laying out the route anatomy, calling REST endpoints through the standard kamelet, applying Enterprise Integration Patterns (EIPs), mapping requests and responses, configuring runtime properties, and testing locally and on a cluster. If you don’t have GitHub access to the source repositories, every compiled artifact is available from the JFrog repository at Banking OS artifacts on JFrog. This includes the BOM, SDK, kamelets, API specs, and Maven plugins.

​
How the pieces fit

If you haven’t worked with Apache Camel and Maven before, start here. A connector repository holds your inputs, Maven turns them into build outputs, and the applications-live repository deploys those outputs. The following diagram shows the flow: The following terms describe the pieces:
  • Apache Camel: The integration framework. Routes describe the steps of each operation. For more information, see Anatomy of a connector.
  • Camel K and Quarkus: The runtime that runs your routes on Kubernetes.
  • Kamelet: A reusable Camel building block, such as gc-http-caller. For more information, see Kamelets.
  • Maven: Builds the project, pulls dependencies, generates the Camel REST DSL from the OpenAPI spec, and packages the container image and Helm chart. When you release the repository, CI pushes both to your installation’s Azure Container Registry.
  • BOM: The grandcentral-bom parent POM. It pins versions of Camel, Quarkus, the SDK, Kamelets, and plugins. For more information, see BOM (bill of materials) and Reference artifacts and rules.
  • JOLT and XSLT: Transformation templates for JSON and XML payloads. For more information, see Transform and validate data.

​
Build path

Code standards

Coding standards and best practices to apply across all connectors

Set up the project

Naming conventions, project layout, prerequisites, connector styles, and first-time configuration

Anatomy of a connector

The route skeleton and operation patterns for REST/JSON, SOAP/XML, and event connectors

Kamelets

What a Kamelet is and how to create one for a connector

Call REST endpoints

Use the gc-http-caller kamelet for every outbound REST call

Use Camel EIPs

Common Enterprise Integration Patterns: choice, multicast, splitter, doTry, and more

Transform and validate data

JSON Schema validation, JOLT and XSLT transformations, and helper bean calls

Configure properties

Common application.properties values for Camel, HTTP, CXF, retries, and headers

Configure a custom connector

Helm and SOPS configuration that takes effect at deploy time

Test and validate

Run the connector locally, deploy with kamel:dev, and write SDK-based unit tests

Reference artifacts and rules

Maven artifacts published to JFrog and the rules and anti-patterns to follow
The connector template is the reference implementation (the golden sample). If something doesn’t work, compare your repository with the template first.

​
Connector styles

Three connector styles exist — REST/JSON, SOAP/XML, and Event/Generic — and the vendor’s integration type determines which to use. Each style pairs a transformation format (JOLT or XSLT) with the appropriate HTTP kamelet. For the full comparison and the exact kamelet to use for each style, see Connector styles in Set up the project.

​
Technology stack

Build custom connectors with the following stack:
  • Apache Camel K: integration framework for Kubernetes
  • Quarkus: runtime
  • Maven: build and dependency management
  • Java: primary development language
  • GitHub Actions: continuous integration and deployment