FreedomDev
TeamAssessmentThe Systems Edge616-737-6350
FreedomDev Logo

Your Dedicated Dev Partner. Zero Hiring Risk. No Agency Contracts.

201 W Washington Ave, Ste. 210

Zeeland MI

616-737-6350

[email protected]

FacebookLinkedIn

Company

  • About Us
  • Culture
  • Our Team
  • Careers
  • Portfolio
  • Technologies
  • Contact

Core Services

  • All Services
  • Custom Software Development
  • Systems Integration
  • SQL Consulting
  • Database Services
  • Software Migrations
  • Performance Optimization

Specialized

  • QuickBooks Integration
  • ERP Development
  • Mobile App Development
  • Business Intelligence / Power BI
  • Business Consulting
  • AI Chatbots

Resources

  • Assessment
  • Blog
  • Resources
  • Testimonials
  • FAQ
  • The Systems Edge ↗

Solutions

  • Data Migration
  • Legacy Modernization
  • API Integration
  • Cloud Migration
  • Workflow Automation
  • Inventory Management
  • CRM Integration
  • Customer Portals
  • Reporting Dashboards
  • View All Solutions

Industries

  • Manufacturing
  • Automotive Manufacturing
  • Food Manufacturing
  • Healthcare
  • Logistics & Distribution
  • Construction
  • Financial Services
  • Retail & E-Commerce
  • View All Industries

Technologies

  • React
  • Node.js
  • .NET / C#
  • TypeScript
  • Python
  • SQL Server
  • PostgreSQL
  • Power BI
  • View All Technologies

Case Studies

  • Innotec ERP Migration
  • Great Lakes Fleet
  • Lakeshore QuickBooks
  • West MI Warehouse
  • View All Case Studies

Locations

  • Michigan
  • Ohio
  • Indiana
  • Illinois
  • View All Locations

Affiliations

  • FreedomDev is an InnoGroup Company
  • Located in the historic Colonial Clock Building
  • Proudly serving Innotec Corp. globally

Certifications

Proud member of the Michigan West Coast Chamber of Commerce

Gov. Contractor Codes

NAICS: 541511 (Custom Computer Programming)CAGE CODE: oYVQ9UEI: QS1AEB2PGF73
Download Capabilities Statement

© 2026 FreedomDev Sensible Software. All rights reserved.

HTML SitemapPrivacy & Cookies PolicyPortal
  1. Home
  2. /
  3. Solutions
  4. /
  5. SAP Custom API Integration: BAPI, RFC & OData for Mid-Market
Solution

SAP Custom API Integration: BAPI, RFC & OData for Mid-Market

Custom SAP integration development — BAPIs, RFC function modules, OData services, IDocs, and SAP Integration Suite — from a Zeeland, MI company that connects SAP ECC and S/4HANA to your external systems without forcing you into SAP's six-figure connector licensing.

FD
20+ Years SAP Integration
BAPI / RFC / OData / IDoc
No Additional SAP Licensing
Zeeland, MI

The SAP Integration Tax: Why Mid-Market Companies Pay Enterprise Prices for Basic Connectivity

SAP sells integration the same way it sells everything else: as a licensing event. Need to connect your SAP ECC system to your e-commerce platform? That will be SAP Process Integration at $150,000+ in license fees before a single line of configuration is written. Need real-time inventory visibility between SAP and your warehouse management system? SAP Integration Suite starts at $50,000 per year in subscription costs, requires SAP BTP (Business Technology Platform) credits on top, and assumes you have an SAP Basis team on staff to manage it. For a company doing $20M-$100M in revenue with 50-500 employees, these licensing costs represent an absurd proportion of IT budget — often exceeding the cost of the integration development itself by 3-5x.

