Integrări B2B în Magento 2: Profiles, Mappings și controlul sincronizării în B2B Suite

Integrarea Magento 2 cu ERP, PIM, WMS sau CRM înseamnă mai mult decât trimiterea datelor către un API. Trebuie identificată compania, legate identificatoarele, verificat rezultatul și gestionate mesajele respinse. În B2B, de aici depind procesarea comenzii, recunoașterea corectă a clientului și livrarea listei convenite către canalul potrivit.

Integrations în Kowal B2B Suite organizează lucrul în cinci zone: Profiles, Mappings, Sync Jobs, Dead Letter Queue și Sync Errors. Explicăm funcționarea și utilizarea lor zilnică.

Descrierea urmează implementarea verificată în noiembrie 2026. Exemplele sunt ilustrative și presupun un adaptor instalat pentru sistemul și operația indicate.

Ce oferă Integrations și ce face adaptorul?

Integrations oferă infrastructură comună: profiluri, asocieri de ID-uri, registru de sarcini, controlul încercărilor, rezultate și istoric de erori. Un adaptor realizează conexiunea concretă la ERP, PIM, WMS sau CRM și cunoaște API-ul și regulile acelui sistem.

Adaptorul definește autentificarea, formatele, transformarea câmpurilor și execuția. Selectarea „ERP” descrie scopul profilului; nu instalează automat o conexiune cu orice ERP.

Salvarea unei sarcini înregistrează doar lucrul de efectuat. Formularul nu pornește un proces periodic în fundal. Procesarea și selectarea sarcinilor trebuie conectate la implementare, de exemplu printr-un executant, planificator sau middleware care folosește logica și API-ul oferite.

Cinci ecrane, cinci întrebări precise

Elementele prezintă același proces din perspective diferite. Profilul definește contextul, asocierile leagă înregistrări, sarcina reprezintă operația, iar ultimele ecrane ajută la gestionarea eșecurilor.

Profiles: configurarea integrării pentru website-ul corect

În B2B > Integrations > Profiles creezi și editezi profiluri. Fiecare aparține unui website Magento cu B2B activ. Poți separa astfel canalele naționale și export dacă folosesc website-uri distincte.

Website este aici unitatea Magento pentru organizarea canalului comercial. Mai multe vizualizări lingvistice în același website nu înseamnă automat integrări independente.

Config JSON nu are câmpuri universale pentru toate integrările. Adaptorul interpretează cheile. Formularul verifică JSON, dar nu înlocuiește testarea conexiunii. Pentru credențiale sunt recomandate referințe la o configurație sigură, conform cerințelor adaptorului.

Integratorul folosește astfel un profil denumit în loc să repete parametrii ERP în scripturi separate. Operatorul vede sistemul și direcția schimbului.

Mappings: legarea identificatoarelor Magento și externe

O companie poate avea ID 42 în B2B Suite și cod ERP-C-0084 în ERP. O persoană recunoaște același client; integrarea necesită o legătură explicită pentru citirea sau actualizarea fișei corecte.

Mappings salvează website, tip sistem, tip entitate, ID local, ID extern și metadate JSON opționale. Interfața prevede companii, clienți, produse, categorii, liste de prețuri, comenzi, RFQ și documente.

Valorile sunt exemple. Adaptorul decide reprezentarea ID-ului local pentru fiecare entitate. Asocierile pot fi căutate atât după ID local, cât și extern.

Mappings leagă identități de înregistrări; nu este un editor vizual pentru transformarea câmpurilor. Reguli precum „numele clientului ERP ajunge în câmpul company Magento” aparțin adaptorului. Salvarea unei asocieri nu descarcă și nu sincronizează date.

Contextul include website, tip sistem și entitate, nu exclusiv un profil. Pentru mai multe conexiuni de același tip într-un website, integratorul trebuie să planifice identificarea coerentă. Baza impune unicitatea ID-urilor locale și externe în acest context.

Sync Jobs: registrul lucrului și al sincronizării

Un Sync Job reprezintă o operație, cum ar fi trimiterea unei comenzi către ERP. În Schedule Sync Job alegi profil activ, entitate și operație. Poți indica direcție, date JSON, cheie de idempotență, limită de încercări și termen. Fără suprascriere, direcția vine din profil.

