Meduse integration workflows

This page maps source-visible triggers, processors, file/API destinations, and code-level statuses at the pinned revisions. A configured schedule or successful local job status does not prove a live worker, remote acknowledgement, or customer-visible result.

Choose the workflow

Starting point	Walkthrough	Continue into
Product form or spreadsheet grid	Product editing and bulk updates	Magento export or the tenant's event listener
Attribute, family, category or menu editor	Catalog structure and menus	Menu and file exports
Images, attachments or Vimeo stories	Media workflows	The selected tenant's export processor and destination
Logidav name, parcel or shipping data for Mosaikasa	Catalog enrichment	Catalog values or connector resource data, depending on the importer
Family, attribute or ASIR mapping file for Logidav	Reference-data sync	The matching Logidav command and its parser/state transitions
New product, stock, price or product-update file	Logidav handoffs and stock/price paths	Logidav-side integration contract
Supplier input, WooCommerce feed, Shopify or Merchant Center	Supplier/public feeds and API flows	Connector inventory and schedule inventory

Earlier Logidav workflow notes

The older Meduse command pages remain available below. Their schedule rows were copied from historical Logidav documentation; they are not Meduse Laravel schedule declarations and do not establish that a production cron is active. Some are incomplete command stubs. Use the current integration and workflow guides for reviewed behavior, and retain the old notes as migration evidence.

Historical command note	Current starting point
Product data sync	Logidav product handoffs
Attribute sync	Reference-data sync
Family save	Reference-data sync
Stock sync	Stock and availability
Price sync	Price handoff
ASIR attribute mapping	Reference-data sync and ASIR interface

Catalog product export to Magento

For the complete click-to-file-to-storefront journey, read Product creation to storefront, Meduse publication, and the receiving Magento catalog importer.

CatalogProduct change logging provides the source cursor. The Menzzo schedule defines menzzo:products-export every minute; that command runs the ExportProducts job synchronously. Product-update jobs can also emit ExportProductsEvent, which the Menzzo event provider dispatches to export-products. The job requires an enabled menzzo connector and a CatalogProduct resource row, reads version records after last_sync, normalizes catalog attributes and channel scopes, and writes JSON Lines to the Menzzo FTP export/pending directory.

View diagram source

sequenceDiagram
    participant C as Meduse catalog
    participant V as VersioningVersion
    participant T as Menzzo schedule or update event
    participant J as ExportProducts
    participant F as Menzzo FTP
    participant G as Magento consumer
    participant R as SyncAfterMagentoUpdate
    C->>V: save tracked product changes
    T->>J: every-minute command or queued event
    J->>J: check connector, resource row, and last_sync
    J->>F: upload mapped product JSONL to export/pending
    Note over F,G: Magento importer writes a separate CSV acknowledgement - see its guide
    G-->>F: completed export response expected by Meduse
    R->>F: read export/complete
    R->>C: merge returned IDs and product metadata

Diagram

The file is a product feed, not a direct Magento API call. The exporter includes SKU, enabled status, category/family/channel codes, associations, catalog attributes, and image references; it converts price-collection values to an EUR value and writes one JSON object per line. SyncAfterMagentoUpdate is separately scheduled every minute and reads files placed in export/complete. It can import returned Magento/feed IDs, URLs, image references, availability, shipping metadata, and connector resource info, then moves the source file into Logidav’s new-product/finished path and invokes the Meduse-to-Logidav export command. The receiving Magento importer creates a separate updated_*.csv acknowledgement in complete and attempts to delete the input JSONL; it does not simply move the original feed to complete.

The product job tracks a TrackedJob and marks it finished after the FTP write; an exception marks it failed and attempts to restore the previous last_sync. That status is an upload-level signal only. It does not prove Magento imported the file.

Logidav product handoffs

Two opposite file paths must be kept distinct.

Logidav to Meduse: new product JSON and update CSV

Logidav’s MeduseService::sendNewProductToFtp() writes new-product JSON into /meduse/connectors/logidav/new-product/pending. Meduse’s Logidav schedule polls that directory every minute through GenerateSyncJobsForCommand; it copies each file locally, moves the FTP file to processing, and pushes ProcessNewProduct onto the process-new-product Laravel queue. The processor maps product attributes/options/channels, writes the main catalog and selected tenant catalogs, and moves the FTP file to complete or failed. It then dispatches the Menzzo product export for central products or the MeublePromo export for the MeublePromo tenant.

View diagram source