The result is predictable: mid-market SAP customers end up with disconnected systems. The ERP handles financials, materials management, and production planning, but everything else — CRM, e-commerce, WMS, quality management, customer portals, business intelligence — operates on a separate island. Data moves between SAP and external systems through CSV exports, manual re-keying, or a tangle of flat-file IDocs that someone configured in 2014 and nobody has touched since because the consultant who built them left the country. Finance closes the books five days late because the revenue recognition data in SAP does not match the order data in Shopify. Purchasing creates duplicate vendor records because the supplier portal has no connection to SAP's MM module. The warehouse ships against yesterday's production schedule because the WMS polls SAP via a batch job that runs at midnight.

SAP's own integration tools are powerful, but they are built for Global 2000 companies with dedicated SAP Basis teams, integration architects, and six-figure annual maintenance budgets. SAP PI/PO (Process Integration/Process Orchestration) requires its own ABAP stack and Java stack, its own hardware or cloud instance, its own monitoring, and its own specialized consultants at $200-$300 per hour. SAP CPI (Cloud Platform Integration, now part of Integration Suite) is simpler but still requires BTP licensing, iFlow development expertise, and ongoing subscription costs that compound every year. For a mid-market company that needs five or six integration points between SAP and external systems, these platforms are architectural overkill — equivalent to buying a commercial aircraft when you need a pickup truck.

There is a third option that SAP's sales team will never mention: building custom integrations directly against SAP's native interfaces. Every SAP system — ECC, S/4HANA, Business One — exposes integration points through BAPIs (Business Application Programming Interfaces), RFC (Remote Function Call) modules, OData services, IDocs (Intermediate Documents), and in S/4HANA, RESTful ABAP Programming (RAP) APIs. These interfaces exist in your system right now, fully licensed, requiring zero additional SAP software purchases. The barrier is not licensing — it is expertise. You need developers who understand both SAP's internal data model and modern integration patterns, and that combination is genuinely rare.

SAP PI/PO or Integration Suite licensing costs $50K-$150K+ before any development begins — often exceeding the integration build cost itself

Manual data transfer between SAP and external systems: CSV exports, re-keying, batch IDocs running on overnight schedules

Finance closes books 3-5 days late because revenue, cost, and inventory data must be manually reconciled across systems

No real-time inventory visibility: warehouse, e-commerce, and SAP MM module show different stock levels at any given moment

Duplicate master data (vendors, customers, materials) across SAP and external systems because there is no synchronization layer

Legacy IDoc interfaces configured years ago by a consultant who is no longer available — nobody understands the mappings or dares to modify them

SAP Basis team is 1-2 people (or outsourced) and cannot absorb the overhead of managing PI/PO or Integration Suite infrastructure

S/4HANA migration planning stalled because current integrations are built on deprecated SAP interfaces with no documented migration path

Need Help Implementing This Solution?

Our engineers have built this exact solution for other businesses. Let's discuss your requirements.

  • Proven implementation methodology
  • Experienced team — no learning on your dime
  • Clear timeline and transparent pricing

SAP Integration ROI: What Changes When Your ERP Actually Talks to Your Other Systems

$50K-$150K
SAP middleware licensing costs avoided per implementation
Real-time
Data sync replacing overnight batch IDocs and CSV exports
3-5 days
Faster month-end close from automated SAP-to-GL reconciliation
95%+
Reduction in duplicate master data records across systems
Zero
Additional SAP licenses required for BAPI/RFC/OData integration
4-10 weeks
Typical delivery for 3-5 SAP integration points

Facing this exact problem?

We can map out a transition plan tailored to your workflows.

The Transformation

Direct SAP Integration: BAPIs, RFCs, OData, and IDocs Without the Middleware Tax

FreedomDev builds custom integrations that connect SAP ECC and S/4HANA to your external systems using SAP's native interfaces — no SAP PI/PO, no Integration Suite, no BTP subscription required. We write code that talks directly to your SAP system through the same interfaces that SAP's own middleware uses, but wrapped in modern, maintainable integration services that your existing IT team can monitor and support. The approach is straightforward: identify the SAP business objects and transactions your integration needs to read or write, select the appropriate interface (BAPI, RFC, OData, IDoc, or RAP API), build a middleware service that handles authentication, data transformation, error handling, and retry logic, and deploy it on infrastructure you already own or can provision for $50-$200 per month.