Adaptorul trebuie să înțeleagă entitatea și numele operației. export_order poate face parte din soluția convenită, dar simpla introducere nu implementează exportul.

View arată rezumat, intrare, rezultat al adaptorului, jurnale și erori. Verifici website, profil, direcție, entitate, operație, încercări, cheie și orele planificării, pornirii și încheierii.

Interpretează success conform contractului adaptorului. Dacă API-ul extern doar acceptă mesajul pentru procesare ulterioară, stabilește dacă rezultatul înseamnă recepție sau finalizare confirmată a operației comerciale.

Termenul planificat informează executantul. Setarea datei nu înlocuiește funcționarea procesului sau regulile de selectare a sarcinilor pregătite.

Idempotență: limitarea sarcinilor duplicate

După o întrerupere, middleware-ul poate trimite din nou aceeași operație. O cheie de idempotență identifică sarcina existentă. Publicarea cu aceeași cheie în același website returnează înregistrarea în loc să creeze alta.

Cheia trebuie să identifice o operație concretă, de exemplu exportul unei versiuni a comenzii. Este comună website-ului: include context recognoscibil de sistem și operație. Refolosirea unei chei vechi nu actualizează datele sarcinii existente.

Aceasta evită înregistrări duplicate. Prevenirea efectelor repetate în ERP, precum un al doilea document după un răspuns incert, trebuie asigurată și de adaptor și de posibilitățile API-ului extern.

Dead Letter Queue: sarcini care necesită o decizie

Dead Letter Queue arată sarcini dead. Este o vizualizare a acelorași înregistrări, nu o copie suplimentară a mesajelor. Separă operațiile nefinalizate în limita permisă.

La trei încercări, a treia execuție eșuată setează dead. Modulul nu lansează automat trei încercări consecutive. Execuțiile următoare și intervalele depind de mecanismul de reîncercare și executantul implementat.

Operatorul deschide sarcina, investighează și corectează cauza, de exemplu asocierea lipsă a clientului sau conexiunea. Apoi poate folosi Retry Job.

Reîncercarea este disponibilă pentru failed și dead. Nu creează altă sarcină și nu resetează istoricul încercărilor. Setează retry, termenul curent și șterge orele anterioare de pornire și încheiere. Dacă limita era epuizată, o mărește pentru încă o încercare. Adaptorul rulează numai la procesarea ulterioară.

Sync Errors: istoricul erorilor în context

Sync Errors arată erorile adaptorului: cod, mesaj, oră și posibilitatea reîncercării. Le asociază contextului actual al sarcinii, profilului și website-ului, separând problema unui client de o avarie generală.

Detaliile includ erori și jurnale tehnice pentru pornire, încheiere și planificarea reîncercării. Datele erorii păstrează și o urmă tehnică utilă integratorului.

O sarcină poate avea mai multe erori din încercări succesive. Numărul lor nu este numărul operațiilor rămase. O sarcină reușită ulterior poate păstra erorile anterioare.

Retryable depinde aici de încercările rămase la apariția erorii. Nu detectează automat o cauză temporară. Un ID greșit nu se repară prin repetare, chiar dacă mai este permisă o încercare.

Diferența principală: Sync Errors ajută la analiza cauzelor; Dead Letter Queue listează sarcinile cu încercări epuizate.

Scenariul 1: legarea firmei B2B de clientul ERP

Alfa are cont Magento și o fișă ERP existentă. Echipa vrea să evite duplicarea clientului.

1. Integratorul pregătește adaptorul ERP și profilul website-ului corect.
2. Mappings leagă firma 42 de ERP-C-0084.
3. Sarcina adaptorului folosește asocierea pentru înregistrarea existentă.
4. Operatorul verifică rezultatul și identificatoarele returnate în Sync Jobs.

Identitatea clientului rămâne coerentă. Câmpurile actualizate și sistemul lor sursă fac parte din domeniul convenit.

Scenariul 2: comanda B2B ajunge la ERP după întrerupere

Clientul comandă și mecanismul creează o sarcină de export. ERP este temporar inaccesibil. Adaptorul eșuează, eroarea se salvează și sarcina devine failed sau, după epuizare, dead.

