ERP Bridge

First-Pass Node Dossier

This page is an evidence-backed node dossier generated from the domain hierarchy and node questionnaire.

What It Is

ERP Bridge is the integration layer that syncs Pyle records with an external ERP system. In the shared packages, this capability is split between framework-owned sync services and actions, and an ERP request-log surface exposed through the separate erp-bridge package.

Parent hierarchy:

• Supporting Platform Capabilities
• Integration And Data Exchange
• ERP Bridge

Primary implementation paths:

• packages/framework/src/Services/ErpBridge
• packages/framework/src/Actions/ErpBridge
• packages/erp-bridge/src/Models/RequestLog.php

What Users Can Do With It

Direct capabilities

Operators can:

• open the packaged Settings > Erp Bridge page
• search ERP request-log rows
• inspect endpoint, method, response code, and exception details
• retry eligible syncs from the request-log actions menu

Indirect capabilities

Other workflows use ERP Bridge to:

• sync models from ERP to Pyle
• sync eligible models from Pyle to ERP
• process hook-driven sync payloads
• convert local models into DTOs for outbound ERP requests

Things users cannot do directly

The inspected shared package does not expose one broad configuration console for ERP mappings or connector setup. The packaged admin surface is mainly a request-log review and retry screen.

Where It Is Managed

Channel	Role	Notes
Admin Settings > Erp Bridge page	Direct	Main packaged operator surface
ERP request-log table	Direct	Search and retry surface
Framework ERP sync services	Indirect upstream input	Own sync orchestration and exception handling
ERP hook and sync actions	Indirect	Own inbound and outbound model synchronization

Sources:

• packages/erp-bridge/src/Models/RequestLog.php
• packages/framework/src/Services/ErpBridge/AbstractErpSyncService.php

Channel-Level Field Coverage

Packaged admin ERP Bridge page

The packaged admin table shows:

• created_at
• method
• endpoint
• response_http_code
• exception_message
• exception_http_code

It also provides a Retry sync action when the log row can be resynced.

Request-log model

The underlying request-log model also persists:

• uuid
• url
• request_headers
• request_body
• response_headers
• response_body
• dto_body
• sync_class
• external_id
• parameters

Sources:

• packages/erp-bridge/src/Models/RequestLog.php

Configuration And Data Model

Key implementation characteristics:

• the request-log review surface depends on Modules\ErpBridge\Models\RequestLog from the packages/erp-bridge package
• framework sync services wrap exceptions in ErpBridgeRequestException
• sync services define four main directions:
  • sync one model from ERP
  • sync many models from ERP
  • sync one model to ERP
  • sync one model from an ERP hook

Important framework abstractions:

• AbstractErpSyncService
• AbstractSyncModelFromErp
• AbstractSyncModelsFromErp
• AbstractSyncModelToErp
• AbstractSyncModelFromHook

Source:

• packages/framework/src/Services/ErpBridge/AbstractErpSyncService.php
• packages/framework/src/Actions/ErpBridge
• packages/erp-bridge/src/Models/RequestLog.php

Relationships

ERP Bridge directly connects to:

• ERP request logs
• model-specific ERP sync services
• DTO conversion actions
• hook and retry flows

Practical dependents in the shared package include:

• products
• product offers
• product categories
• product attributes
• product types
• customers
• addresses
• inventory locations
• inventory items
• orders
• customer product restrictions

Rules And Downstream Effects

Package-boundary split

The request-log review UI is packaged in admin, but the log model itself lives in the separate erp-bridge package. The framework package owns the sync behavior, not the request-log persistence model.

Retry behavior

Retry is only available when a request log has enough information to replay the sync. In practice that means the row must have either parameters or an external_id, plus a sync_class.

Exception wrapping

Framework sync services normalize low-level exceptions into ERP-bridge request exceptions before they surface upward.

Sources:

• packages/erp-bridge/src/Models/RequestLog.php
• packages/framework/src/Services/ErpBridge/AbstractErpSyncService.php

Integrations And Automation

Model-specific sync services

The shared package provides dedicated ERP sync services for many business models, including product, offer, category, customer, address, inventory, and order records.

DTO conversion

Outbound ERP sync flows rely on ToDTO actions for records such as orders, order items, addresses, users, and tax lines.

Hook-driven synchronization

Hook sync paths can run immediately or dispatch asynchronously depending on the incoming parameters.

Sources:

• packages/framework/src/Services/ErpBridge
• packages/framework/src/Actions/ErpBridge
• packages/framework/src/Models/Interfaces/MapsToErpBridgeDTO.php

Where It Appears To End Users

ERP Bridge is an operator and integration concept.

In the inspected shared packages, users experience it through the admin request-log page and through downstream business records that stay in sync with ERP data.

Current Documentation Takeaways

1. ERP Bridge is a real packaged admin review surface, but not a full connector-configuration studio.
2. The framework package owns the sync mechanics, while the erp-bridge package owns the concrete request-log model.
3. Retry and review are request-log-centric; most other ERP behavior happens behind the scenes through sync services.

Open Questions

• This first pass did not inspect host-app ERP connector configuration, credentials, or webhook registration screens outside the shared packages.

Sources

• packages/erp-bridge/src/Models/RequestLog.php
• packages/framework/src/Services/ErpBridge/AbstractErpSyncService.php
• packages/framework/src/Services/ErpBridge
• packages/framework/src/Actions/ErpBridge