Perché CommerceML è deprecato e come sostituirlo

Tre mesi fa mi ha chiamato un conoscente, il proprietario di un'azienda all'ingrosso che vende oli e lubrificanti industriali. Catalogo da sedicimila posizioni, WooCommerce, sette anni di attività del sito, traffico stabile, gli ordini stanno arrivando. Sembrerebbe che vada tutto bene. Ma non ha chiamato perché la sua vita era bella. "Ascolta", dice, "il mio catalogo è di nuovo rotto. Lo scambio con 1C si è bloccato a metà, metà della merce era sparita, le foto erano sparite, i prezzi erano vecchi. I gestori controllano manualmente ogni articolo. Passiamo tre giorni a ripristinare ciò che avrebbe dovuto essere aggiornato in un'ora. Forse c'è qualcosa al posto di CommerceML, o è normale e tutti vivono così? "

Non gli ho detto che “vivono tutti così”. Perché non è vero. Così vivono le persone bloccate nel 2005, anno in cui è stato creato il formato CommerceML. Sì, hai sentito bene: la tecnologia che migliaia di negozi online utilizzano oggi per scambiare dati tra 1C e il sito è stata progettata ventuno anni fa. In un’epoca in cui l’iPhone non esisteva ancora, Google si era appena quotata in borsa e la parola “cloud” indicava un fenomeno esclusivamente atmosferico. E questo formato, nato in un'era tecnologica completamente diversa, rimane ancora lo standard de facto per l'integrazione di 1C con i negozi online in Russia e nella CSI. Penso che sia giunto il momento di avere una conversazione onesta sul perché è successo, sul perché non funziona più e su cosa fare al riguardo.

Non sono un teorico o un predicatore di alcuna tecnologia particolare. Ho vissuto con CommerceML per sette anni nella produzione reale, con i suoi difetti, interruzioni, prodotti duplicati e notti insonni in cui avevo urgentemente bisogno di sistemare il catalogo prima della spedizione mattutina. E ad un certo punto mi sono reso conto che era inutile trattare i sintomi: era necessario cambiare l'intero approccio. Questo articolo è la storia di come siamo arrivati a questa decisione, cosa abbiamo passato e cosa abbiamo ottenuto alla fine. Se anche tu stai lottando con lo scambio di 1C e del sito, forse ti farà risparmiare quegli stessi tre giorni di nervoso ripristino del catalogo.

Come siamo arrivati a questo punto della vita: sette anni su CommerceML

Per capire perché CommerceML è un problema, devi prima capire come funziona. L'idea è semplice: 1C genera file XML di una determinata struttura - catalogo prodotti, offerte (prezzi e saldi), immagini - e li carica sul sito tramite uno speciale script PHP. Il sito, a sua volta, analizza questi file XML e aggiorna il database. Sembra logico, vero? Nel 2005 era addirittura elegante. XML era di moda, l’API REST non era ancora diventata uno standard e i cataloghi dei negozi online raramente superavano le due migliaia di articoli.

Il problema è che il mondo è cambiato, ma CommerceML no. Il formato è rimasto quasi lo stesso di quando è stato creato. Sì, ci sono stati aggiornamenti minori, sì, è apparsa la versione 2.10, ma dal punto di vista architettonico è sempre lo stesso approccio: generare un XML gigante, trasferirlo interamente sul sito, analizzarlo interamente e aggiornare il database. È come inviare via email l'intero file a un collega ogni volta che desideri aggiornare una riga in un foglio di calcolo Excel di diecimila righe. Sembra assurdo? Ma è esattamente così che funziona CommerceML.

Quando abbiamo iniziato con questo progetto, il catalogo era composto da circa quattromila articoli. CommerceML ha fatto il lavoro. Lo scambio è durato dai quindici ai venti minuti, gli errori erano rari ed era vivibile. Abbiamo utilizzato uno dei plugin più popolari per WooCommerce: woocommerce-syncchronization-1c. Ha svolto il suo lavoro onestamente: ha accettato XML da 1C, lo ha analizzato, ha creato prodotti, ha aggiornato i prezzi. Nel corso di sette anni ha subito dozzine di aggiornamenti a WordPress, WooCommerce, PHP e ogni volta qualcosa si è rotto, ma nel complesso ha funzionato.

E poi il catalogo crebbe fino a sedicimila articoli. E si scatenò l'inferno.

La prima cosa che abbiamo riscontrato è stata l'ora di scambio. Lo scaricamento completo di un catalogo non richiedeva più venti minuti, ma due o tre ore. A volte quattro. Inoltre, CommerceML è progettato in modo tale che ogni scambio sia, di fatto, uno scarico completo. Sì, formalmente esiste un meccanismo di "scambio di modifiche", ma in pratica funziona in modo così inaffidabile che la maggior parte delle impostazioni 1C utilizza lo scarico completo. E immagina: ogni notte (e lo scambio deve essere impostato di notte, perché durante il giorno crea un carico sul server e rallenta il sito) 1C carica sedicimila prodotti in file XML per un volume totale di circa un gigabyte, quindi li carica sul server e lo script PHP tenta di elaborare il tutto. PHP, che per impostazione predefinita ha un limite di tempo di esecuzione dello script di trenta secondi e un limite di memoria di 256 megabyte. Naturalmente abbiamo aumentato i limiti, sia a 512 che a un gigabyte, ma queste sono stampelle, non una soluzione.

