Product Creation to Storefront

A new product starts in Logidav, passes through Meduse's catalog, reaches Magento in a JSONL file, then returns its Magento identifiers to Logidav in a CSV acknowledgement. This guide follows that whole loop. Use the detailed guides for the Logidav screen and validation, Meduse processing, and Magento importer.

The sequence is reconstructed from the pinned source revisions above. Scheduled intervals below describe code declarations or historical configuration, not observed production execution. File paths identify application contracts; the deployed FTP accounts and directory roots have not been checked.

Follow one product

Imagine a development fixture with SKU DOC-DEMO-001. This is an illustrative trace, not a product created during this review.

1. Create and prepare the product in Logidav

Open Produits → Gestion des produits → Création de produit → Création de produit menzzo. Click Créer produit, choose the creation type in the modal, then Créer. A saved row's Voir link opens the detail form at /new-product/add-update/{id}.

Complete the required commercial, availability, image and EAN data. The detail form's Publier action posts to new_product_to_synchronise_in_magento. Its controller validates the product, image requirements and EAN conflicts before setting toPublish=1. The response means the product is queued for publication; it has not reached Magento yet. Validation failures also return a JSON status: ok with an error message, so the status field alone is insufficient.

Two different Publish actions

The list row also exposes a Publier action in a different state. It calls new_product_create_in_magento, which starts menzzo:new-product:create, a command marked deprecated. This page follows the detail form's Meduse route. See the Logidav guide before treating the two buttons as interchangeable.

2. Logidav exports the publication request

menzzo:new-product:synchronise --action=sync selects up to ten toPublish=1 records, builds a separate payload per selected record (including its variations) and uses MeduseService::sendNewProductToFtp() to upload JSON:

meduse/connectors/logidav/new-product/pending/
  logidav_new_products_<timestamp>_<random>.json

The command advances toPublish to 2 after its send block. A caught upload error can still be followed by that state change, so toPublish=2 is not proof that the FTP file exists. Logidav's preserved historical crontab lists a five-minute invocation, while its repository also contains a two-second loop script. Neither establishes which launcher is active in a particular environment.

3. Meduse picks up the JSON and creates catalog records

The Laravel schedule declares meduse:module:logidav:generate-sync-jobs every minute. It takes the file from new-product/pending, creates a local processing copy and lock, moves the FTP file to new-product/processing, then dispatches ProcessNewProduct on the process-new-product queue.

The job creates or enriches Meduse catalog records and their values. On its normal completion path it moves the original input to new-product/complete. For the Menzzo connector, it also queues the product exporter on export. Caught import failures use new-product/failed; partial database effects and stale locks require separate inspection. A running scheduler without a worker consuming the named queue cannot complete this handoff when the queue connection is asynchronous.

4. Meduse builds the Magento feed

Modules/Menzzo/Jobs/ExportProducts maps catalog products to JSONL, one product per line, and uploads a new file:

/meduse/connectors/menzzo/export/pending/
  <timestamp>_<random>_export-products-<timestamp>.jsonl

This is a new transformed file, not the original Logidav JSON moved between folders. Event-driven edits and the source-scheduled menzzo:products-export command can also dispatch exports; see the Meduse guide for selection, connector enablement and queue names. There is no mandatory second Publish click in the reviewed Meduse UI for this import path. Its edit form uses Modifier / Enregistrer and catalog status fields.

5. Magento consumes the JSONL

Magento's meduse cron group declares axelites_meduse_syncproducts, implemented by Axelites\Meduse\Cron\SyncProducts::execute(), every five minutes. It takes up to four pending JSONL files per invocation, moves them into export/processing, and processes that selected batch.

Magento finds each product by SKU. It creates a simple product if none exists, otherwise updates the existing product according to its mappings and age-dependent rules. Attributes, family, categories, stock, images, website assignment and indexing have separate effects; they are not one atomic publish operation. Existing products older than two days, for example, skip incoming status/visibility attribute changes. The Magento guide explains these rules and supplier-specific overrides.

Magento uses a configured FTP prefix followed by export/pending, export/processing and export/complete. The intended shared contract requires that prefix to correspond to Meduse's /meduse/connectors/menzzo/ destination. Source matching does not verify the deployed configuration.

6. Magento writes an acknowledgement, then removes the input

The importer writes a CSV named updated_<JSONL-basename-without-extension>.csv into export/complete. It contains SKU, feedId, magento_id and derived catalog/shipping metadata. It then attempts to delete the processed JSONL from export/processing; the input is not simply archived in complete.