For SAP ECC systems, BAPIs and RFC function modules are the workhorses. A BAPI is a standardized function module with a defined interface that SAP guarantees will remain stable across releases — it is the closest thing SAP has to a public API. There are over 5,000 BAPIs in a standard ECC installation covering every business process: BAPI_SALESORDER_CREATEFROMDAT2 for creating sales orders, BAPI_MATERIAL_GETLIST for querying material master data, BAPI_CUSTOMER_GETDETAIL2 for reading customer records, BAPI_ACC_DOCUMENT_POST for posting financial documents. RFC function modules extend beyond BAPIs to include custom Z-modules that your ABAP developers may have already built. We connect to these using the SAP NetWeaver RFC SDK or the SAP Java Connector (JCo), wrapping them in REST APIs that any modern system can consume.

For S/4HANA, OData services are the primary integration interface. SAP has published over 600 standard OData APIs in S/4HANA that cover sales, purchasing, production, finance, warehouse management, and master data. These are true RESTful services — they accept JSON payloads, support CRUD operations, implement OData query parameters ($filter, $select, $expand, $orderby), and authenticate via OAuth 2.0 or SAP's communication arrangements. If a standard OData service does not cover your use case, we build custom OData services using S/4HANA's RAP (RESTful ABAP Programming) model or CDS (Core Data Services) views with OData exposure annotations. The result is a clean API that feels like any other REST service, except it reads from and writes to SAP's database through SAP's application layer with full transaction integrity.

IDocs (Intermediate Documents) remain the right choice for specific scenarios: EDI transactions with trading partners, asynchronous batch processing where guaranteed delivery matters more than real-time response, and integration with older external systems that already speak IDoc. We configure IDoc message types, set up partner profiles, build custom IDoc segments when standard ones do not fit, and create inbound/outbound processing logic in ABAP. But unlike a decade ago when IDocs were the only viable integration option, we now treat them as one tool in a toolkit — not the default. For most real-time integration needs in 2025 and beyond, BAPIs, RFCs, and OData services deliver faster, with less overhead, and with significantly easier troubleshooting than IDoc processing chains.

BAPI & RFC Integration (SAP ECC)

We connect external systems to SAP ECC using the 5,000+ standard BAPIs and RFC function modules that already exist in your system. Sales order creation, material master lookups, vendor management, financial postings, inventory movements, production order management — all accessible through RFC connections without any additional SAP licensing. We build middleware services using the SAP JCo (Java Connector) or PyRFC (Python) libraries that wrap these calls in modern REST endpoints your other systems can consume.

OData & RAP API Integration (S/4HANA)

S/4HANA exposes 600+ standard OData APIs covering every major business process. We consume these directly from your external systems or build custom OData services using CDS views and RAP when the standard APIs do not cover your requirements. Full support for OData V2 and V4, batch operations ($batch), deep inserts, navigation properties, and server-side filtering. Authentication via OAuth 2.0 client credentials, SAML bearer assertions, or communication arrangements.

IDoc Configuration & Custom Segment Development

For EDI, batch processing, and guaranteed-delivery scenarios, we configure IDoc interfaces end-to-end: message types, segments (standard and custom Z-segments), partner profiles, ports, process codes, and inbound/outbound ABAP processing logic. We migrate legacy ALE/IDoc setups to current standards, document the undocumented, and build monitoring so you actually know when an IDoc fails instead of discovering it three weeks later during month-end close.

SAP-to-E-Commerce Real-Time Sync

Real-time bidirectional integration between SAP (ECC or S/4HANA) and Shopify, Magento, WooCommerce, BigCommerce, or custom e-commerce platforms. Orders flow into SAP as sales orders within seconds of placement. Inventory availability updates from SAP MM/WM to the storefront in real-time. Pricing, customer-specific discounts, and ATP (Available-to-Promise) checks execute against SAP data so your e-commerce storefront always shows accurate information.

