All projectsCase study

TCI → PrestaShop Synchronization Diagnosis

Tracing a status rewritten on every synchronization back to its real source.

PrestaShopTCIERPSynchronisation
TCI PRESTASHOP SYNC
01

Context

A category created in TCI was correctly synchronized to PrestaShop but appeared inactive.

02

Problem

Even after manually activating it in PrestaShop, the next synchronization disabled it again.

03

Solution

Analysis of the complete TCI → connector → PrestaShop flow, reproduction of the issue and correction of the source-side configuration so the correct status was propagated.

04

Key lesson

In an integration, fix the source of truth rather than repairing the same symptom after every synchronization.

MISSION TCI → PrestaShop Synchronization Diagnosis
MY ROLE Integration diagnosis
DURATION Targeted incident
ENVIRONMENT TCI · Connecteur · PrestaShop
STATUS Resolved
01 · BEFORE

Starting point

A correction made in PrestaShop was overwritten by the next synchronization.

→
02 · AFTER

What changes

The root cause was traced back to the source for a durable fix.

PROJECT FLOW LIVE
01 TCI Source
02 Paramètre Statut
03 Connecteur Sync
04 PrestaShop Destination
05 Validation Stable
Under the hood

How the project actually works

Architecture, constraints, deliverables and real impact.

04

Main challenge

Identify which system actually owned the truth when the status was overwritten on every synchronization.

01 TCI
02 Source configuration
03 Connector
04 Synchronization
05 PrestaShop
05

Deliverables

  • Issue reproduction
  • Source → destination diagnosis
  • Source-side correction
  • Post-sync validation
06

Impact

The fix remains durable because it changes the source of the status.

Designed for real-world use
07

What this project demonstrates

I start from the problem and business flow, then aim for an observable, testable and maintainable solution rather than a demo effect.

← PreviousAutomated Plesk Backup Control