Why now

SAP PO mainstream maintenance ends 2027.

Extended maintenance ends 2030. The default path — a proprietary iPaaS — is deeper lock-in. There is a third option.

  1. 2026today
  2. 2027mainstream maintenance ends
  3. 2030extended maintenance ends (premium)
b.basis.no

BASIS INTEGRATION PLATFORM

Integrations, delivered like modern software.

A managed platform, framework, and runtime contract for customer-owned integrations on dedicated Kubernetes — operated by Basis with an SLA up to the application layer. Your Git, your data, your clusters.

git push→ ci · digest→ catalog PR→ argo cd→ dev · test · prod

Not a multi-tenant SaaS — every customer gets dedicated dev, test & prod.

b.PLATFORM · FRAMEWORK · CONTRACT

One product. Three parts.

What Vercel did for frontend teams, Basis does for integration teams — with one critical difference: the trust model stays customer-oriented. Your Git, your registry, your secrets, your clusters, your code.

Platform

“Dedicated, managed, observable.”

Dedicated dev, test, and prod environments on a managed Kubernetes foundation. GitOps delivery, registry, secrets, and observability included — operated by Basis with an SLA.

Framework

“From scaffold to production in days.”

Golden-path templates with CI built in. Apache Camel on Quarkus first — 300+ connectors for everything from SAP IDocs to REST, files, and Kafka. .NET next. Always real code.

Contract

“Portability is the product.”

Every integration speaks the same operational language — admin, health, metrics, logs — whatever the runtime. Your code lives in your Git. If you ever want to leave, you can. That’s the point.

b.OWNERSHIP & TRUST

What’s yours stays yours.

Basis runs sovereign managed infrastructure and has operated SAP environments for 25+ years (est. 1999). Same company, same trust model, modern platform.

Yours

  • Integration code, in your Git — GitHub Cloud, GitHub Enterprise, or Basis-hosted Gitea
  • Data and message payloads — they stay in your dedicated environments
  • Secrets backend — Azure Key Vault, HashiCorp Vault, OpenBao, cloud secret managers
  • Image registry content — dedicated Harbor, nonprod/prod trust zones
  • The integrations themselves — portable via the runtime contract

Managed by Basis

  • Platform baseline: Kubernetes, Argo CD, Traefik, Harbor, observability stack
  • Upgrades, patching, monitoring, alerting
  • SLA up to the application layer
  • Platform support + integration consulting
  • Golden-path templates, CI workflows, catalog tooling
b.HOW IT WORKS

From git push to production, by pull request.

Promotion isn’t a deploy button — it’s a reviewed Git change. The cluster converges on what’s merged.

Push real code

Plain code — Apache Camel on Quarkus today, .NET next — in your own Git. A push starts the pipeline.

$ git push origin main

CI builds + scans an immutable digest

CI builds, tests, and scans an immutable image digest — the exact digest that passed test is what runs in prod.

✓ scan passed · sha256:9f3a…e7c1Prod never rebuilds.

Promotion is a catalog PR

Promotion is a Git change, reviewed as a pull request. Approvals run through PR review and CODEOWNERS — auditable by design.

catalog PR #42 · approvedPromotion is a Git change.

Argo CD pulls desired state

Argo CD pulls the merged state into your cluster, and it converges. Day-2 ops live in the dashboard — start/stop, promote, resend — direct, but always logged.

argocd · Synced → HealthyDesired state, not ssh.
b.ARCHITECTURE · WHERE THE CODE LIVES
Git repository structure — Basis platform repos seeded into the customer's own Git; app-repo CI updates the catalog
b.ARCHITECTURE · THE CUSTOMER TENANT
Customer tenant — dedicated management, dev, test and prod clusters with Argo CD per cluster; customer Git, CI runners and Harbor outside
b.MESSAGE STORE & RESEND · NEW

Every message, accounted for.

One toggle in the dashboard — the platform provisions the rest. Messages are stored durably, failures become visible, and a failed message can be resent. The same way on every runtime.

  • Durable by default. Every message is journaled as it flows — received, each attempt, each processing step.
  • Failures surface, they don’t disappear. After retries, a message parks in the platform DLQ and shows up in the dashboard with its full history.
  • Resend is a button, not a war room. Audited resend and replay from the dashboard — down to redoing a single step.
  • Identical on every runtime. Camel on Quarkus or .NET: one contract, one behaviour, one dashboard.