După restabilire, operatorul verifică rezultatul anterior în ERP și planifică Retry pentru aceeași sarcină. Adaptorul trebuie să recunoască documentele existente pentru a evita duplicatele dacă cererea fusese acceptată, dar răspunsul s-a pierdut.

Rezultatul reușit poate include ID-ul documentului ERP, iar adaptorul poate salva o asociere. Conținutul și momentul depind de implementare.

Scenariul 3: actualizarea listei canalului B2B corect

ERP este sursa condițiilor comerciale. Canalul angro are profil de import și asocierea listei 7 cu ERP-PRICELIST-DEALERS.

Adaptorul citește ERP, verifică SKU-uri, moneda și pragurile și salvează după regulile Pricing. Sync Job urmărește operația; rezultatul poate sumariza pozițiile procesate. La probleme sunt disponibile contextul și mesajul.

Integrations gestionează fluxul; Pricing selectează prețul. Vezi listele B2B și Price List în Magento 2. Validarea, scrierile parțiale și actualizarea indexului trebuie definite în adaptor.

Scenariul 4: o eroare recurentă cere corectarea datelor

Sistemul de depozit refuză operația deoarece nu recunoaște produsul. Repetarea nu schimbă situația. Sarcina epuizează încercările și apare în Dead Letter Queue.

Operatorul deschide View Job, citește mesajul și verifică ID-urile. Dacă lipsește o legătură, corectează Mappings. După remediere alege Retry Job și verifică rezultatul următor.

Exemplul arată nevoia de asocieri și istoric. Coada permite revenirea la operație; diagnosticul indică ce trebuie reparat înaintea încercării.

Implementarea Integrations pas cu pas

1. Alege primul proces. Începe cu exportul comenzilor, nu cu toate domeniile simultan.
2. Stabilește sursele. Decide cine gestionează clientul, lista sau starea și cum se rezolvă conflictele.
3. Pregătește adaptorul și executantul. Definește operații, formate, autentificare, execuție și reîncercări.
4. Configurează Profiles și Mappings. Verifică website, direcție și ID-uri pe cazuri reale.
5. Testează succesul și erorile. Include API indisponibil, date invalide, cereri repetate și încercări epuizate.
6. Verifică rezultatul comercial. Confirmă înregistrarea corectă în destinație, nu doar starea.
7. Atribuie responsabilități. Stabilește cine urmărește Sync Errors și Dead Letter Queue și corectează datele ori conexiunea.

Evaluezi astfel operațiile corecte și timpul de remediere, nu doar existența conexiunii API.

Întrebări frecvente despre Integrations în B2B Suite

Un profil ERP oferă integrare gata pentru orice ERP?

Nu. Păstrează contextul și configurația. Un adaptor pentru API și procesele convenite asigură comunicarea.

Mappings transformă câmpurile de import?

Leagă identificatoare locale și externe. Transformarea câmpurilor și formatarea datelor aparțin adaptorului.

Retry trimite datele imediat?

Nu. Reprogramează sarcina existentă. Trimiterea sau preluarea are loc la următoarea execuție a procesului conectat.

Cum diferă Dead Letter Queue de Sync Errors?

Prima arată sarcini dead, al doilea erori cu context. Erorile operațiilor ulterior reușite pot rămâne în istoric.

Modulul reîncearcă automat la câteva minute?

Salvează termene, stări și contoare și oferă reîncercări. Programul, intervalele și selecția automată trebuie configurate în soluția de execuție.

Poate fi gestionată integrarea prin API?

API-ul B2B Suite gestionează profiluri, asocieri, publicarea, procesarea și reîncercarea sarcinilor, plus citirea sarcinilor, jurnalelor și erorilor. Necesită permisiuni și context website unde este folosit.

Integrare B2B sub controlul echipei

Profiles organizează configurația, Mappings identitățile, Sync Jobs progresul, iar Dead Letter Queue și Sync Errors eșecurile. Împreună formează o bază extensibilă pentru integrarea Magento 2 cu adaptoare potrivite firmei.

Descoperă Kowal B2B Suite pentru Magento 2 Open Source sau descrie procesul pe care vrei să-l conectezi la ERP, PIM, WMS sau CRM. Începe cu sistemul, direcția și o operație astăzi manuală.

Citește și: reducerea gestionării manuale a vânzărilor B2B și costul gestionării manuale a comenzilor B2B.