Integration of B2B portal with ERP via ESB

Fault-Tolerant B2B Portal Integration with ERP Core via ESB

In enterprise projects, B2B portals for partners are integrated with monolithic systems like ERP or Tririga. Direct connections lead to race conditions, where simultaneous changes from portal users and core administrators overwrite data. The solution is an ESB as an intermediate layer with an event-driven model for bidirectional asynchronous transfer.

ESB isolates the portal from the internal structure of the core: it accepts JSON, transforms it into SOAP/XML or specific REST, and buffers it in queues (RabbitMQ, Kafka) if unavailable. The core remains the single source of truth—changes in it trigger webhooks to the bus for portal updates.

Problems with Synchronous Point-to-Point Integration

Synchronous calls cause:

• Race condition: The last request overwrites the previous one.
• Downtime propagation: Core backups or updates break the portal.
• Security risks: Exposing APIs externally without proper protection.

In a scenario, a contractor changes a quota on the portal (from 10 to 50 objects), while an administrator changes it in the core (to 5 due to a penalty). Without buffering, data is lost.

Architecture via ESB: Data Flow

Data flow:

• Portal sends JSON to ESB.
• ESB validates, transforms payload, and queues it.
• When the core is available—delivery and confirmation.
• Changes in the core → trigger → webhook to ESB → portal update.

This ensures:

• Interface isolation.
• Asynchrony with retry policies.
• Fault tolerance during peak loads.

Code Documentation: AOK Protocol

To maintain architecture, use AOK—a passport in JSDoc comments of key modules. It records purpose, architecture, integration points, and SOLID compliance.

Example for a quota synchronization module:

/**
 * ====================================================================
 * | AOK PASSPORT: CAPACITY SYNCHRONIZATION MODULE |
 * ====================================================================
 *
 * @PURPOSE
 * Ensuring bidirectional synchronization of "Quota" parameters
 * between the Partner's Personal Account and the card in the Core system.
 *
 * @ARCHITECTURE
 * Accepts JSON payload from the Partner Portal.
 * Validates values (min/max) according to configuration tables.
 * Initiates record updates in the table (Business Object).
 * When data is changed by the Business Administrator, it triggers
 * a background process to send data back via Webhook.
 *
 * @INTEGRATION
 * Endpoint: /api/v1/sync_capacity
 * Security mechanism: JWT token validation, SSL/TLS encryption.
 * Error handling: If the bus is unavailable, activates
 * a retry policy (3 attempts with 5-minute intervals), then logs to Kibana.
 *
 * @SOLID_COMPLIANCE
 * Single Responsibility: The module is only responsible for data synchronization;
 * rating calculation logic is isolated in a separate microservice.
 * ==================================================================== */

AOK minimizes onboarding: new developers immediately see integration context, validation, and error handling.

Key Implementation Components

• Queues: RabbitMQ/Kafka for buffering.
• Transformations: ESB maps JSON → legacy formats (SOAP, XML).
• Triggers: OnSave in the core for reverse synchronization.
• Security: JWT, TLS, rate limiting.
• Monitoring: Logs in Kibana, queue metrics.

Key Takeaways

• Core is the single source of truth; portal reflects state via ESB.
• Asynchrony prevents downtime and race conditions.
• AOK in code ensures long-term maintainability.
• Retry policies (3 attempts, 5-minute intervals) for reliability.
• Isolation reduces security risks from external APIs.

— Editorial Team