SAP-to-WMS/3PL Integration

Connecting SAP's inventory management (MM/WM/EWM) to external warehouse management systems or third-party logistics providers. Goods receipts, transfer orders, pick/pack/ship confirmations, ASNs (Advance Shipping Notices), and inventory adjustments flow bidirectionally between SAP and your warehouse system. We handle unit-of-measure conversions, batch/serial number synchronization, and the notorious SAP storage location and plant mapping that breaks most generic integration attempts.

SAP Master Data Synchronization

Customer master, vendor master, material master, BOM (Bill of Materials), and pricing condition records synchronized between SAP and your CRM, supplier portal, product information management (PIM) system, or business intelligence platform. We build conflict resolution logic for bidirectional sync scenarios, handle SAP's multi-level master data structures (customer hierarchies, material classifications, condition record layering), and implement change detection so only modified records trigger synchronization events.

Want a Custom Implementation Plan?

We'll map your requirements to a concrete plan with phases, milestones, and a realistic budget.

  • Detailed scope document you can share with stakeholders
  • Phased approach — start small, scale as you see results
  • No surprises — fixed-price or transparent hourly
“
We were quoted $180,000 for SAP PI/PO licensing plus another $120,000 in consulting to connect SAP to our Shopify store and WMS. FreedomDev built direct BAPI integrations for a fraction of that cost. Orders flow from Shopify into SAP in under 10 seconds, inventory syncs in real-time, and we did not have to buy a single additional SAP license.
VP of Operations—Michigan Manufacturing & Distribution Company (SAP ECC 6.0 EHP7)

Our Process

01

SAP System Assessment & Interface Inventory (1-2 Weeks)

We log into your SAP system and inventory every available integration interface: existing BAPIs and RFC function modules (standard and custom Z-modules), OData services (for S/4HANA), configured IDoc message types, RFC destinations, and any existing PI/PO or CPI iFlows. We map which business processes need integration, which SAP transactions and tables are involved, what data needs to move in which direction, and at what frequency. We also assess your SAP authorization model because integration users need specific RFC and BAPI authorization objects (S_RFC, B_BAPI_METH, S_SERVICE for OData) — getting this wrong is the number one reason SAP integration projects stall. Deliverable: a technical integration blueprint with specific BAPI/RFC/OData endpoints per use case, authorization requirements, estimated data volumes, and a prioritized build sequence.

02

Interface Selection & Data Mapping (1-2 Weeks)

