Skip to content

Platform Export - Autodoc, Qweon, Rhinoman, Amazon, Evox

Overview

This document specifies the legacy integrations that were still missing decision-grade migration coverage across Platform Export and Vehicle Data.

Checklist coverage: - PX-013 Autodoc API integration app - PX-014 Qweon tyre sync/linking admin and commands - PX-015 Rhinoman stock file generation - PX-016 Amazon fulfillment sync (disabled providers) - INT-008 Rhinoman integration - INT-009 Qweon integration (disabled providers, active CP routes) - INT-010 Evox integration (disabled providers) - INT-011 Amazon Fulfillment integration (disabled providers)

Primary legacy evidence: - _autodoc/index.php - src/Autodoc/Controller/Api/InventoryController.php - src/Autodoc/Controller/Api/OrderController.php - src/Autodoc/Middleware/AuthorizationMiddleware.php - _cp/index.php (/qweon routes) - src/Qweon/ServiceProvider/QweonServiceProvider.php - src/Qweon/Service/SyncTyresService.php - src/Qweon/Command/PullTyresCommand.php - src/Qweon/Command/LinkTyresCommand.php - src/Rhinoman/Service/RhinomanFacade.php - src/Rhinoman/Service/StockFileGenerator.php - src/Rhinoman/Command/GenerateStockFileCommand.php - src/Amazon/Fulfillment/ServiceProvider/AmazonFulfillmentServiceProvider.php - src/Amazon/Fulfillment/Service/AmazonStockExportService.php - src/Amazon/Fulfillment/Service/AmazonOrderRetrievalService.php - src/Evox/ServiceProvider/EvoxServiceProvider.php - src/Evox/Service/DownloadVehiclesService.php - _core/config/service-providers.php - _core/config/command-providers.php

Legacy Capabilities (As-Is)

1. Autodoc API App (PX-013)

The dedicated _autodoc Slim app exposes: - GET /api/getstock/{productIdOrEanCode} - POST /api/createorder - GET /api/trackinfo/{orderId} - GET /api/orderstatus/{orderId} - POST /api/cancelorder

Operational behavior: - Basic auth middleware validates one platform (username = Autodoc) and one supplier (username from credentials). - Request/response traffic is recorded to autodoc_traffic_logs with retention. - createorder creates internal orders from JSON payloads, including stock checks and duplicate-reference protection (prefix:autodoc-order-id). - orderstatus and trackinfo attempt Odoo resync before response. - trackinfo also sets package-link sent status on delivery notes.

2. Qweon Tyre Sync + Admin Linking (PX-014, INT-009)

Capabilities implemented in code: - Pull tyre catalog pages from https://atraxion.qweon.com/webservice/?request=getalltyres.... - Parse XML into DTOs and persist/update qweon_* entities. - Link imported Qweon tyres to local catalogue using SQL-based EAN/MPN matching. - CP/admin routes exist for sync trigger, link/unlink, status changes, and suggestions for brands/profiles.

Activation state: - Global Qweon service/command providers are commented in _core/config/service-providers.php and _core/config/command-providers.php. - CP routes under /qweon remain present in _cp/index.php. - qweon:push-tyres exists but is not registered by command provider.

3. Rhinoman Stock Export (PX-015, INT-008)

Capabilities: - Typed PSR-18 client with X-API-Key header and JSON decode. - RhinomanFacade::getProducts() paginates and maps API payloads to product DTOs. - StockFileGenerator fetches all pages, builds CSV rows, and writes a stock file. - Command app:rhinoman:generate:stock-file <filename> executes the export.

Current export behavior: - Pull-only pagination (default page size 100). - Fixed sleep(5) between pages for rate limiting. - No output file written when no rows are returned.

4. Amazon Fulfillment (PX-016, INT-011)

Implementation exists but is disabled by default: - Service and command providers are commented in global provider configs. - Commands: - amazon:export-stock - amazon:retrieve-orders - Services cover stock export, order retrieval, shipment confirmation, and queue handoff.

Current characteristics: - Selling Partner API client wiring exists. - Stock export is SQL-driven and assumes AmazonExport flag in article data. - Retrieval queues orders via generic queue mechanism. - Order update service contains placeholder behavior for status updates.

5. Evox Vehicle Integration (INT-010)

Implementation exists but is disabled by default: - Evox service and command providers are commented in global provider configs. - Command evox:download-vehicles downloads vehicles, colors, and profile images.

Current characteristics: - API key passed as query parameter in requests. - Full request/response logging to evox_api_log. - Downloads side/front/rear profile images to EVOX_DOWNLOAD_DIR. - Persists evox_vehicles and evox_vehicle_colors model data.

Current Gaps And Risks To Resolve In Migration

  1. Integration activation state is inconsistent (disabled providers but partially active route surfaces, especially Qweon CP routes).
  2. Autodoc authentication is basic header/password matching without stronger signing or replay protection.
  3. Autodoc country-to-invoice-customer mapping is hard-coded in controller logic.
  4. Qweon linking relies on direct SQL update statements and assumes schema-level compatibility.
  5. Rhinoman client returns empty arrays on HTTP client exceptions, making hard failures indistinguishable from empty result sets.
  6. Rhinoman stock file job has fixed sleep-based throttling and no resumable checkpointing.
  7. Amazon module contains non-production placeholders and mapping inconsistencies between API models and queued payloads.
  8. Evox image retrieval uses direct file_get_contents file writes without transport abstraction or retry policy.
  9. Observability is not standardized across these integrations (different logs/tables and uneven failure taxonomy).