An acknowledgement row is assembled before later attribute, category and image updates. Row errors are caught and processing continues, and response-write failures can still reach input removal. A magento_id or completion CSV therefore proves neither all-field success nor storefront visibility. This importer has no dedicated failed-file directory. Files left in processing are not automatically included in the next Magento invocation's newly selected pending batch. Meduse separately declares menzzo:retry-failed-files hourly: it moves processing files at least one hour old back to pending, which can replay partial work. Its deployment is unverified.

7. Meduse returns the result to Logidav

meduse:sync-after-magento-update, declared every minute, reads the Magento CSV in menzzo/export/complete. It reconciles identifiers and selected connector fields, adds URL/image/coefficient data to the CSV and moves it to:

meduse/connectors/logidav/new-product/finished/<acknowledgement-name>.csv

It can also request a separate Meduse-to-Logidav catalog export. That separate export-logidav path must not be confused with the new-product/finished acknowledgement loop; its Logidav consumer is stopped at the reviewed revision. See Meduse publication.

8. Logidav reconciles the acknowledgement

menzzo:new-product:synchronise --action=checkCreatedProductsFromMeduse reads the finished CSVs. For an existing local SKU with a numeric Magento ID, it can populate source_id, clear is_new, and request menzzo:v2:products --productId=<Magento ID> when the source ID was missing. The linked new-product record is marked is_publish=2, to_publish=0. Other response fields enrich local product data, and the response file is deleted after processing.

Those flags record receipt of an acknowledgement. Final acceptance still checks the intended storefront/store view: the correct product page, images, attributes, availability and price, plus category/search visibility where expected. No such runtime test was performed for this documentation.

The whole loop

View diagram source

sequenceDiagram
  actor Editor
  participant L as Logidav
  participant F as FTP exchange
  participant M as Meduse scheduler and workers
  participant G as Magento meduse cron group
  Editor->>L: Detail form Publier
  L->>L: Validate, toPublish = 1
  L->>F: action=sync writes new-product/pending JSON
  M->>F: Claim JSON to new-product/processing
  M->>M: process-new-product job, catalog writes
  M->>F: Original JSON to new-product/complete
  M->>F: Export job writes menzzo/export/pending JSONL
  G->>F: Move selected JSONL to export/processing
  G->>G: SKU create/update, attempt attributes and media
  G->>F: Write export/complete updated_*.csv
  G->>F: Attempt deletion of input JSONL
  G->>G: After batch, attempt search updates and reindexing
  Note over G,F: CSV can contain partial results
  M->>F: Read and enrich completed CSV
  M->>F: Move CSV to new-product/finished
  L->>F: action=checkCreatedProductsFromMeduse reads CSV
  L->>L: Reconcile IDs, is_publish=2, to_publish=0
  L->>F: Delete handled acknowledgement
  Note over Editor,G: Storefront acceptance is a separate check

Diagram

Find the first missing handoff

Last observed state	Next source component to trace	What that state does not prove
Detail form accepted; toPublish=1	Logidav synchronization launcher and selected record	A file was exported.
toPublish=2	Upload result and the exact JSON filename	Upload success, because send errors can be caught before this flag is written.
JSON in new-product/processing	Meduse local lock/copy and process-new-product worker	The job ran, completed, or can safely be replayed.
JSON in new-product/complete	Menzzo connector and Meduse export job	Magento import or even a successful destination upload.
JSONL in menzzo/export/pending	Matching Magento FTP root and axelites_meduse_syncproducts	The environment is running this cron.
JSONL in export/processing	The selected import batch, row errors and acknowledgement write	Automatic retry on the next run.
updated_*.csv in export/complete	Meduse meduse:sync-after-magento-update	All product fields, media and indexes succeeded.
CSV in new-product/finished	Logidav checkCreatedProductsFromMeduse action	Local source IDs and flags were reconciled.
is_publish=2, to_publish=0	Intended store-view and storefront acceptance	A visible, purchasable or fully indexed product.

For an approved development fixture, record SKU, local product IDs, exact filenames, tracked job IDs, row errors and resulting Magento ID. Follow these checkpoints without moving files or replaying jobs speculatively: the flow has partial writes and no end-to-end transaction. Production inspection or recovery requires approval for the exact command and target.

Related journeys and remaining evidence

• Product editing covers later Meduse edits and bulk saves.
• Magento catalog dependencies follows family, attribute, product-family, file, image and menu consumers. These feeds have different formats and completion rules.
• Stock and catalog covers Logidav operational availability/price changes and its separate Magento API queue.
• Menzzo workflow map identifies the remaining storefront, checkout, order, shipment and refund documentation boundaries.

The detailed guides contain pinned source links for each step. This walkthrough establishes a source-level chain across the three repositories; it does not establish deployed versions, shared FTP configuration, installed launchers/workers, delivery timing, CDN behavior or owner acceptance. Those are the remaining checks for an environment-specific onboarding exercise.