We've encountered situations where the sales department enters orders in SAP while the website lives its own life — stock levels don't match, prices are outdated, and customers complain about delays. Integrating a website with SAP is not just a technical task; it's the key to synchronizing business processes. In this article, we'll dive into the architecture, methods, and pitfalls that engineers face in such projects. We have accumulated experience from over 20 integrations and share best practices.
What problems do we solve?
Data desynchronization is the main pain point. Manual entry leads to errors: SAP holds accurate stock, prices, and order statuses, but the website uses an outdated copy. Performance suffers when every request to SAP via RFC or IDoc loads the productive system — the average SAP response delay is 200–500 ms, which is critical for user experience. Security is at risk if SAP networks are exposed to the internet without middleware — a protected layer with authorization and encryption is needed. A typical scenario: during order synchronization every minute via RFC, table locks occur in SAP, slowing down dispatchers by 30%.
Why not connect the site directly to SAP?
SAP systems are designed for operational tasks, not web traffic. Direct calls from PHP or Node.js via RFC (Remote Function Call) is an anti-pattern. First, SAP JCo (Java Connector) has no native support for PHP — an intermediate service in Java or Python is required. Second, each request from thousands of visitors can cause table locks in SAP. The recommended architecture is an asynchronous bus with queues.
Site (PHP/Node.js)
↕
Middleware (SAP BTP Integration / MuleSoft / custom service)
↕
SAP (via SAP PI/PO, OData, SOAP)
How does SAP BTP simplify integration?
SAP Business Technology Platform (BTP) Integration Suite is a cloud ESB offering monitoring, retry logic, and data transformation. Instead of writing middleware from scratch, we use ready-made connectors for OData, SOAP, and IDoc. This reduces development time by 30–40% and lowers the number of errors in data transfer. For many projects, using BTP pays off in 6–12 months due to lower support costs.
Connection methods to SAP
| Method |
Protocol |
Performance |
Complexity |
Web Support |
| SAP OData |
REST |
High |
Medium |
Native (curl/fetch) |
| RFC |
SAP RFC |
Medium |
High |
Requires JCo/pyrfc |
| SOAP |
HTTP |
Low |
High |
Via SOAP clients |
| IDoc |
XML/ALE |
Asynchronous |
Medium |
Via middleware |
SAP OData is a modern standard. It is published via SAP Gateway, supports CRUD and filtering. In our experience, OData reduces integration development time by 25% compared to RFC. Example request:
GET https://sap-server/sap/opu/odata/sap/ZSD_ORDER_SRV/OrderSet?
$filter=CustomerID eq '1234567'
&$expand=OrderItems
Authorization: Basic {credentials}
SAP recommends using OData as the primary protocol for integration (documentation on SAP Help Portal).
RFC is still used for high-load operations but requires a separate adapter service. IDocs are indispensable for massive asynchronous exchanges (e.g., nightly material upload).
Example of retrieving materials via OData (Python)
import requests
response = requests.get(
'https://sap-gw/sap/opu/odata/sap/ZMM_MATERIAL_SRV/MaterialSet',
params={
'$filter': "Plant eq '1000' and MaterialType eq 'FERT'",
'$select': 'MaterialNumber,Description,BaseUnit,StandardPrice',
'$format': 'json'
},
auth=(SAP_USER, SAP_PASSWORD),
verify=True
)
materials = response.json()['d']['results']
B2B portal with SAP integration
For corporate clients, a B2B portal based on SAP provides:
- Individual prices from SAP SD (pricing conditions for a specific buyer)
- Credit limit and current debt (SAP FI)
- Order history with repeat order capability
- Shipment status and documents (invoices, credit notes)
- Personal managers from SAP CRM
What is included in the work
- Audit of the current SAP system and identification of required modules (SD, MM, FI, CRM)
- Architecture design of middleware (SAP BTP, MuleSoft, or a custom Node.js service)
- Setup of OData services on the SAP side (SAP Gateway)
- Development of the integration layer on the website (REST clients, queues, caching)
- Testing of scenarios: synchronization of orders, stock, prices
- Documentation and administrator training
Typical mistakes in SAP integration
Common issues and how to avoid them
- **N+1 query to SAP**: each order fetches stock separately. Solution — batch loading via $batch in OData.
- **Race condition during synchronization**: multiple users update the same order simultaneously. Solution — optimistic locking with ETag.
- **Lack of caching**: every page render triggers SAP. Solution — local Redis cache with TTL of 30 seconds.
Timelines and economic impact
Development time for a serious B2B integration with multiple modules is 3 to 6 months. Cost is calculated individually after an audit. Customers report a 30–50% reduction in manual synchronization costs and a 40% decrease in order processing time. Return on investment typically occurs in 6–12 months.
Why choose us
5+ years of experience integrating SAP with web applications. Over 20 successful projects for large enterprises. Certified specialists in SAP and web development. Get a consultation on integrating SAP with your website — contact us. Order an audit of your current system and find out how to save up to 50% on synchronization time.
1C:Enterprise Integration: Product, Order, and Stock Exchange
Monday morning. The manager opens the site and sees that the item sold out on Friday is still listed as "in stock". Three customers have already paid for a product that doesn't exist. We encounter this pain regularly: the lack of synchronization between 1C and the online store hurts revenue and reputation. We solve the problem end-to-end — setting up the exchange so that the accounting system and the storefront update synchronously, without data loss, and with consistency guarantees.
1C is the accounting system of most Russian companies. The site is the storefront. They must speak the same language and do so regularly, reliably, and without data loss. Our experience: over 50 successful integrations for clients with catalogs from 500 to 200,000 SKUs.
Why isn't standard CommerceML always sufficient?
CommerceML is a standard exchange protocol supported by 1C:Trade Management, 1C:Integrated Automation, and several other configurations. WooCommerce, Shopify, and other CMS have plugins for CommerceML (e.g., "1C-Bitrix" for their products, separate plugins for WordPress). Flow: 1C initiates exchange → sends a ZIP archive with XML to the site endpoint → site parses and updates the catalog.
CommerceML format is XML with its own schema: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Categories, products, characteristics, images, prices, stock. The main difficulty: the hierarchy of characteristics in 1C and product attributes on the site do not always match one-to-one. Mapping is needed. For a deep understanding of the protocol, we recommend documentation on Wikipedia — Wikipedia: CommerceML.
How we overcome CommerceML limitations
For non-standard 1C configurations or when CommerceML is not suitable — we write an HTTP service in 1C (built-in since version 8.3) and interact via REST JSON. This gives full control over the data structure and synchronization frequency, but requires development from a 1C programmer.
For enterprise tasks with multiple accounting systems — Message Broker (RabbitMQ, Apache Kafka) as an intermediary. 1C publishes events to a queue, the site subscribes and processes them. Guaranteed delivery, buffering when one side is unavailable.
What we synchronize and how
Catalog (products, categories, attributes). The most voluminous part. Full export on first run, delta updates thereafter. When importing CommerceML: parse XML via PHP SimpleXML or XMLReader (for large files — only XMLReader, otherwise memory limit). Match products by GUID from 1C, which we store in a separate database field. If a product is deleted in 1C, we hide it on the site, not delete (order history may reference it).
Stock and prices. This is a separate ПакетПредложений in CommerceML, updated more often than the catalog. It's critical to do it atomically: not update stock one by one, but in a transaction. Otherwise, during the update, the user may see an inconsistent state. Frequency: once an hour for calm mode, once every 5–15 minutes for active trading.
Orders. Two-way exchange. Site → 1C: new order is sent with items, quantities, prices, customer contact info. 1C → site: order status (paid, assembled, shipped, delivered). For order transfer — either the same CommerceML (Документы block) or a direct REST call when an order is created on the site.
What typical problems do we solve?
Duplicate products. A 1C operator created an item with a typo in the SKU, then fixed it. On the site — two items. Solution: matching by GUID from 1C (not by SKU), GUID is immutable.
Cyrillic in XML and encodings. 1C historically works with Windows-1251. A CommerceML file may come in CP1251, PHP expects UTF-8. mb_convert_encoding() or iconv() in the first lines of the parser — mandatory.
Timeouts during large exports. A catalog of 100,000 items is 50–200MB XML. PHP default execution time of 30s is insufficient. Solution: CLI command (Laravel Artisan or Symfony Console) run via cron, without HTTP timeout. Or chunked processing via XMLReader with partial commits to the database.
Images. 1C can transmit images as Base64 inside XML (bloats file by 1.3x) or as file links. The second option is preferable. Download asynchronously, convert to WebP, place in media library.
Case: auto parts online store, 85,000 SKUs. Synchronization via CommerceML every 30 minutes. Problem: full export took 18 minutes, resulting in a new export starting while the old one was still running. Solution: lock via Redis (SET nx ex), delta export (only changed items in the last 2 hours via filter in 1C), processing via queue with 20 parallel workers. Sync time: 18 minutes → 2.5 minutes, no conflicts.
Comparison of integration methods
| Method |
Sync speed |
Configuration flexibility |
Resource intensity |
| CommerceML |
High (binary XML) |
Low (fixed schema) |
Low (hardly affects server) |
| REST API directly |
Medium (JSON) |
High (any model) |
Medium (needs two HTTP servers) |
| Message Broker (RabbitMQ/Kafka) |
Very high (asynchronous) |
Medium (event-driven architecture) |
High (needs broker cluster) |
CommerceML in typical scenarios is 2-3 times faster than REST for catalog synchronization due to binary packing of XML and compact format. However, if custom exchange logic is required, REST provides full flexibility.
Process and timeline
Audit of 1C configuration (version, configuration type, export capabilities) → data mapping design → development of receiver on site and sender in 1C → testing on real data → schedule setup → monitoring of first exchanges.
Participation of a 1C programmer on the client side is mandatory, or we involve a trusted specialist.
| Scenario | Timeline |
| CommerceML, catalog + stock, WooCommerce | 2–4 weeks |
| Two-way order exchange | +2–3 weeks |
| Custom 1C configuration, REST API | 4–8 weeks |
| Enterprise: multiple 1C databases, data bus | 2–4 months |
What's included in the result (deliverables)
- Documentation: mapping scheme, data formats, error handling logic.
- Configured synchronization schedule with execution logs.
- Access to monitoring (Grafana/ELK — by agreement).
- Training for managers: how to run manual exchange, how to read logs.
- Post-launch warranty support — 2 weeks (issue fixing).
Get a consultation
We will evaluate your project within one business day — email us or use the chat. The integration cost is calculated individually based on project complexity. With over 7 years of experience in 1C integrations, we guarantee stable synchronization without surprises.
