• Er. GSK

    • Home
    • Projects
    • About
    • Resume
    • Contact
Projects
H

Hero Ecotech

B2B
live

SAP-integrated B2B field-sales ordering app and backend.

Backend + app engineer2025 – 2026Core of a small teamAuribises TechnologiesEnterprise / ERP integration
heroecotech.inkrossbikes.in
My role at AuribisesClient product. Source is private.
On this page
  • Overview
  • Tech stack
  • Responsibilities
  • How it works
  • Challenges
  • Reflections

Overview

A field-sales ordering app for B2B staff that talks to the customer's SAP ERP through a custom TypeScript backend. I built the backend integration and the Flutter app.


Tech stack

Flutter
TypeScript
Express 5
Firebase
Algolia
SAP
The skills behind this

Responsibilities

  • Enabled B2B field staff to place orders directly into the customer's SAP ERP by building the TypeScript and Express integration backend, resolving a TLS hostname mismatch and SAP's two-step authenticated ordering process that off-the-shelf clients cannot complete.
  • Delivered the Flutter field-sales application from design through to release.
  • Kept field staff working against current pricing and stock by engineering the price-synchronisation pipeline and the Algolia search index.
  • Protected order accuracy under concurrent use through transaction-safe order numbering and an immutable order history.
  • Ensured large daily data loads completed reliably by making the bulk SAP synchronisations fault-tolerant: batched, self-healing, and isolating failed records with an audit trail.

I built the Flutter app and the backend's SAP integration, price-sync pipeline, and Algolia sync. A teammate set up the initial SAP data import.


How it works

1

Field-sales app

Flutter, staff place orders

2

TypeScript backend

Express, mediates every call

3

SAP ERP

Orders in, master data out

4

Firestore + Algolia

Synced data, fast search

The app only ever talks to my backend. The backend speaks SAP's language on one side and keeps Firestore and Algolia in step on the other.

Engineering challenges

01Talking to a legacy SAP system that wasn't built for this

Problem. Orders, customers, products and prices all live in the customer's SAP system, and SAP doesn't make itself easy to reach. It sat on a private IP but answered with a certificate for a hostname, so a normal HTTPS call just failed the check. Placing a sales order wasn't a simple POST either; SAP wanted a token handshake first.

Approach. For the TLS mismatch I told the request to use the right hostname for the certificate while still connecting to the IP, with the option of a proper CA cert and a dev-only switch that warns loudly if anyone turns the safety off. For orders I followed SAP's two-step flow: fetch the token, then send the order, and I pulled SAP's real response back out so the app could tell a genuine rejection apart from a dropped connection.

Outcome. The app could place real orders into SAP and stay in step with SAP's data over a connection an off-the-shelf HTTP client refuses to make.

02Keeping orders correct when several people order at once

Problem. Multiple staff place orders at the same time, so order numbers could clash. And an order's printed record could quietly change later if someone edited or removed the customer it pointed at.

Approach. Order numbers are handed out inside a Firestore transaction, so two orders can't grab the same one. Instead of pointing an order at a live customer record, I copy the customer details onto the order when it's created, so the history stays exactly as it was no matter what changes later. On the app side the order code is honest about failure, telling a network drop apart from the server saying no.

Outcome. No duplicate order numbers under load, order history that doesn't rewrite itself, and error messages that actually mean something.

03Moving large SAP data sets without falling over

Problem. Daily syncs pull big sets of customers, products and prices into Firestore and Algolia. Done naively, one oversized payload or one bad record would take the whole run down.

Approach. I raised the request limit for the bulk loads and processed them in batches that keep going even when a record fails, keeping the failed ones in an audit trail to look at later. The price sync runs as a series of named stages, so if it breaks the error says which stage and I'm not guessing. Product variants get a composite id so they map cleanly, and I tuned the batch size by watching it run rather than guessing.

Outcome. Syncs finish even when a few records are bad, failures are isolated and recorded, and a broken run points straight at its cause.


What I'd do differently

  • The SAP integration is the one place I'd invest in an automated test suite first. That fiddly, edge-case protocol code is where regressions hide, and right now I lean on careful manual checks.
  • The early TLS workaround on the app side was a stopgap. I documented it and removed it once the real certificate was fixed, but I'd reach for the proper fix first next time.

Interested in this kind of work? Get in touch


More projects

View all

Mentcape

Therapy and coaching SaaS, my step up from junior to senior.

Finlo

Multi-tenant parking and transport SaaS with a stats engine.

SUT1 Replay Server

Real-time telemetry decoder (Swinburne capstone, HD 90/100).

APK Guardian

ML-based Android malware detection, full-stack.

On this page

  • Overview
  • Tech stack
  • Responsibilities
  • How it works
  • Challenges
  • Reflections