Message store durable journal, DLQ & resend for this integration
  • the platform provisions
  • +Kafka input topicbip.order-to-partner.in
  • +Postgres journalbip_message_log · attempts · steps
  • +Shared platform DLQbip.message.dlq
  • +Dashboard tracking & resenddev · test · prod
b.MESSAGE STORE · UNDER THE HOOD

One adapter in front of your code.

A versioned runtime adapter — a normal Maven / NuGet dependency — owns consumption, retry, journaling and DLQ. Your integration stays plain business code.

Source systemSAP · SFTP · REST · …
→
bip.order-to-partner.indurable Kafka input topic
→
RUNTIME ADAPTER · CAMEL / .NET
your integration route plain Camel / .NET code — zero platform plumbing
→
Target systemIdempotency-Key injected
bip_message_log · _attempt · _step_outcome durable Postgres journal — the dashboard’s source of truth, incl. a replay audit trail
bip.message.dlq parked with the original payload + error headers
Dashboard tracking, search, resend — across dev · test · prod
honest semantics

Controlled at-least-once, with platform-managed step de-duplication — we never claim exactly-once. For external side effects the adapter injects an Idempotency-Key so your endpoints can de-duplicate too.

b.MESSAGE STORE · WHEN A MESSAGE FAILS

See it. Inspect it. Resend it.

Dashboard — message monitoring with full history and audited resend
1

The failure is visible

Retries exhausted → the message parks in the DLQ, full history in the journal.

2

Inspect in the dashboard

Payload, every attempt, every step outcome — no kubectl, no log spelunking.

3

Resend — or redo one step

One click resends; x-bip-redo-steps re-runs only the steps you choose.

4

Delivered via the cluster agent

Dashboard → command queue → per-cluster agent → adapter. Outbound-only — no inbound access to your cluster.

5

Every replay is audited

Who, when, what — recorded in bip_message_replay_audit.

Direct, but always logged.
b.MESSAGE STORE · ONE CONTRACT, EVERY RUNTIME

Certified, not promised.

The behaviour isn’t a convention — it’s a versioned contract with a certification suite both runtimes must pass. That’s what guarantees “the same on every runtime”.

the contract · versioned like software
spec
normative message-store contract, v1
schemas
JSON Schemas + OpenAPI for every surface
sql
canonical journal schema (bip_*)
certification
22 scenarios every runtime must pass
camel · quarkusMaven package
.netNuGet package

released into your registry — pinned per customer, checksum-verified. Your CI never touches Basis infrastructure.

Certification matrix

S1 – S22 · consume · retry · DLQ · journal · resend · redo · audit
camel · quarkus
.net

both adapters pass all 22 scenarios — validated end-to-end on a live demo integration

ROADMAP

Platform-side capture at the Kafka boundary — a message shows as RECEIVED even if the workload is down. The journal won’t depend on the app calling an SDK.

b.WHAT WE'VE BUILT SO FAR

Not a concept — a platform that runs today

  • The platform runs
    dedicated dev · test · prod, managed across every environment
  • GitOps delivery, end-to-end
    git push → CI build & scan → catalog PR → Argo CD — validated
  • One operations dashboard
    estate health, message flow, and failures across DEV · TEST · PROD
  • Catalog as code
    create, pin, and promote integrations as reviewed Git changes
  • Message store & resend
    durable journal, DLQ, audited resend — certified on both runtimes
Overview — operational posture across all environments

Press → to step through the rest — full screen

b.WHERE THIS GOES
25+years of managed SAP & IT operations
0license fees on the open-source core
100%of integration code in your Git

We know what we’re replacing — and we run what we sell.

Let’s put your own flows on it.

  1. 01Pick 2–3 of your current SAP PO interfaces
  2. 02We stand them up in a dedicated dev environment
  3. 03You see your own integrations on the platform — live
  4. 04Then we scope the bigger move together
basis.no
BASIS INTEGRATION PLATFORM
01 / 13