sequenceDiagram
    participant L as Logidav product workflow
    participant F as Shared FTP
    participant G as GenerateSyncJobsForCommand
    participant Q as Configured Laravel queue
    participant P as ProcessNewProduct
    participant C as Meduse catalog and tenants
    L->>F: write new-product JSON to pending
    G->>F: copy locally and move pending to processing
    G->>Q: dispatch on process-new-product label
    Q->>P: run mapped import (may be inline)
    P->>C: create/update catalog product and selected tenant copy
    P->>F: move source to complete or failed
    P->>Q: enqueue destination product export

Diagram

Logidav’s separate ProductMeduseDataUpdateProcessor reads rows from its mz_meduse_queue, maps attributes, and writes a pipe-delimited CSV to /meduse/connectors/logidav/syncProduct/pending. Meduse’s SyncProductCommand polls that path, moves each file through processing, applies the scoped changes to CatalogProduct, writes row errors into the file when needed, and moves it to complete or failed; after processing it queues a Menzzo product export. This handoff is FTP-backed. It is separate from both Laravel’s queue and the generic Logidav mz_queue path.

Meduse to Logidav: product feed

SyncProductToLogidavCommand reads changed catalog versions (or an explicit product ID list), maps scoped attributes/options/store IDs, and uploads a pipe-delimited CSV to /meduse/connectors/logidav/export-logidav/pending. The intended Logidav reader is SyncProductMeduseCommand, which contains a matching pending/processing/complete/failed reader and product update mapping. In the reviewed Logidav source revision, however, execute() calls die('stopped') before connecting to FTP or reading that directory. The reader is therefore unreachable in this revision; the Meduse FTP upload is not proof that Logidav imported the feed.

View diagram source

sequenceDiagram
    participant C as Meduse catalog
    participant V as VersioningVersion
    participant E as SyncProductToLogidavCommand
    participant F as Shared FTP
    participant L as Logidav SyncProductMeduseCommand
    C->>V: record catalog change
    E->>V: select versions after last_sync
    E->>F: upload pipe CSV to export-logidav/pending
    Note over F,L: consumer exits before FTP reader, no import is shown in this source revision

Diagram

Stock, availability, price, and quantity

Logidav’s menzzo:product:meduse:sync-stock producer writes a semicolon-delimited availability CSV to export-stock; Meduse’s Logidav scheduler defines the matching import command every 30 minutes. Meduse deletes each source file before parsing it, compares the incoming snapshot with catalog_product_availability_update, replaces that tracking table, and emits AvailabilityUpdateDetected for changed rows. The Mosaikasa event provider listens and dispatches the Menzzo ProcessAvailabilityUpdateJob; that job bulk-updates catalog availability/status attributes and does not call Shopify. The event provider’s Mosaikasa-specific processor dispatch is commented out.

Price uses a separate semicolon-delimited feed. Logidav’s menzzo:product:meduse:sync-price command writes to export-price; Meduse schedules sync-price-from-logidav every five minutes. Meduse maps retail and special prices into the central catalog and selected MeublePromo/Mosaikasa tenants, with supplier-specific price calculations for the branches in source. It deletes each input file before processing and tracks command output, but no durable per-file failure folder is shown.

Quantity is a third, separate feed under products-qty. Meduse defines a six-hour schedule for sync-qty-from-logidav; the command validates SKU and numeric quantity, updates catalog_product.qty, deletes a fully successful file, and rewrites a file with row-level errors if some rows fail.

View diagram source

sequenceDiagram
    participant L as Logidav export commands
    participant F as Shared FTP
    participant S as Meduse stock/price/qty schedules
    participant A as Availability tracking table
    participant P as CatalogProduct
    participant E as AvailabilityUpdateDetected
    L->>F: stock CSV to export-stock
    L->>F: price CSV to export-price
    L->>F: qty CSV to products-qty
    S->>F: poll each feed on its configured interval
    S->>A: replace availability snapshot and identify changed rows
    S->>P: apply price and qty files
    S->>E: emit event for changed availability rows
    E->>P: dispatch Menzzo availability processor
    Note over E,P: processor updates catalog attributes, this listener does not invoke Shopify

Diagram