Il secondo riguarda i prodotti duplicati. Questo è forse il problema più doloroso di CommerceML e, per qualche motivo, poche persone ne parlano apertamente. Il meccanismo è questo: ogni prodotto in 1C ha un identificatore univoco (GUID). Durante il caricamento, questo GUID viene trasmesso al sito e il plug-in lo utilizza per cercare un prodotto esistente da aggiornare. Sembra affidabile? Non importa come sia. Non appena un prodotto in 1C cambia in un certo modo, ad esempio è stato spostato in un altro gruppo, o il tipo di articolo è stato modificato o si è verificata una sorta di riorganizzazione interna della directory, il GUID potrebbe cambiare. O, peggio ancora, rimangono gli stessi, ma il plugin non lo trova perché i meta campi non sono sincronizzati in WordPress. Risultato: sul sito appare un duplicato. Prodotto con lo stesso nome ma ID diverso. E quando hai sedicimila posizioni, è quasi impossibile catturare manualmente tali duplicati. Abbiamo riscontrato situazioni in cui lo stesso olio motore era presente sul sito in tre copie, con prezzi diversi, scorte diverse e URL diversi. Questo è un disastro per il SEO, confusione per gli utenti e grattacapo per i manager.

Il terzo problema sono le immagini. CommerceML fornisce immagini di prodotto insieme a file XML come allegati binari. In teoria, questo è conveniente: tutto è in un unico pacchetto. In pratica, con un catalogo di sedicimila posizioni, dove ogni prodotto ha da una a cinque immagini, il volume di scarico diventa mostruoso. Ma non è nemmeno questa la cosa principale. La cosa principale è il meccanismo di aggiornamento dell'immagine. CommerceML non dispone di un metodo affidabile per determinare se l'immagine di un prodotto è cambiata o meno. Pertanto, molte implementazioni ricaricano semplicemente tutte le immagini ad ogni scambio. Si tratta di gigabyte di traffico, ore di lavoro di script e, cosa più spiacevole, perdita periodica di immagini. Abbiamo scoperto regolarmente che le immagini di alcuni prodotti scomparivano dopo lo scambio. A volte a causa di un timeout, a volte per un errore di analisi, a volte senza una ragione apparente. I manager hanno trascorso ore a caricare manualmente le immagini che lo scambio “ha perso”.

Il quarto problema sono i campi personalizzati. Questo è ciò che alla fine mi ha convinto che dovevo terminare CommerceML. La nostra azienda vende oli e lubrificanti industriali, un prodotto con caratteristiche tecniche complesse. Viscosità a diverse temperature, punto di scorrimento, punto di infiammabilità, classe di viscosità ISO, approvazioni del produttore dell'attrezzatura, GOST o TU, tipo di base (minerale, sintetica, semisintetica), densità, area di applicazione: ogni prodotto ha dozzine di parametri specifici. In 1C, tutti questi parametri sono memorizzati come "dettagli aggiuntivi" - un sistema flessibile che consente di creare caratteristiche arbitrarie per qualsiasi tipo di articolo. Ora prova a trasmettere tutto questo attraverso CommerceML.

CommerceML ha uno schema rigido. Esiste un certo insieme di campi che può trasferire: titolo, descrizione, articolo, gruppo, immagini, prezzo, saldo e diversi dettagli standard. Campi personalizzati? Formalmente - attraverso il meccanismo delle “proprietà” e dei “valori immobiliari”. Ma l’implementazione è così rigida che in pratica è quasi impossibile trasmettere dati strutturati complessi – come diversi tipi di viscosità a diverse temperature – senza una seria personalizzazione dell’elaborazione sul lato 1C. E la personalizzazione dell'elaborazione richiede un programmatore 1C, che costa da tremila rubli l'ora e che deve spiegare la struttura del tuo sito. E ogni volta che aggiungi un nuovo parametro di prodotto in 1C, questa personalizzazione deve essere aggiornata. Un circolo vizioso.

Ricordo il momento in cui abbiamo provato ad aggiungere un nuovo attributo al sito: le approvazioni del produttore (ovvero un elenco di marche di apparecchiature per le quali questo olio è adatto). In 1C questo è stato memorizzato come una sezione tabellare che elenca le tolleranze. CommerceML semplicemente non sa come passare le parti della tabella. Abbiamo trascorso due settimane a negoziare con un programmatore 1C che ha provato a "impacchettare" questi dati in proprietà CommerceML standard, creando un sistema complesso di valori compositi, che poi dovevano essere analizzati dal lato del sito. Il risultato ha funzionato, ma era così fragile che si rompeva ogni secondo aggiornamento 1C.

