InCube · Implementation Engineer → Technical Lead · 2020–2025
20+ ERP integrations, and the toolkit that made them repeatable
Connected client ERPs, from SAP to Odoo, with InCube's sales, warehouse and CRM platforms, and turned every connector into a reusable tool so each new client went faster than the last.
20+
client integrations delivered
7
ERP and logistics platforms integrated
100%
automated syncs, no manual re-entry
- team
- Implementation engineers; I led the technical side
- what i owned
- Integration architecture and methodology, and every technical integration decision once I became tech lead
- timeline
- 2020–2025
- .NET
- C#
- Node.js
- T-SQL
- SQL Server
- REST APIs
- SAP RFC
- Windows services
how it fits together
01
Client ERPs
SAP, Oracle JD Edwards, Microsoft Dynamics, Odoo
02 · built this
Integration layer
REST, SAP RFC, linked servers, stored procedures, middleware
03
InCube platform
Sales-force automation, warehouse and CRM
04
Field teams and dashboards
Orders, stock, invoices and reports
Problem
InCube sells sales-force-automation, warehouse and CRM solutions to distributors across Saudi Arabia and the region. Every client already ran its own ERP, and every ERP spoke a different language. Without reliable integration, orders, invoices, stock, customers and prices had to be moved by hand, which was slow and full of errors.
Constraints
- A different ERP for almost every client: SAP, Oracle JD Edwards, Microsoft Dynamics 365 and GP, Odoo, plus logistics systems like Manhattan.
- Each one integrates differently: some through APIs, some only at the database level, some only by file exchange.
- Integrations had to run on their own, day after day, without anyone watching them.
What I built
- SAP: integrations over REST APIs, plus an application that calls SAP’s RFC functions directly. It’s still in use at a multinational energy company.
- Oracle JD Edwards: a SQL Server linked server to the Oracle database, with stored procedures that keep both sides in sync.
- Microsoft Dynamics 365 and GP: stored procedures and Windows services that run timed syncs.
- Odoo: a middleware service that syncs data with Odoo.
- Manhattan: batch file processing.
- Roadnet (route optimization): my own middleware, so other developers could integrate with it easily.
Everything was built to be reused: each connector, tool and script works for the next client, not just the first.
The hardest one
SAP’s RFC interface was a completely new concept to me. I sat with the client’s SAP consultants to understand how their system worked, then went through many rounds of testing until the integration ran smoothly. It’s still running today.
Leading the technical side
As Technical Lead I took over every integration decision: the methodology, and how we approached each client’s requirements technically. The implementation engineers stayed the same team; I led how we built.
Result
More than 20 client integrations, all running as fully automated syncs. Each new client could start from a proven toolkit instead of a blank page.
Key decisions
Meet every ERP on its own terms
Rather than forcing one pattern, each integration used what the ERP did best: REST and RFC calls for SAP, a linked server for Oracle, timed services for Microsoft Dynamics, a middleware service for Odoo and batch files for Manhattan.
Build it once, reuse it everywhere
Every connector, tool and script was built to be reused for the next client, so integrations became a toolkit rather than one-off projects.
before
- Orders, stock and customer data re-entered by hand between systems
- Every new client integration started from scratch
after
- Fully automated syncs between each client's ERP and the platform
- A reusable toolkit of connectors for each major ERP
Client names are withheld to respect confidentiality.
Got something that needs to move?
Hiring, collaborating, or just curious, I'd love to hear from you.