Development of middleware for 1C-Bitrix integration

Developing Middleware for 1C-Bitrix Integration

Direct integration between two systems (Bitrix24 ↔ 1C, Bitrix24 ↔ SAP) creates tight coupling: a change in one system's API breaks the other. Middleware is an intermediate layer that receives data from one system, transforms it, and forwards it to another. Both systems only know the middleware — they have no knowledge of each other.

When Middleware is Needed

• Three or more systems exchange data with each other.
• Data formats differ substantially and require complex transformation.
• Buffering is required: one system is unavailable, data accumulates and is delivered later.
• Auditing is required: a complete history of all data exchanges with the ability to replay any operation.
• Different teams develop integrations independently.

Middleware Architecture Options

Option 1. PHP middleware inside 1C-Bitrix — a separate module in /local/modules/ that accepts HTTP requests, transforms data, and proxies it onward. Downside: tied to the 1C-Bitrix infrastructure.

Option 2. Independent microservice (Node.js, Python FastAPI, Go) — lives independently; 1C-Bitrix is one of its sources or consumers. Advantage: scales independently, does not consume PHP resources.

Option 3. iPaaS platforms — Make (Integromat), n8n, Apache Camel. Visual transformation builder without code. Suitable for non-developers, but limited for complex transformations.

PHP Middleware: Structure and Contracts

// Central middleware router
class IntegrationBus {
    private array $handlers = [];

    public function register(string $eventType, callable $handler): void {
        $this->handlers[$eventType][] = $handler;
    }

    public function dispatch(string $eventType, array $payload): array {
        $results = [];
        foreach ($this->handlers[$eventType] ?? [] as $handler) {
            try {
                $results[] = $handler($payload);
            } catch (\Throwable $e) {
                $this->logError($eventType, $payload, $e);
                $results[] = ['error' => $e->getMessage()];
            }
        }
        return $results;
    }
}

// Register handlers in init.php
$bus = IntegrationBus::getInstance();

// New order → CRM and accounting system
$bus->register('order.created', [CrmConnector::class, 'handleNewOrder']);
$bus->register('order.created', [AccountingConnector::class, 'createInvoice']);
$bus->register('order.created', [WarehouseConnector::class, 'reserveGoods']);

Data Transformation (Mapping)

Transformation is the most complex part of middleware. Use the Pipeline pattern:

class TransformationPipeline {
    private array $pipes = [];

    public function pipe(callable $transformation): self {
        $this->pipes[] = $transformation;
        return $this;
    }

    public function process(array $data): array {
        return array_reduce(
            $this->pipes,
            fn($carry, $pipe) => $pipe($carry),
            $data
        );
    }
}

// Example: 1C-Bitrix order → SAP format
$pipeline = (new TransformationPipeline())
    ->pipe(fn($d) => normalizeCustomerData($d))       // normalise customer data
    ->pipe(fn($d) => enrichWithAddressData($d))        // enrich with address data
    ->pipe(fn($d) => convertCurrencyFields($d))        // convert currency fields
    ->pipe(fn($d) => mapStatusCodes($d, 'bitrix2sap')) // map status codes
    ->pipe(fn($d) => validateSapSchema($d));            // validate SAP schema

Audit and Replay

Every message is logged before and after transformation:

// Audit table
CREATE TABLE integration_audit (
    id            BIGSERIAL PRIMARY KEY,
    event_type    VARCHAR(100),
    source_system VARCHAR(50),
    target_system VARCHAR(50),
    payload_in    JSONB,
    payload_out   JSONB,
    status        VARCHAR(20), -- success, error, retry
    error_msg     TEXT,
    duration_ms   INT,
    created_at    TIMESTAMP DEFAULT NOW()
);

When a downstream system fails, the operation can be replayed by audit record ID without re-querying the source.

Case Study: Three-way Interaction

A manufacturing company: 1C:ERP (stock and pricing) ↔ 1C-Bitrix website ↔ RetailCRM (order processing). Without middleware, each system pair had its own integration — six bidirectional connections, six points of failure.

After introducing a middleware hub: 3 systems → 3 connectors to middleware. A change in the 1C API affected only the 1C connector, leaving the RetailCRM integration untouched.