E quinto: interrompe le directory di grandi dimensioni. Si tratta di un problema tecnico, ma ha implicazioni aziendali dirette. Lo script PHP che elabora l'XML da CommerceML funziona all'interno di una singola richiesta HTTP. Sì, molte implementazioni suddividono l'elaborazione in blocchi e utilizzano importazioni passo passo, ma il meccanismo di base rimane lo stesso: lo script deve leggere l'XML, analizzarlo, abbinarlo ai prodotti esistenti nel database, aggiornare o creare nuovi record, il tutto entro i limiti di PHP. Con un catalogo di sedicimila posizioni con decine di attributi per ogni prodotto, la sceneggiatura si bloccava regolarmente. A volte in modo silenzioso: semplicemente smetteva di funzionare a causa di un timeout, lasciando la directory in uno stato aggiornato a metà. A volte con errore di memoria. A volte a causa del blocco del database, perché sedicimila query INSERT/UPDATE consecutive creano un carico serio su MySQL. E ogni fallimento di questo tipo significava che alcuni prodotti venivano aggiornati, ma altri no. I prezzi di alcuni prodotti sono attuali, mentre altri sono quelli di ieri. Il resto è stato aggiornato in alcuni punti, non in altri. I gestori non sanno di quali dati sul sito ci si possa fidare. Gli acquirenti effettuano ordini per beni che non sono più disponibili. Questi non sono inconvenienti tecnici: si tratta di perdite di denaro e di reputazione.

Quando ho smesso di trattare i sintomi

Il punto è questo: per molto tempo ho cercato di risolvere ogni problema separatamente. Prodotti duplicati? Scriviamo uno script per controllare i duplicati. Immagini perse? Aggiungiamo la registrazione e il ricaricamento. Timeout? Aumentiamo i limiti PHP e dividiamo l'exchange in porzioni più piccole. Campi personalizzati? Assumeremo un programmatore 1C per personalizzare l'elaborazione. Ogni volta, un'altra toppa sulla vecchia coperta. E ogni patch aggiungeva complessità, creava nuovi punti deboli e richiedeva supporto. A un certo punto avevamo un sistema di scambio così personalizzato che nessun nuovo sviluppatore sarebbe riuscito a capirlo senza una settimana di immersione. Ovviamente non c'era documentazione, perché il sistema è cresciuto in modo organico, di problema in problema, e nessuno aveva previsto che diventasse così complesso.

La svolta decisiva è arrivata quando abbiamo perso un grosso ordine. Un cliente aziendale ha ordinato un lotto di olio idraulico: duecento litri, una quantità decente. Il sito mostrava “in stock” perché ieri sera lo scambio con 1C si è bloccato e i saldi non sono stati aggiornati. Ma in realtà quest'olio non era più nel magazzino: era stato spedito a un altro cliente il giorno prima. Il manager ha chiamato il cliente, si è scusato e si è offerto di attendere la consegna: il cliente ha rifiutato ed è andato da un concorrente. Non perché abbiamo un prodotto scadente o prezzi elevati, ma perché il nostro sistema di scambio dati non è stato in grado di aggiornare in tempo il saldo di un prodotto. Ho allora pensato: quanti di questi casi nemmeno notiamo? Quanti clienti vedono "in stock", aggiungono l'articolo al carrello e poi il manager li richiama con le scuse? E quanti di loro se ne vanno semplicemente in silenzio senza lasciare un ordine?

È stato allora che ho iniziato a cercare seriamente delle alternative. Non un altro plugin per CommerceML: ce ne sono molti, ma sono tutti limitati dalle capacità del formato stesso. E su un approccio fondamentalmente diverso all'integrazione di 1C e del sito. E qui ho notato per la prima volta OData.

Per coloro che non l'hanno trovato: OData è un protocollo standard per la creazione e l'utilizzo delle API REST. È stato sviluppato da Microsoft ed è ampiamente utilizzato in tutto il mondo per accedere ai dati. La parola chiave qui è “standard”. Questo non è un formato proprietario di un'azienda, né una soluzione improvvisata per un compito specifico. È un protocollo aperto con specifiche chiare, supporto per impaginazione, filtri, ordinamento, selezione di campi specifici: tutto ciò che ti aspetteresti da un'API moderna. Ed ecco cosa è importante: 1C supporta OData immediatamente. A partire dalla versione 8.3, qualsiasi configurazione 1C può fornire l'accesso ai propri dati tramite l'interfaccia OData. Senza elaborazione aggiuntiva, senza componenti di terze parti: abilita semplicemente la pubblicazione OData nelle impostazioni del server web 1C e otterrai un'API REST completa per tutte le directory, documenti e registri del tuo database.

Quando ho provato per la prima volta a interrogare un catalogo di articoli tramite OData, sono rimasto stupito. Invece di aspettare che 1C generasse un file XML delle dimensioni di un gigabyte, ho inviato una richiesta HTTP e un secondo dopo ho ricevuto JSON con i primi cento prodotti. Ho inviato la seguente richiesta e ho ricevuto le successive cento. E ogni richiesta ha restituito esattamente i dati di cui avevo bisogno: non l'intero catalogo, ma campi specifici per prodotti specifici, filtrati secondo criteri specifici. Potrei chiedere “dammi tutti i prodotti del gruppo Oli Idraulici che hanno cambiato prezzo nelle ultime due ore” e ricevere una risposta in un paio di secondi. Provalo con CommerceML.

Ma non permettetemi di idealizzare. OData non è un pulsante magico "fai bene". Si tratta di uno strumento che richiede un approccio diverso all’integrazione. E passare ad esso non significa semplicemente sostituire un plugin con un altro. Questo è un cambiamento nell'architettura dello scambio di dati tra 1C e il sito. Scopriamo qual è la differenza fondamentale.