For each integration point, we select the optimal SAP interface. This is not a generic decision — it depends on the specific business object, the direction of data flow, real-time versus batch requirements, and what your SAP system version actually supports. A sales order creation will use BAPI_SALESORDER_CREATEFROMDAT2 on ECC or the A_SalesOrder OData service on S/4HANA. An inventory check might use BAPI_MATERIAL_AVAILABILITY or a custom CDS view depending on whether you need ATP (Available-to-Promise) logic or simple stock levels. We then map every field between SAP and the external system, including data type conversions (SAP's DATS format to ISO 8601, CURR fields with implied decimals, NUMC fields, LANG codes), value mappings (SAP plant codes to WMS location IDs, SAP customer numbers to CRM account IDs), and transformation logic for fields that do not have a one-to-one correspondence.

03

Middleware Development & ABAP Enhancements (3-8 Weeks)

We build the integration middleware — a lightweight service layer that sits between SAP and your external systems. This is typically a Node.js, Python, or Java application deployed on your existing infrastructure, a cloud VM, or a container platform. The middleware handles SAP connection pooling (RFC connections are expensive to establish and must be managed carefully), authentication and session management, request queuing for high-volume scenarios, data transformation between SAP's formats and modern JSON/REST conventions, error handling with automatic retry for transient failures, and dead-letter queuing for transactions that need manual review. When standard BAPIs or OData services do not cover a use case, we develop ABAP enhancements inside SAP: custom function modules wrapped as RFCs, CDS views with OData exposure, BAdI implementations for event-driven outbound integration, or custom IDoc segments and processing logic. All ABAP development follows SAP's naming conventions (Z/Y namespace), includes unit tests, and is transport-ready for your QA-to-production promotion process.

04

Integration Testing in SAP Sandbox/QA (2-3 Weeks)

Every integration is tested against your SAP QA or sandbox system before touching production. We run through the full transaction lifecycle for each integration point: create, read, update, and where applicable, reverse or cancel. We test with realistic data volumes — not five test records, but thousands — because SAP BAPIs and OData services behave differently under load (connection pool exhaustion, RFC timeout handling, OData pagination with $skip/$top, IDoc queue bottlenecks). We simulate failure scenarios: what happens when SAP is down for a kernel update, when an RFC connection drops mid-transaction, when an OData service returns a 503 because the ICM (Internet Communication Manager) is overloaded, when an IDoc gets stuck in status 51 (application error). Every failure scenario has a documented recovery path. We validate SAP authorizations by testing with the actual integration user's profile, not with SAP_ALL — authorization failures in production are the most common go-live blocker for SAP integrations.

05

Production Deployment, Monitoring & SAP Transport (1-2 Weeks)

We deploy the middleware service to your production infrastructure and promote all ABAP transports through your SAP landscape (DEV to QA to PRD). We configure monitoring that covers both sides of the integration: middleware health checks, SAP RFC connection status, OData service response times, IDoc processing status, and business-level metrics (orders processed per hour, master data sync lag time, failed transaction count). For SAP-specific monitoring, we set up SM58 (transactional RFC monitoring), WE05 (IDoc monitoring), BD87 (ALE monitoring), and /IWFND/ERROR_LOG (OData error log) alerts that notify your team when something needs attention. We run in parallel with existing manual processes for 1-2 weeks, comparing automated output against manual output transaction by transaction. Ongoing maintenance covers SAP Support Pack and Enhancement Pack impact analysis, OData service deprecation monitoring, BAPI interface changes in SAP Notes, and middleware service patching.

Before vs After

MetricWith FreedomDevWithout
Licensing Cost$0 additional SAP licensing (uses existing BAPIs/RFCs/OData)SAP PI/PO: $150K+ license; Integration Suite: $50K+/yr subscription
Infrastructure RequirementsSingle VM or container ($50-$200/mo)SAP PI/PO: dedicated ABAP+Java stack; CPI: BTP credits + iFlow runtime
Required ExpertiseSAP functional + modern dev (we provide both)SAP Basis admin + PI/PO developer + ongoing SAP platform management
Time to First Integration4-6 weeks including testingSAP PI/PO: 3-6 months (platform setup + development); CPI: 2-4 months
Ongoing Cost (5 integrations)$1K-$3K/mo middleware hosting + maintenanceSAP Integration Suite: $50K+/yr + consultant hours for iFlow changes
S/4HANA Migration PathOData/RAP APIs are S/4HANA native — already future-proofedPI/PO is deprecated; must migrate to Integration Suite (another project)
Legacy ECC SupportFull BAPI/RFC/IDoc support on ECC 6.0 EHP0 through EHP8Integration Suite pushes toward S/4HANA; ECC support is maintenance-mode
TroubleshootingStandard HTTP debugging + SAP transaction logs (SM58, WE05, ST22)PI/PO: SXMB_MONI message monitoring; CPI: cloud-based iFlow trace logging

Ready to Solve This?

Schedule a direct technical consultation with our senior architects.

Explore More

ERP ImplementationAPI IntegrationLegacy ModernizationManufacturingDistributionLogisticsRetail

Frequently Asked Questions

Do we need additional SAP licenses to build custom BAPI or RFC integrations?
No. BAPIs, RFC function modules, and OData services are part of your existing SAP installation. They ship with every SAP ECC and S/4HANA system and are covered under your current SAP runtime license. You do not need SAP PI/PO, SAP Integration Suite, SAP BTP, or any additional SAP software to use them. What you need is an RFC-enabled system user with the appropriate authorization objects (S_RFC for RFC access, B_BAPI_METH for BAPI execution, S_SERVICE for OData services in S/4HANA), and an external middleware service that makes the RFC or HTTP calls. The middleware runs on your infrastructure — a Linux VM, a Docker container, a Kubernetes pod — using open-source SAP connector libraries (SAP JCo for Java, PyRFC for Python, node-rfc for Node.js). SAP licenses these connector libraries separately, but they are typically available at no additional cost to existing SAP customers through the SAP Service Marketplace. We verify your specific licensing situation during the assessment phase, but in fifteen years of SAP integration work, we have never encountered a customer who needed to purchase additional SAP licenses solely to use BAPIs, RFCs, or OData services.
What is the difference between a BAPI, an RFC, an OData service, and an IDoc?
These are four different ways to programmatically interact with SAP, each suited to different scenarios. A BAPI (Business Application Programming Interface) is a standardized, SAP-released function module with a documented interface that SAP guarantees will remain stable across upgrades and support packs. BAPIs follow a strict naming convention (BAPI_OBJECT_METHOD), implement consistent error handling through RETURN tables, and support transaction control through BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK. They are the safest way to read and write SAP business data because SAP has committed to interface stability. An RFC (Remote Function Call) is the underlying protocol that enables external programs to call ABAP function modules in SAP. Every BAPI is an RFC-enabled function module, but not every RFC function module is a BAPI. Custom Z-function modules that your ABAP team has built can also be RFC-enabled for external access. RFCs are more flexible than BAPIs but carry more risk because SAP does not guarantee interface stability for non-BAPI function modules. An OData service is a RESTful web service that SAP exposes through its Internet Communication Manager (ICM). In S/4HANA, OData is the primary integration interface — SAP has published 600+ standard OData APIs, and you can build custom ones using CDS views with OData annotations or the RAP (RESTful ABAP Programming) model. OData services communicate over HTTP/HTTPS, accept and return JSON or XML, and support standard query parameters ($filter, $select, $expand, $orderby, $top, $skip). They are the easiest to consume from modern applications because they behave like any other REST API. An IDoc (Intermediate Document) is an asynchronous message format used for EDI and system-to-system batch communication. IDocs are structured documents with a control record (sender, receiver, message type), data records (segments containing the business data), and status records (processing log). They are processed through SAP's ALE (Application Link Enabling) framework and are ideal for scenarios where guaranteed delivery matters more than real-time response — EDI with trading partners, batch master data distribution, and integration with systems that cannot handle synchronous API calls. For new integration projects, we recommend BAPIs or OData services for real-time synchronous needs and IDocs only for EDI or guaranteed-delivery batch scenarios. We actively migrate clients off of legacy IDoc-only integrations toward BAPI or OData when the use case supports it, because the troubleshooting and monitoring experience is significantly better.
We are on SAP ECC and planning to move to S/4HANA in the next 2-3 years. Will these integrations survive the migration?
This is the most important question mid-market SAP customers should be asking, and the answer depends entirely on which integration approach you use. SAP BAPIs have the strongest migration path. SAP has committed to BAPI interface compatibility in S/4HANA for all standard BAPIs — the function signatures, import/export parameters, and table structures remain the same. An integration built against BAPI_SALESORDER_CREATEFROMDAT2 on ECC will work on S/4HANA without modification in most cases. There are exceptions — some BAPIs related to deprecated functionality (classic GL, classic MM movements that are replaced by ACDOCA or MATDOC) may behave differently — but SAP documents these in the S/4HANA Simplification List and we specifically check your integration points against that list during the assessment phase. RFC function modules have a similar migration path for standard function modules. Custom Z-function modules will migrate to S/4HANA as part of your custom code migration, but they may need adjustment if they reference database tables that have been restructured in S/4HANA (BSEG, BSIK, BSID, BSAK, BSAD replaced by ACDOCA; MSEG replaced by MATDOC; VBAK/VBAP table changes). OData services are native to S/4HANA and represent SAP's strategic direction for integration. Building new integrations against OData services on ECC (available from ECC 6.0 EHP7 with SAP Gateway) means those integrations are already S/4HANA-ready. In many cases, migrating from ECC to S/4HANA with OData-based integrations requires changing nothing more than the hostname in your middleware configuration. Our recommended approach for ECC customers with an S/4HANA migration on the horizon: build new integrations using BAPIs or OData services (not IDocs, not direct table access), document every integration point against the S/4HANA Simplification List, and structure the middleware so that switching from RFC-based BAPI calls to HTTP-based OData calls is a configuration change rather than a rewrite. We have migrated integrations from ECC to S/4HANA where the middleware code change was literally updating three environment variables.
How do you handle SAP's authorization model for integration users?
SAP authorization for integration is one of the most underestimated aspects of SAP integration projects and the number one cause of go-live delays. Every RFC call, BAPI execution, and OData request is subject to SAP's authorization framework — the same framework that controls what human users can do in SAP GUI. An integration service user (type B — system user, or type S — service user in S/4HANA) needs authorization objects specific to the interfaces it uses. For RFC calls: S_RFC (authorization to call specific function groups or function modules), S_RFCACL (trusted RFC between SAP systems). For BAPI execution: B_BAPI_METH (authorization for specific BAPI methods on specific business objects). For OData services: S_SERVICE (authorization to access specific ICF service nodes). On top of these technical authorizations, the integration user needs the same business-level authorizations as a human user performing the equivalent transaction. An integration user that creates sales orders through BAPI_SALESORDER_CREATEFROMDAT2 needs authorization objects V_VBAK_VKO (sales organization), V_VBAK_AAT (order type), M_BEST_EKO (purchasing organization if relevant), and potentially dozens of others depending on your specific configuration. We build integration user roles during the assessment phase, following SAP's principle of least privilege — the integration user gets exactly the authorizations needed for its specific integration tasks and nothing more. We test authorization in the QA system using the actual integration user profile (SU53 trace for failed authorization checks, ST01 authorization trace for comprehensive logging) and document every authorization object in the integration blueprint so your SAP security team can review and approve before production deployment.
What does SAP integration cost without PI/PO or Integration Suite?
A custom SAP integration project using direct BAPI, RFC, or OData connections typically costs 40-70% less than the equivalent project built on SAP PI/PO or Integration Suite, because you eliminate the platform licensing cost entirely and reduce the infrastructure and administration overhead. For a straightforward integration point — for example, synchronizing sales orders between a Shopify store and SAP SD using BAPI_SALESORDER_CREATEFROMDAT2 — the cost is $8,000-$15,000 for the integration development, testing, and production deployment. A more complex integration point — bidirectional inventory sync between SAP MM/WM and an external WMS with lot/batch tracking, unit-of-measure conversion, and storage location mapping — runs $15,000-$25,000. A typical mid-market SAP integration project covering 3-5 integration points (e-commerce orders, inventory sync, customer master sync, financial posting, and shipping confirmation) totals $40,000-$80,000 including the middleware infrastructure, all ABAP enhancements, testing, and production cutover. Compare that to SAP PI/PO ($150,000+ in licensing alone, plus $80,000-$200,000 in consulting for the same 3-5 integration points) or SAP Integration Suite ($50,000+/year in subscription plus $60,000-$150,000 in iFlow development). The ongoing cost for custom middleware is $1,000-$3,000 per month for hosting, monitoring, and maintenance — versus $50,000+/year for Integration Suite subscription renewal plus consultant hours for any iFlow modifications. Over a 3-year period, the total cost of ownership difference is typically $200,000-$400,000 in favor of direct integration for a mid-market SAP environment with 3-5 integration points.
Can you integrate SAP Business One, not just ECC or S/4HANA?
Yes, though the integration interfaces are completely different. SAP Business One uses the DI API (Data Interface API) and DI Server for programmatic access, the Service Layer (a RESTful OData API introduced in SAP Business One 9.2) for HTTP-based integration, and a simpler integration framework compared to ECC or S/4HANA. The DI API is a COM-based library that runs on Windows and provides object-oriented access to every Business One business object — business partners, items, documents (orders, invoices, deliveries, payments), production orders, inventory transactions. The Service Layer is the modern alternative, providing RESTful access over HTTP with JSON payloads, session-based authentication, and query capabilities similar to OData. For SAP Business One integration, we typically use the Service Layer for new projects because it runs on any platform (not just Windows), does not require COM interop, and supports standard HTTP tooling for monitoring and debugging. The DI API is still necessary for specific scenarios — complex financial postings, UDF (User Defined Fields) with validation, and transactions that the Service Layer does not fully support. Cost is typically lower than ECC/S/4HANA integration because the data model is simpler, there are fewer authorization complexities, and the Service Layer behaves like a standard REST API without the enterprise overhead of RFC connection management or OData service registration.
How do you handle SAP system downtime and maintenance windows?
SAP systems go down regularly for planned maintenance — kernel updates, support pack applications, client copies, system refreshes — and occasionally for unplanned reasons. Integration services must handle these outages gracefully because an integration that throws errors or loses data during an SAP maintenance window will erode trust in the entire system. Every integration we build includes three layers of resilience. First, a message queue (RabbitMQ, Redis Streams, or AWS SQS depending on your infrastructure) sits between the external system and the SAP-facing middleware. When a transaction arrives — an order from Shopify, an inventory update from the WMS, a customer record change from Salesforce — it is immediately acknowledged and persisted in the queue before any attempt to reach SAP. If SAP is down, the message waits. Second, the SAP-facing middleware implements health check polling against SAP's ICM (for OData) or a lightweight RFC ping function (for RFC/BAPI). When SAP returns online, the middleware begins draining the queue in order, processing backed-up transactions at a controlled rate to avoid overwhelming SAP with a burst of requests. Third, we implement idempotency keys on every write operation so that if a transaction is attempted, SAP goes down mid-processing, and the transaction is retried after SAP comes back, it does not create a duplicate sales order, post a duplicate financial document, or double-count an inventory movement. For planned maintenance windows, we integrate with your SAP operations calendar to proactively pause integration processing and resume automatically when the window closes. For unplanned outages, the queue-based architecture means zero data loss — transactions accumulate in the queue and process in order once SAP is available.
We have existing IDocs that were configured years ago and nobody understands them. Can you help?
This is one of the most common situations we encounter in mid-market SAP environments. Someone — usually an external consultant — configured IDoc interfaces five or ten years ago for a specific project, the documentation was minimal or has been lost, the consultant is no longer available, and now the IDocs are a black box that everyone is afraid to touch. They run, mostly, but nobody knows exactly what data mappings are in place, what the processing logic does, or what will break if anything changes. We start by reverse-engineering the existing IDoc configuration. This means reviewing the partner profiles (transaction WE20), port definitions (WE21), message types and basic types (WE30/WE31), process codes (WE42/WE64), function modules linked to inbound and outbound processing, and any custom ABAP code in user exits or BAdI implementations. We document every field mapping, transformation rule, and piece of processing logic into a technical specification that your team can actually read and maintain. From there, we make a recommendation: modernize or stabilize. If the IDoc interfaces are working reliably and the use case genuinely calls for asynchronous batch processing, we stabilize them — add monitoring (WE05 alerts, BD87 reprocessing automation), fix any silent failures, update the documentation, and leave them running. If the use case has evolved to need real-time synchronous processing, we migrate the integration to BAPI or OData interfaces, run both in parallel during validation, and decommission the IDocs once the new integration is proven. In either case, you end up with integration interfaces that someone on your team actually understands, with documentation that will survive the next consultant change.

Stop Working For Your Software

Make your software work for you. Let's build a sensible solution.