A separate daily mosaikasa:sync-product-availability command compares the Mosaikasa tenant catalog with the central availability table and synchronously runs the same Menzzo catalog-update job. The source also defines a two-hour mosaikasa:update-availability-with-bulk-operation schedule that builds JSONL, performs a staged upload, and starts a Shopify bulk operation. The explicit manual update:availability command calls Mosaikasa’s Shopify UpdateAvailabilityJob synchronously; that job builds availability/status JSONL and runs Shopify bulk mutations. A Mosaikasa-specific processor can also queue UpdateAvailabilityJob, but its event-provider dispatch is commented out in this revision. See the Mosaikasa schedule, tenant comparison command, bulk availability command, manual availability command, Shopify job, and Shopify service.

Product images, product files, and menus

Product image upload/save routes call UploadProductImagesController. On removal, the controller clears the relevant raw_values reference and saves the product; that branch does not delete the underlying image file. After a central-tenant image update, the controller emits ProductImagesUpdated; the Menzzo event provider dispatches ProductImagesProcessor to export-product-images. The processor builds a pipe-delimited CSV containing SKU and serialized image references/flags, then uploads it to /meduse/connectors/menzzo/export-product-images/pending. The listener ignores events whose tenant is non-null. The job’s success status means the FTP put completed; it does not prove that Magento fetched the referenced images or that a CDN/storefront image rendered.

For the Mosaikasa tenant, the Mosaikasa event provider sends image updates to its own export-product-images queue. ProductImagesProcessor reads the current image references and runs UpdateShopifyProductImagesJob synchronously, which calls Shopify GraphQL through ShopifyService. This differs from the Menzzo FTP metadata feed; neither job proves storefront rendering.

ProductFilesProcessor sends product file URL fields such as dimension visuals, notices, and unpacking video references to its own FTP pending directory. It is metadata/reference export; binary transfer and the receiving consumer are not established here.

Menu export has two Menzzo API entry points. GET /api/menu/export-menu-json runs a controller export that writes JSON to the Menzzo FTP menu path. GET /api/menu/export-menu-csv dispatches a JSON menu job and CSV job to the export queue; the JSON job writes per-channel/device-type files under menu/menu_json, while the CSV job uploads to {tenant}/menu/pending. The menu jobs mark their tracked job finished after creating/uploading the file. The Magento menu consumers are now traced separately: scheduled JSON snapshots are reread without a file move, while the separate CSV handler’s invocation remains unverified.

For Mosaikasa, CatalogCategoryController::updateShopifyMenu() pushes UpdateShopifyMenu to the export queue; the job maps Meduse menu categories to Shopify collection IDs and calls the Shopify menu mutation. For MakeUp, MakeUpCatalogCategoryController::updateMakeUpMenu() instead invokes Artisan::call('makeup:update-menu') inline, and that command directly calls MakeUpService::menuUpdate(). These are Shopify API paths, distinct from the Menzzo FTP menu files.

View diagram source

sequenceDiagram
    participant U as Meduse API caller
    participant C as Image or menu controller
    participant Q as Laravel queue
    participant J as Image/menu export job
    participant F as Shared FTP
    participant G as Magento consumer
    U->>C: upload/save images or request menu export
    C->>Q: dispatch jobs to named queue (may run inline)
    Q->>J: run export processor
    J->>F: upload CSV/JSON references to pending or menu path
    Note over F,G: downstream asset/menu import is not in the supplied source

Diagram

Supplier feeds and public feeds

The Bigbuy and Vidaxl commands are inbound supplier-feed processors, not catalog exports to those platforms. Bigbuy’s registered menzzo:import:bigbuy-products-suplier command reads semicolon CSV files from the SFTP disk under files/products/csv/standard/, joins supplier rows to catalog products marked drop_ship=bigbuy, recalculates regional prices/enabled state, and updates local Bigbuy quantity and shipping-rate data. Separate core commands, menzzo:import:bigbuy-categories and menzzo:import:bigbuy-products, materialize Meduse categories/products from mz_bigbuy_* staging tables. No schedule for these commands or producer for the product-export staging table was found in the scoped source.

Vidaxl’s menzzo:import:vidaxl-products-category command downloads its supplier CSV over HTTP to data/vidaxl/products, parses stock/price columns, and updates matching Vidaxl catalog records and tenant flat rows. The URL constant is deliberately not reproduced. A download error raises an exception; no tracked-job or remote-import acknowledgement appears in this command. Neither supplier command has a module schedule provider in this snapshot.

Ameubleo is an outbound file feed to a WooCommerce plugin. Its three commands select catalog products/attributes/menu data, write newline-delimited JSON under config-selected paths on the public storage disk, and atomically rename the completed temporary file. The schedule defines catalog at minute 00, menu at minute 15, and attributes at minute 30 every six hours. The feed consumer and its polling/acknowledgement behavior are not in the supplied source. See the Ameubleo schedule, catalog exporter, menu exporter, and attributes exporter.