CommerceML funziona secondo il principio del "caricamento batch". 1C genera un pacchetto di dati (file XML), lo carica sul sito e il sito lo elabora. Si tratta di un'operazione batch, unidirezionale e offline. 1C non sa cosa sta succedendo sul sito. Il sito non sa cosa succede in 1C tra gli scambi. I dati vengono sincronizzati con un ritardo, da un'ora a un giorno, a seconda della pianificazione. OData funziona diversamente. Questa è un'API, un'interfaccia di programmazione per l'accesso diretto ai dati. Dal sito è possibile accedere a 1C in qualsiasi momento e ricevere informazioni aggiornate: il prezzo attuale del prodotto, il saldo attuale del magazzino, l'elenco delle caratteristiche, le immagini. Non è necessario attendere il caricamento, non è necessario analizzare XML, non è necessario archiviare file intermedi. I dati sono disponibili in tempo reale.

E qui sorge la prima domanda che tutti mi fanno: "E il carico su 1C? Se il sito tira costantemente richieste 1C, ucciderà il database!" Domanda giusta. Risposta: non è necessario estrarre 1C ogni volta che visualizzi un prodotto sul sito. L'architettura corretta sembra diversa. I dati del prodotto vengono importati da 1C nel database del sito tramite OData, esattamente come con CommerceML. La differenza è che con OData puoi farlo in modo incrementale. Non scaricare l’intero catalogo, ma richiedere solo modifiche: “dammi prodotti la cui data di modifica è superiore all’orario dell’ultima sincronizzazione”. Per un catalogo di sedicimila articoli, dove in genere cambiano da dieci a venti articoli all'ora, ciò significa elaborare da dieci a venti voci invece di sedicimila. La differenza di prestazioni è di due o tre ordini di grandezza.

Ora aggiungi i webhook a questo. Il webhook è un meccanismo in cui 1C stesso notifica al sito le modifiche. Il prezzo del prodotto è cambiato? 1C invia una richiesta POST al sito: "prodotto tale e tale, nuovo prezzo tale e tale". Lo stock in magazzino è stato aggiornato? Un'altra richiesta POST. Il sito riceve una notifica e aggiorna il prodotto specifico entro pochi millisecondi. Non è necessario attendere gli scambi programmati, né scorrere l'intera directory alla ricerca di modifiche. I dati sul sito sono aggiornati in tempo reale, con un ritardo di secondi, non di ore. Ricordi quel caso con l'ordine perso a causa di saldi scaduti? Non accadrebbe con i webhook. Il saldo verrà aggiornato sul sito Web nel momento in cui la merce viene spedita in 1C.

Devo essere sincero: impostare webhook da 1C non è un compito banale. Nelle configurazioni scatolate (UT, ERP, KA) non esiste tale meccanismo. Devi scrivere un abbonamento a un evento in 1C, che invierà una richiesta HTTP quando un prodotto cambia, oppure utilizzare un'estensione. Utilizziamo un'estensione che viene attivata quando vengono elaborati documenti che influiscono su saldi e prezzi e invia una notifica al sito. Lo sviluppo ha richiesto un paio di giorni, ma ne vale la pena: ora il resto del sito viene aggiornato entro cinque-dieci secondi dalla pubblicazione del documento in 1C. I gestori hanno smesso di controllare manualmente la pertinenza dei dati sul sito. I clienti hanno smesso di ricevere chiamate di scuse. Non si tratta solo di un miglioramento tecnico: si tratta di un cambiamento qualitativo nel modo in cui opera l'azienda.

Mappatura che non si rompe ad ogni starnuto

Uno degli argomenti più dolorosi nell'integrazione di 1C e del sito è la corrispondenza dei campi. In 1C i dati vengono archiviati in una struttura, sul sito web in un'altra. CommerceML propone uno schema rigido: il nome del prodotto è nel campo “Nome”, la descrizione è nel campo “Descrizione”, l'articolo è nel campo “Articolo” e così via. Se la struttura dei dati differisce anche leggermente da quanto presupposto da CommerceML, iniziano i problemi.

Ecco un esempio specifico tratto dalla nostra pratica. In 1C, il nostro prodotto “Olio idraulico HVLP 46” ha il nome completo “Olio idraulico HVLP 46 (barile da 200 l)” e il nome abbreviato “HVLP 46”. CommerceML trasmette un campo "Nome": quale? L'impostazione predefinita è piena. Ma sul sito vogliamo mostrare un nome nel titolo del prodotto, un altro nel catalogo e un terzo nel breadcrumb. Con CommerceML, per questo è necessario modificare l'elaborazione di scarico in 1C, oppure analizzare le stringhe lato sito, estraendo il volume e l'unità di misura dal nome completo. Entrambe le opzioni sono stampelle. Con OData, interrogo semplicemente entrambi i campi: "Descrizione" e "NomeFull" e li mappo ai campi WooCommerce richiesti. Uno nel titolo, l'altro nel meta campo. Nessuna personalizzazione 1C, nessuna analisi delle stringhe, nessun normale fragile.

Ma questo è un semplice esempio. La situazione con dettagli aggiuntivi è molto più interessante. Come ho già detto, in 1C i nostri prodotti hanno dozzine di caratteristiche tecniche. Viscosità, densità, temperature, tolleranze: tutto questo è memorizzato nella parte tabellare "Dettagli aggiuntivi" dell'articolo articolo. Ogni attributo ha una chiave (GUID del tipo caratteristica) e un valore (stringa, numero o collegamento a un elemento della directory). CommerceML non sa come lavorare direttamente con questa struttura: è necessario un programmatore 1C che scriva un'elaborazione che "espanda" la parte tabulare nel set di proprietà CommerceML. E ogni volta che viene aggiunto un nuovo attributo a 1C, questa elaborazione deve essere aggiornata.