Target Migration Specification (Symfony)

Scope

In-scope: - Decision baseline for Autodoc, Qweon, Rhinoman, Amazon, and Evox migration posture. - Target contracts for inbound/outbound flows, hardening requirements, and feature-flag strategy. - Ownership split: Platform Export for channel integrations, Vehicle Data for Evox.

Out-of-scope: - Full implementation of each integration in this document. - Commercial onboarding UI and credential management UI.

Decision Baseline (Proposed)

Integration IDs Proposed Action Rationale
Autodoc API PX-013 Keep (Day 1) Active production contract with stock/order/status endpoints.
Qweon sync/linking PX-014, INT-009 Keep (gated) Existing data/admin workflows exist; enable only with explicit feature flag and conformance checks.
Rhinoman stock export PX-015, INT-008 Keep (low priority) Existing command-based export can be isolated as scheduled batch worker.
Amazon Fulfillment PX-016, INT-011 Defer/Replace Currently disabled and partially implemented; requires full contract revalidation before enablement.
Evox vehicle import INT-010 Defer (Vehicle Data backlog) Disabled optional source; treat as optional adapter after core vehicle sources are stable.

Required Improvements Before Any Re-Enablement

  1. Explicit feature flags per integration and per runtime surface (API, command, admin routes).
  2. Typed configuration validation (credentials, endpoints, timeout, rate limits) at boot.
  3. Idempotency keys and dedupe strategy for all inbound order paths.
  4. Retry/backoff with structured error types (auth, transport, payload, mapping, downstream).
  5. Unified integration audit log schema (attempted/succeeded/failed, correlation id, payload metadata).
  6. Security hardening for inbound APIs (signature/HMAC for Autodoc instead of static basic credential pattern).
  7. Replace direct filesystem/network primitives (file_get_contents, ad-hoc sleeps) with transport/storage abstractions.

Suggested Target Components

Shared contracts: - IntegrationFeatureFlagService - ExternalIntegrationHealthService - IntegrationDeliveryLogService - IntegrationRetryPolicy

Platform Export adapters: - AutodocInboundApiAdapter - QweonCatalogueSyncAdapter - RhinomanStockExportAdapter - AmazonFulfillmentAdapter (disabled until validated)

Vehicle Data adapter: - EvoxVehicleAdapter (optional source, disabled by default)

Data Migration Notes

  1. Preserve Autodoc traffic logs (autodoc_traffic_logs) for audit and replay analysis.
  2. Preserve Qweon entities/tables (qweon_tyres, qweon_tyre_brands, qweon_tyre_profiles, mapping table) if Qweon remains in scope.
  3. Preserve Rhinoman export output contract (CSV headers and column order) for downstream consumers.
  4. Preserve Evox vehicle/color tables and stored asset references if Evox is retained as optional source.
  5. Do not migrate disabled Amazon runtime state blindly; perform contract verification first, then migrate only validated configuration/data.

Acceptance Scenarios (Gherkin)

Feature: Legacy integration decision coverage and migration hardening

  Scenario: Autodoc stock inquiry responds for a valid authenticated request
    Given Autodoc integration is enabled
    And a valid platform and supplier credential pair exists
    When a stock inquiry is sent for a known product identifier
    Then the response should include success, product-id, amount, and price

  Scenario: Autodoc createorder remains idempotent on duplicate external reference
    Given an Autodoc order with external id "X" was already imported
    When the same createorder payload is submitted again
    Then the API should reject the duplicate reference

  Scenario: Qweon pull and link commands synchronize tyres and create links
    Given Qweon integration is feature-enabled
    When qweon pull and link jobs run
    Then qweon tyres, brands, and profiles should be persisted
    And linkable tyres should be mapped to internal products by EAN or MPN

  Scenario: Rhinoman stock-file command exports paginated API data
    Given Rhinoman credentials are valid
    When the stock-file generation command is executed
    Then a CSV file with the agreed header and product rows should be produced

  Scenario: Amazon fulfillment remains disabled unless explicitly enabled
    Given Amazon fulfillment providers are disabled by default
    When application services and commands are bootstrapped
    Then Amazon fulfillment commands should not be available

  Scenario: Evox import stores vehicles, colors, and profile assets
    Given Evox integration is explicitly enabled
    When the vehicle download command runs
    Then vehicle and color records should be persisted
    And profile images should be stored via the configured storage adapter

Open Decisions

  1. Autodoc: keep current API contract as-is, or introduce versioned v2 endpoints with signed requests.
  2. Qweon: is CP route exposure acceptable while providers are disabled, or should routes also be feature-gated.
  3. Rhinoman: should stock export remain file-based only, or add API push mode for near-real-time inventory.
  4. Amazon: replace with a cleaner implementation or permanently drop if business usage is inactive.
  5. Evox: retain as optional secondary source or drop in favor of DriveRight/WheelSize only.