Most SAP Business One integration projects that run into trouble don’t fail because of the technology — Service Layer, DI API, and n8n are all mature and capable. They run into trouble because the integration wasn’t scoped properly before development started. This is the checklist I actually work through before building any SAP B1 integration.
1. Define the direction and trigger of data flow
Is data flowing into SAP B1, out of SAP B1, or both? And what triggers the flow — a real-time event, a scheduled batch, or a manual action? A surprising number of integration requirements arrive vaguely specified (“connect it to our website”) without this being pinned down, and it materially changes the architecture: real-time bidirectional sync is a fundamentally different build to a nightly one-way export.
2. Choose the right SAP B1 API for the constraints
Service Layer for anything platform-independent, cloud-hosted, or built with tools like n8n; DI API only where there’s a specific reason to need it (see the fuller comparison in a separate post on this). Pin this down early — it affects hosting, licensing, and which developers can realistically build it.
3. Map the data model on both sides — properly
Don’t assume a “customer” in the third-party system maps cleanly onto a SAP B1 BusinessPartner, or that a “product” maps directly onto an Item. Differences in required fields, code formats, tax handling, and multi-currency support need to be resolved on paper before any code is written. This is usually where the most time-consuming surprises live.
4. Decide who owns each field
When the same piece of data — a price, a stock quantity, a customer address — can be edited in both systems, define explicitly which system is the source of truth for each field. Without this, bidirectional syncs create quiet, hard-to-diagnose data conflicts within weeks of go-live.
5. Plan for authentication and session management
Service Layer sessions expire and need re-authentication logic. Third-party APIs often have their own token refresh cycles, rate limits, and webhook signature verification requirements. None of this is exciting work, but skipping it produces integrations that work fine in testing and fail intermittently in production.
6. Design explicit error handling, not just the happy path
What happens when SAP B1 rejects a document because of a business rule (credit limit, missing tax code, closed period)? What happens if the third-party system is temporarily unreachable? Does the integration retry, queue, alert a human, or silently drop the transaction? Every one of these needs a deliberate answer, because “it usually works” is not an acceptable failure mode for anything touching financial or inventory data.
7. Handle duplicates and idempotency
If a webhook fires twice, or a scheduled job overlaps with a slow previous run, will the integration create duplicate sales orders or double-post a transaction? Building idempotency checks — using external reference numbers stored in SAP B1 User Defined Fields, for instance — early is far cheaper than untangling duplicate records after go-live.
8. Consider data volume and rate limits from day one
An integration that works cleanly with test data can behave very differently against a live item master of tens of thousands of SKUs, or when a third-party API enforces rate limits. Use Service Layer’s $filter, $select, and paging options deliberately rather than pulling full datasets by default.
9. Plan for monitoring, not just building
Once live, someone needs to know quickly if the integration silently stops working — a failed nightly sync that goes unnoticed for a week causes real damage. Even basic monitoring (a daily summary message, or an alert on consecutive failures) is worth building in from the start rather than added reactively after an incident.
10. Document the mapping and logic for whoever comes next
SAP B1 implementations often outlive the original integration developer’s involvement. A clear record of field mappings, business rules, and known edge cases saves whoever maintains it later — often the business’s own team — from having to reverse-engineer the logic from code.
Takeaway
Nearly all of this checklist is scoping and design work that happens before writing integration code, not during it. The projects that go smoothly are the ones where data ownership, error handling, and API choice were settled on paper first — the build itself is usually the straightforward part.
Leave a Reply