Non è così con OData. OData fornisce dettagli aggiuntivi come array annidati di oggetti, ciascuno con una chiave e un valore. Sul lato del sito, leggiamo semplicemente questo array e mappiamo ciascun attributo all'attributo WooCommerce corrispondente. E qui arriva la parte divertente: il rilevamento automatico. Il nostro modulo, quando si connette a 1C per la prima volta tramite OData, esegue automaticamente la scansione dei metadati del database, trova tutti i tipi di caratteristiche del prodotto e offre la mappatura: "Trovato 99 caratteristiche uniche in 1C. Eccole. Quali dovrei creare come attributi WooCommerce? Che tipo di meta campi? Quali dovrei ignorare? Hai impostato la corrispondenza una volta e poi funziona automaticamente. Hai aggiunto un nuovo attributo "Classe di pulizia NAS" a 1C? Durante la successiva sincronizzazione, il modulo rileverà un nuovo attributo e offriti di crearne un attributo sul sito Senza un programmatore 1C, senza aggiornare l'elaborazione, senza configurazione manuale.

Abbiamo trovato 99 caratteristiche uniche nel database 1C e da esse abbiamo creato 121 tassonomie in WooCommerce. Perché 121 e non 99? Poiché alcune caratteristiche avevano più valori (ad esempio, le “approvazioni del produttore” contenevano più valori per un singolo prodotto) e per tali caratteristiche era più conveniente creare tassonomie separate con funzionalità di scelta multipla. Con CommerceML, tale flessibilità semplicemente non esiste: ottieni ciò che fornisce l'elaborazione del caricamento e non puoi modificare la logica di mappatura al volo.