Shopify and Google Merchant API flows

Mosaikasa uses Shopify Admin GraphQL. Product name, attribute, image, and association events pass through its event provider; name/attribute/image jobs use queue labels, while some association work is dispatched synchronously. Scheduled price export at 00:30 generates JSONL and starts Shopify bulk operations; bulk-operation checks run every five minutes. Status and stock commands are defined every four hours, and a Shopify availability bulk-operation command every two hours. These are source schedules only. The Mosaikasa schedule provider and event provider define those triggers; product price and availability commands report API/bulk-operation errors, while a successful command start is not proof that Shopify completed the bulk operation.

MakeUp uses a separate MakeUpService GraphQL client. meduse:makeup:export-all-products reads the make_up tenant, creates or updates Shopify products/variants and uploads media, then writes platform IDs to connector mapping tables. Category commands/jobs create Shopify collections and save their IDs. There is no MakeUp schedule provider in this snapshot; product export is a manual command path and the MakeUp category controller calls its Artisan menu command inline.

MerchantCenter uses direct HTTP batches rather than FTP. merchant-center:google-shopping-products shapes Meduse catalog data into Google product entries and sends batches through the configured Merchant API or legacy Google Shopping batch service; --dryRun avoids the write. A separate Spanish command builds candidate entries from Mosaikasa’s Shopify product/variant IDs and submits Merchant API product inputs, recording accepted IDs and a completion digest in cache. Its schedule gates Spain sync and verification on module configuration, with the optional cleanup also gated. The MerchantCenter schedule, product command, and Spanish sync describe these paths. Product API acceptance is the source-level boundary; Google-side serving and approval were not checked.

Shopify product URL readback

The daily shopify:sync-products-from-shopify declaration is the reverse direction from the outbound mutations above. Its command handler initializes mosaikasa, fetches product/variant data through ShopifyService, and processes the returned items in chunks of 100. Each item is matched by platform_variant_id and the Shopify connector ID in connector_resource_product.

For a matching catalog product, the handler finds or creates the Shopify connector's ConnectorResourceData and stores a nonempty product URL with ?variant=<variant ID> at infos.url_key.fr_FR. This is connector metadata readback, separate from the Logidav shipping metadata import. Unmatched variants are skipped; a missing URL leaves an existing URL unchanged. The handler does not verify that a customer can open the resulting URL.

Each chunk has its own database transaction. A caught chunk exception rolls back that chunk, logs an error and continues; the final success message can therefore follow skipped variants or rolled-back chunks. Validate the mapped variant, connector record and URL for the affected development fixture rather than treating the final line or daily schedule declaration as full reconciliation. The reviewed source does not prove that the scheduled command ran or fetched every remote product.

Status and failure interpretation

• TrackedJob and queue-monitor states describe Meduse-side processing. A finished export job means its local file and FTP upload path returned successfully; it is not a remote import acknowledgement.
• Queue names and Queue::push/dispatch calls do not prove an asynchronous worker. The repository default is sync unless QUEUE_CONNECTION overrides it; deployed configuration and worker state were not inspected. HTTP callers may therefore wait for inline job execution under the default, while an asynchronous override requires a worker.
• Both the Mosaikasa and Logidav schedule providers define shopify:manage-product-status every four hours. The source review cannot establish whether both providers load in the same runtime or whether the scheduler executes duplicate definitions.
• For incoming new-product JSON, Meduse moves files through pending, processing, and complete/failed. For Logidav’s Meduse-to-Logidav product CSV, the intended Logidav transition is unreachable because of the early die('stopped').
• Logidav’s specialized Meduse queue processor marks queue rows Complete before the FTP write. That status can therefore precede a successful file handoff and must not be used alone as delivery proof.
• The Meduse stock importer deletes availability and price input files before processing. Runtime retry behavior and recovery of a malformed/deleted file are not established by the source reviewed here.

Remaining proof

To claim end-to-end operation, inspect the approved runtime boundary separately: connector/resource rows and cursor values, scheduler and queue-worker state, the correct FTP account and file lifecycle, the Magento consumer/acknowledgement path, and final catalog/storefront readback. Image acceptance additionally needs the real asset path from Meduse upload through FTP or storage, CDN delivery, and rendered storefront. No production host, database, browser, or live service was accessed for this source review.