Vorrei dire qualcosa anche sulla personalizzazione. In CommerceML, la mappatura viene integrata nel codice del plug-in o nell'elaborazione 1C. Se vuoi cambiare quale campo 1C va dove sul sito, devi andare nel codice PHP o nella configurazione 1C. Con OData, la mappatura è un'impostazione nel pannello di amministrazione del sito. Vedi una tabella: a sinistra ci sono i campi 1C, a destra ci sono i campi WooCommerce. Trascina, modifica, aggiungi regole di trasformazione (ad esempio, “se il valore del campo “Tipo olio” è “Minerale”, scrivi il valore “Minerale” nell'attributo “Tipo base”). Le modifiche vengono applicate istantaneamente, senza distribuire codice, senza riavviare lo scambio. Questo è qualcosa che può fare un gestore del catalogo, non solo uno sviluppatore.

Mi sono chiesto perché CommerceML sia rimasto lo standard per così tanto tempo, nonostante tutte le sue limitazioni. E sono giunto alla conclusione che la ragione è l'inerzia. CommerceML è integrato nelle configurazioni 1C standard. Funziona "fuori dagli schemi": accendi lo scambio, specifica l'indirizzo del sito, premi il pulsante. Non è necessario comprendere l'API, né scrivere codice. Per un piccolo negozio con un paio di centinaia di prodotti, questo è davvero sufficiente. Ma quando il catalogo cresce, quando compaiono attributi complessi, quando un'azienda ha bisogno di rilevanza dei dati in tempo reale, i limiti di CommerceML iniziano a costare denaro. Soldi veri - sotto forma di ordini persi, lavoro manuale dei manager e pagamento per ore di programmatori 1C.

Come si presenta la transizione nella pratica

Capisco che a questo punto il lettore si starà chiedendo: "Okay, OData è meglio di CommerceML, ho capito. Ma come fare? Ho già impostato uno scambio, i prodotti sono sincronizzati, il catalogo funziona. Dobbiamo davvero smontare tutto e ricostruirlo?"

No, non è necessario. E questo è forse l’argomento principale a favore dell’approccio OData: la transizione può avvenire gradualmente. Non disabiliti CommerceML il primo giorno. Colleghi il modulo OData in parallelo, imposti la mappatura, esegui la sincronizzazione di prova, confronti i risultati e solo quando sei sicuro che tutto funzioni correttamente, disabiliti il ​​vecchio scambio.

Questo è esattamente ciò che abbiamo fatto. La prima fase è la connessione a OData 1C e la migrazione delle connessioni esistenti. Avevamo 16.844 prodotti nel nostro database WordPress, ognuno dei quali aveva un meta campo_id_1ccon il vecchio ID di CommerceML. Il modulo ha esaminato tutti i prodotti, li ha confrontati con i record in 1C tramite OData e ha creato una mappatura in una tabella separata: 18.850 record (comprese le variazioni). Questo processo ha richiesto circa due ore, ma è stata un'operazione una tantum.

Il secondo passaggio consiste nel configurare la sincronizzazione incrementale. Abbiamo configurato il modulo OData per aggiornare solo i prodotti modificati. Ogni quindici minuti il ​​modulo chiede a 1C: “Quali prodotti sono cambiati dall’ultimo controllo?” OData ti consente di effettuare tale richiesta in una riga: filtra per data di modifica. La risposta è un JSON con dieci o venti prodotti, che vengono aggiornati in WooCommerce in pochi secondi. Confrontalo con il caricamento di un catalogo completo tramite CommerceML, che ha richiesto tre ore.

La terza fase prevede la configurazione dei webhook per i dati critici. Prezzi e saldi ora arrivano istantaneamente al sito, tramite richieste POST da 1C. Ciò ha richiesto una piccola modifica sul lato 1C, un'estensione che viene attivata quando si registrano documenti di vendita, ricevute e aggiustamenti di prezzo. Ma questa modifica viene eseguita una volta e poi funziona automaticamente.

Fase quattro: disabilitazione di CommerceML. Lo abbiamo fatto un mese dopo il lancio del modulo OData, quando eravamo convinti che tutti i dati fossero sincronizzati correttamente. Abbiamo disattivato il vecchio plugin woocommerce-syncchronization-1c e disabilitato l'elaborazione dello scambio in 1C. Il sito ha continuato a funzionare come se nulla fosse successo, perché i dati ora arrivavano in modo diverso.

Cosa abbiamo ottenuto come risultato? Diamo un'occhiata a numeri specifici. Il tempo per la sincronizzazione completa della directory è stato ridotto da tre-quattro ore a venti minuti, mentre la sincronizzazione completa è necessaria solo durante la configurazione iniziale o dopo modifiche importanti nella struttura della directory 1C. In modalità normale, c'è un aggiornamento incrementale che richiede pochi secondi. Il ritardo nell'aggiornamento dei prezzi e dei saldi è diminuito da un giorno (cambio una volta al giorno) a secondi (webhook). Il numero di duplicati del prodotto per tre mesi è pari a zero. Perché OData utilizza identificatori 1C stabili (Ref_Key), che non cambiano quando un prodotto viene spostato tra gruppi o quando le sue proprietà cambiano. Il numero di immagini perse è zero. Perché le immagini vengono caricate tramite un endpoint separato, con l'hash del file controllato e vengono aggiornate solo quando si verifica una modifica effettiva. Il numero di chiamate a un programmatore 1C per personalizzare uno scambio è pari a zero negli ultimi sei mesi. Perché la mappatura è configurata nel pannello di amministrazione del sito e il rilevamento automatico trova automaticamente nuovi dettagli.

Ma al di là dei numeri, c'è un altro cambiamento difficile da quantificare, ma che potrebbe essere ancora più importante. I manager non hanno più paura del catalogo. In precedenza, la mattina di ogni giornata lavorativa iniziava con un controllo: "lo scambio è andato a buon fine? è tutto a posto? I prezzi sono attuali? Ora funzionano e basta. I dati sul sito sono sempre aggiornati, i prodotti non vengono persi o duplicati, gli attributi vengono aggiornati automaticamente. Ciò ha liberato una notevole quantità di tempo di lavoro che prima veniva dedicato al controllo manuale e alla correzione degli errori di scambio.

Separatamente, vorrei parlare della procedura guidata di configurazione, quella che chiamiamo procedura guidata. Uno dei motivi per cui CommerceML è così popolare è la sua facilità di configurazione iniziale. Ho attivato lo scambio in 1C, ho specificato l'indirizzo: funziona. Per OData, la soglia di ingresso è più alta: è necessario abilitare la pubblicazione OData sul server Web 1C, configurare i diritti utente e comprendere gli endpoint. Abbiamo dedicato molto tempo cercando di abbassare questa soglia e alla fine abbiamo creato una procedura guidata passo passo che guida l'utente attraverso l'intera configurazione in quindici minuti. Il primo passaggio consiste nel fornire l'URL e le credenziali OData. La procedura guidata verifica la connessione, mostra la versione 1C e il nome del database. Il secondo passo è selezionare i libri di consultazione per la sincronizzazione (nomenclatura, caratteristiche, unità di misura). La procedura guidata esegue la scansione dei metadati 1C e mostra le entità disponibili. Il terzo passaggio consiste nel configurare la mappatura dei campi. La procedura guidata propone una mappatura predefinita (che copre il 90% dei casi) e dà la possibilità di modificarla. Il quarto passaggio consiste nell'eseguire un'importazione di prova di dieci prodotti e verificare il risultato. Il quinto passaggio consiste nell'eseguire un'importazione completa. Tutto. Quindici minuti, nessun programmatore 1C, nessuna impostazione di elaborazione.

A dire il vero, quando abbiamo mostrato questo Wizard ai primi utenti, la reazione è stata inaspettata. Mi aspettavo domande come "dov'è l'impostazione di caricamento in 1C?" o “come posso modificare l’elaborazione dello scambio?” Invece, le persone chiedevano: "Aspetta, è tutto? Ho appena indicato l'indirizzo e ha trovato la mia merce da solo? Dov'è il trucco? Non c'è nessun problema. OData è un'interfaccia 1C standard che fornisce dati in un formato strutturato. Non è necessario configurare nulla sul lato 1C (tranne per abilitare la pubblicazione OData e creare un utente con i diritti necessari). Tutte le impostazioni sono sul lato del sito, nel familiare pannello di amministrazione di WordPress.

Conversazione onesta sui contro

Sarei disonesto se presentassi l'approccio OData come una soluzione senza inconvenienti. Ha i suoi limiti e dovrebbero essere discussi apertamente.

Innanzitutto, OData in 1C non è l'ideale. È più lento delle query dirette al database 1C perché funziona su HTTP e passa attraverso un livello di logica aziendale. Per una query su una directory con centinaia di migliaia di elementi, ciò può essere evidente. Risolviamo questo problema tramite l'impaginazione: richiediamo dati in porzioni di 300 record ed elaboriamo ciascuna porzione tramite l'Action Scheduler (programmatore di attività integrato in WooCommerce). Ciò consente di distribuire il carico nel tempo e di non bloccare né 1C né il sito.

In secondo luogo, non tutti i dati sono accessibili tramite OData in modo altrettanto conveniente. Ad esempio, le directory subordinate (come "Caratteristiche articolo" in UT) potrebbero non supportare le operazioni di filtraggio e selezione dei campi standard. Ci troviamo di fronte al fatto che una richiesta con parametri$selezionao$filtroha restituito HTTP 400 alla directory delle caratteristiche. Ho dovuto scaricare tutti i record e filtrarli sul lato PHP. Non è fondamentale, ma è necessario essere consapevoli di tali funzionalità.

Terzo, le immagini. OData in 1C non invia dati binari di file allegati tramite un endpoint standard/$valore. Almeno non ha funzionato nella nostra configurazione. Ho dovuto utilizzare un'estensione aggiuntiva (servizio HTTP) per ricevere i file immagine. Questo non è tecnicamente difficile, ma richiede modifiche minime sul lato 1C.

In quarto luogo, anche i webhook richiedono miglioramenti 1C. Le configurazioni tipiche non dispongono di un meccanismo integrato per l'invio di notifiche in caso di modifica dei dati. Devi scrivere un'estensione. Per una persona che ha familiarità con 1C, questo è un compito che richiederà diverse ore, ma per coloro che lavorano solo con il sito Web e non toccano 1C, questa è un'ulteriore barriera. Tuttavia, i webhook sono facoltativi: puoi lavorare solo con la sincronizzazione incrementale tramite OData, solo con un ritardo di aggiornamento dei dati leggermente più lungo.

Quinto: OData richiede che un servizio web sia pubblicato sul server 1C. Ciò significa che IIS o Apache devono essere configurati per servire le richieste HTTP al database 1C. Sulla maggior parte dei server 1C ciò è già stato fatto (ad esempio, per un thin client tramite Web), ma ci sono casi in cui la pubblicazione Web non è configurata. Quindi è necessario coinvolgere un amministratore 1C per la configurazione iniziale.

Tutte queste limitazioni sono reali, ma nessuna supera i vantaggi di OData rispetto a CommerceML. È come paragonare un'auto elettrica a una locomotiva a vapore: sì, un'auto elettrica ha bisogno di caricare la batteria, e ci sono comunque meno stazioni di ricarica che stazioni di benzina. Ma questo non significa che devi continuare a guidare una locomotiva a vapore, perché la legna da ardere può essere trovata in qualsiasi foresta.

Un'altra domanda che viene posta spesso: "Cosa succede se ho un sito web Bitrix/OpenCart/personalizzato e non WooCommerce?" OData è un protocollo universale. Non è legato a WordPress o WooCommerce. Qualsiasi piattaforma in grado di inviare richieste HTTP e analizzare JSON può funzionare con OData 1C. Il modulo specifico di cui sto parlando è implementato come parte di un plugin WooCommerce, ma i principi sono gli stessi: API REST invece di file XML, aggiornamenti incrementali invece di scarico completo, mappatura personalizzata invece di uno schema rigido. Se lavori con un'altra piattaforma, cerca soluzioni simili o implementa tu stesso l'integrazione, poiché OData fornisce un'API pulita e documentata.

E se lo guardassi dall'altro lato, dal lato degli affiliati 1C e degli sviluppatori 1C? Ho parlato con diversi partner 1C e la loro reazione all'approccio OData è stata contrastante. Da un lato comprendono i limiti di CommerceML: li sperimentano personalmente ogni giorno. D'altra parte, CommerceML è il loro pane quotidiano. Personalizzare l'elaborazione dello scambio, impostare i caricamenti, correggere gli errori di sincronizzazione: queste sono ore regolarmente retribuite. Il passaggio a OData li priva di parte dei loro guadagni, perché il cliente può impostare l'integrazione da solo, senza programmatore 1C. Questa non è una cospirazione o una cattiveria, ma solo una realtà economica. Ma per un’azienda che paga per l’integrazione, questo è un argomento a favore di OData: meno dipendenza da un appaltatore, minori costi di supporto, maggiore controllo.

Sapete cosa mi sorprende di più di tutta questa storia? I vantaggi non tecnici di OData sono evidenti a chiunque abbia anche una minima conoscenza delle tecnologie web. Sono sorpreso che la transizione abbia richiesto così tanto tempo. Abbiamo lottato con CommerceML per sette anni, conoscendone i limiti, e ogni volta abbiamo trovato un motivo per non cambiare il nostro approccio. “Non è il momento”, “funziona, non toccarlo”, “e se peggiorasse?” Ragioni classiche per mantenere lo status quo. È stato solo quando la perdita di un ordine specifico ha reso evidente il costo dell’inazione che abbiamo finalmente fatto il grande passo.

C'è un altro aspetto di cui si parla raramente, ma che in pratica risulta essere di fondamentale importanza: il debugging e la diagnosi dei problemi. Quando qualcosa si rompe nello scambio CommerceML (e si rompe regolarmente), la diagnosi si trasforma in un romanzo poliziesco. Un file XML di decine di megabyte in cui è necessario trovare il nodo problematico. Log PHP che dicono solo "Errore di analisi" senza specificare una posizione specifica. Registri 1C che scrivono "Scambio completato con errori" - e che tipo di errori, scoprilo tu stesso. Abbiamo passato ore a cercare di capire perché un prodotto specifico non era stato aggiornato o perché un gruppo specifico di prodotti aveva perso le immagini. A volte il motivo si rivelava banale, ad esempio un carattere speciale nel nome del prodotto che interrompeva il parser XML. A volte è misterioso, legato all'ordine di elaborazione dei file o ai fusi orari del server.

La diagnostica è trasparente con OData. Invii una richiesta specifica e ricevi una risposta specifica. Errore? È in una risposta HTTP con codice e descrizione chiari. Prodotto non aggiornato? Guarda la richiesta e la risposta nel registro: tutto è visibile. Registriamo ogni operazione di sincronizzazione in una tabella separata (wpaic_1c_sync_log) con i dettagli: quale prodotto, quali campi sono stati aggiornati, quanto tempo è stato impiegato, se si è verificato un errore. Il manager può andare al pannello di amministrazione e vedere la cronologia di sincronizzazione di ciascun prodotto. Questa non è solo comodità: è un altro livello di controllo sul processo.

Ed ecco qualcos'altro che ho notato dopo la transizione. Quando i dati sul sito sono sempre aggiornati, quando lo scambio funziona in modo affidabile e prevedibile, l'atteggiamento dell'intero team nei confronti del sito cambia. In precedenza, il sito veniva percepito come “una vetrina che a volte mostra i dati corretti”. I gestori hanno duplicato le informazioni in Excel perché “il sito non può essere considerato attendibile”. I clienti hanno chiamato per verificare la disponibilità perché "potrebbe non essere aggiornato sul sito web". Ora il sito è una fonte di verità. I manager ne fanno riferimento quando comunicano con i clienti. I clienti effettuano gli ordini da soli senza essere richiamati. La direzione esamina l'analisi delle vendite sul sito Web, sapendo che i dati sono affidabili. È difficile sopravvalutare questo cambiamento: influisce sull'efficienza dell'intera azienda e non solo sul lavoro del reparto IT.

Voglio anche affrontare la questione della sicurezza perché emerge spesso nelle conversazioni sulla sostituzione di CommerceML. "OData consente l'accesso al database 1C tramite Internet: questa è una falla nella sicurezza!" Una giusta preoccupazione, ma scopriamolo. CommerceML funziona anche tramite HTTP: lo stesso script PHP sul sito che accetta XML da 1C è accessibile da Internet. E spesso è protetto solo da login e password, che vengono trasmessi in chiaro. OData può essere configurato in modo più sicuro: HTTPS con TLS obbligatorio, autenticazione tramite Basic Auth o OAuth, limitazione dell'accesso tramite indirizzo IP, un utente 1C separato con diritti minimi (solo lettura delle directory necessarie). Inoltre, è possibile utilizzare una VPN tra i server 1C e quelli del sito Web, chiudendo completamente l'endpoint OData dall'accesso esterno. Quindi, dal punto di vista della sicurezza, OData rappresenta un passo avanti anziché indietro.

Sono sicuro che tra tre o cinque anni CommerceML diventerà anacronistico quanto lo è oggi il caricamento di file FTP su un hosting o il layout di un foglio di calcolo. La tecnologia si evolve, le esigenze del business crescono e il format creato ventuno anni fa per un mondo che non esiste più lascerà inevitabilmente il posto ad approcci moderni. L'unica domanda è se effettuerai questa transizione adesso o aspetterai finché non perderai il tuo "grosso ordine".

Se attualmente stai lavorando con CommerceML e hai identificato i tuoi problemi in questo articolo, allora sei pronto per un cambiamento. Non è necessario aver paura della transizione. Non è necessario rompere ciò che funziona in un giorno. Inizia in piccolo: abilita OData sul tuo server 1C, prova a inviare la prima richiesta, guarda i dati del tuo catalogo in formato JSON. Vedrai i tuoi prodotti, i tuoi prezzi, i tuoi dettagli - solo in un formato comodo, leggibile e moderno. E poi capirai che non ci sarà alcun ritorno ai file XML di dimensioni gigabyte.

Abbiamo raccolto tutta la nostra esperienza, sia positiva che negativa, in un modulo di integrazione 1C tramite OData per WooCommerce. Procedura guidata di configurazione, attributi di rilevamento automatico, sincronizzazione incrementale, supporto webhook, mappatura flessibile dei campi: tutto ciò di cui ho parlato in questo articolo. Se sei interessato a vedere come funziona nella pratica, dai un'occhiata alla pagina dei moduli sul nostro sito web. E se hai domande sull’integrazione di 1C e WooCommerce, scrivi, sono sempre felice di condividere la mia esperienza. Perché ogni negozio che si allontana da CommerceML rende l’intero mercato dell’e-commerce un po’ più moderno.