Add-ons

I requisiti di migrazione si collocano spesso tra due estremi. La migrazione supportata standard può essere strutturalmente adatta, ma l’azienda può comunque aver bisogno di un controllo più preciso su quali record trasferire, dove devono arrivare determinati valori o come modificare alcuni valori prima che raggiungano lo store di destinazione. È questo il ruolo degli Add-ons nei servizi di migrazione Next-Cart.

La decisione importante non consiste semplicemente nel capire se il nome di un Add-on sembra pertinente. Ogni Add-on risolve un tipo diverso di problema nella gestione dei dati e più Add-ons possono lavorare insieme quando un requisito di migrazione comprende più fasi. Comprendere queste differenze aiuta a separare le funzionalità supportate aggiuntive dal lavoro più ampio che appartiene a Custom Service.

Gli Add-ons risolvono problemi circoscritti di gestione dei dati

Gli Add-ons estendono il comportamento di migrazione supportato senza modificare il percorso di migrazione fondamentale. Un buon requisito per un Add-on parte dal risultato aziendale da ottenere e identifica poi l’operazione specifica necessaria per raggiungerlo.

Quattro domande distinguono chiaramente gli Standard Add-ons:

Quali record devono continuare nel processo di migrazione? È una domanda per Data Filter.
Quale campo di destinazione compatibile deve ricevere un campo di origine supportato? È una domanda per Advanced Data Mapping.
Il requisito richiede la mappatura supportata di campi o colonne database quando sia la piattaforma di origine sia quella di destinazione sono Open-Source? È una domanda per Advanced Database Mapping.
Come deve essere modificato il valore di un campo selezionato sulla destinazione durante la migrazione? È una domanda per Data Transformation.

Queste funzioni sono collegate, ma non sono intercambiabili. Il filtraggio cambia l’insieme dei record che partecipano. La mappatura cambia la destinazione. La mappatura database può operare sul livello sottostante del database nei limiti supportati. La trasformazione modifica il valore selezionato sulla destinazione.

Quattro Standard Add-ons, quattro decisioni diverse

I quattro Standard Add-ons si comprendono meglio osservando quale livello del risultato di migrazione controllano. Non sono quattro varianti della stessa funzione. Uno decide quali record partecipano, due decidono dove vengono rappresentati i valori supportati e uno decide quale valore finale deve risultare sulla destinazione.

Standard Add-on	Ruolo principale	Segnale di forte compatibilità	Ruolo in un flusso combinato	Prezzo fisso
Data Filter	Sceglie quali record migrare applicando condizioni supportate basate sui campi a un tipo di dati.	L’azienda ha bisogno soltanto di un sottoinsieme definito dei record altrimenti idonei.	Viene eseguito per primo e stabilisce la popolazione di record che ogni Add-on successivo riceverà.	$50
Advanced Data Mapping	Rimappa un campo di origine supportato verso un campo di destinazione compatibile senza modificare il valore nell’operazione di mappatura.	Il valore di origine è già corretto, ma deve essere collocato in un diverso campo di destinazione supportato.	Viene eseguito dopo il filtraggio e stabilisce le destinazioni dei campi supportati prima della mappatura a livello database.	$50
Advanced Database Mapping	Mappa campi supportati e colonne database sottostanti verso campi o colonne di destinazione compatibili, compresi campi di piattaforma e personalizzati idonei.	Il requisito dipende dalla rappresentazione a livello database e non soltanto dal livello dei campi supportati.	Viene eseguito dopo Advanced Data Mapping e può stabilire il valore o la destinazione che Data Transformation riceve nella fase successiva. È disponibile soltanto quando entrambe le piattaforme sono Open-Source.	$100
Data Transformation	Trasforma i valori di campi selezionati sulla destinazione durante la migrazione.	Il valore finale sulla destinazione deve essere ricalcolato, normalizzato, riformattato o modificato in altro modo da una regola supportata.	Viene eseguito per ultimo e lavora sul valore disponibile sulla destinazione dopo le fasi di mappatura.	$50

La tabella è utile perché lo stesso requisito aziendale può contenere più di uno di questi segnali. Una richiesta come “migrare soltanto questi Products, collocare un valore di origine in un campo diverso, usare un valore database personalizzato per il Price e poi applicare un margine” non è un unico problema generico di personalizzazione. È composta da quattro operazioni distinte che possono essere valutate separatamente e poi combinate nell’ordine di elaborazione previsto.

Data Filter: controllare quali record partecipano

Data Filter è il punto di partenza corretto quando l’azienda può descrivere quali record devono far parte del risultato di migrazione mediante condizioni supportate basate sui campi.

Domande tipiche includono:

Devono essere inclusi soltanto i Products attivi?
Gli Orders devono essere limitati a un periodo aziendale definito o a una determinata condizione di stato?
Devono proseguire soltanto i Customers che soddisfano una condizione concordata su un campo?
Un tipo di dati di contenuto deve essere limitato ai record rilevanti per il nuovo store?

Il confine importante è che Data Filter modifica la partecipazione dei record, non il campo di destinazione o il valore del record. Un Product escluso dal filtro non raggiunge le fasi Add-on successive per quell’ambito di migrazione. Un Product che supera il filtro prosegue con i propri dati supportati disponibili per le successive fasi di mappatura e trasformazione.

Questo rende Data Filter particolarmente importante nei requisiti combinati. Se una regola di mappatura o trasformazione successiva deve riguardare soltanto una parte del catalogo, il filtraggio definisce prima quella popolazione, invece di chiedere a un Add-on successivo di distinguere record che non è progettato per selezionare.

Gli Entity Points restano un concetto separato di capacità. Products, Customers, Orders e Blog Posts possono consumare Entity Points in base ai rispettivi pesi, ma una quantità di Entity Points non identifica quali singoli record devono essere migrati. Data Filter risolve proprio questa decisione di selezione.

Esempi autonomi di utilizzo di Data Filter

Esempio: migrare soltanto Products abilitati. Un merchant sta dismettendo record di catalogo obsoleti o disabilitati e vuole che l’ambito della migrazione contenga soltanto Products il cui campo di stato supportato indica che sono abilitati. Data Filter è il controllo pertinente perché la decisione riguarda quali record Product partecipano, non dove devono essere mappati i loro valori né come debbano essere modificati. La condizione esatta dipende dai campi e dagli operatori supportati per il percorso di migrazione selezionato.

Esempio: limitare gli Orders a un periodo aziendale definito.Un’azienda può aver bisogno soltanto degli Orders creati dopo una data concordata, lasciando lo storico più vecchio fuori dall’ambito previsto. Quando il campo data e il confronto necessari sono supportati, Data Filter può stabilire la popolazione di record prima che vengano valutate eventuali regole successive di mappatura o trasformazione. Il filtro non modifica il significato degli Orders selezionati; stabilisce quali record proseguono.

Advanced Data Mapping: mantenere il valore, cambiare la destinazione supportata

Advanced Data Mapping è adatto quando il valore di origine è corretto ma non lo è la destinazione supportata in cui dovrebbe essere collocato.

Il modello mentale è una riassegnazione diretta:

supported source field -> compatible target field

Per esempio, se il percorso di migrazione selezionato supporta sia Product Short Description sia Description, il requisito può prevedere che il valore di origine Short Description diventi Description sulla destinazione. Il valore non deve essere ricalcolato. La migrazione ha bisogno di una diversa destinazione supportata.

Questa distinzione è utile nella pratica:

“Metti questo valore di origine supportato in quel campo di destinazione compatibile” indica Advanced Data Mapping.
“Modifica questo valore prima che raggiunga lo store di destinazione” indica Data Transformation.
“Il valore si trova in una colonna database sottostante che richiede gestione a livello database” può indicare Advanced Database Mapping quando il percorso tra piattaforme è idoneo.

In un flusso combinato, Advanced Data Mapping riceve soltanto i record che hanno superato Data Filter. Stabilisce le destinazioni dei campi supportati prima dell’esecuzione di Advanced Database Mapping e Data Transformation. Quando fasi successive riguardano una destinazione collegata o identica, l’ordine di elaborazione determina quale valore sarà disponibile per il passaggio successivo.

Advanced Data Mapping ha comunque limiti precisi. Il campo di origine e quello di destinazione devono essere supportati e compatibili, e i dati Tax sono esclusi dall’ambito Standard della mappatura. Modificare la destinazione non garantisce inoltre che applicazioni, temi, estensioni o logiche aziendali sulla piattaforma di destinazione utilizzeranno il valore mappato in un modo specifico.

Esempi autonomi di utilizzo di Advanced Data Mapping

Esempio: usare Product Short Description come Description sulla destinazione. Il testo di origine è già corretto, ma lo store di destinazione deve ricevere quel valore supportato in un diverso campo compatibile. Advanced Data Mapping è adatto perché si tratta di un cambio diretto di destinazione: Short Description -> Description. L’operazione conserva il valore invece di riscriverlo.

Esempio: riassegnare un valore di contatto Customer supportato. Una migrazione può contenere un campo di contatto Customer supportato il cui valore deve finire in un altro campo di contatto compatibile sulla destinazione perché le due piattaforme organizzano le informazioni cliente in modo diverso. Quando entrambi i campi sono supportati e la destinazione può rappresentare correttamente il valore di origine, Advanced Data Mapping può effettuare la riassegnazione senza trasformare un problema di destinazione del campo in un requisito di trasformazione o Custom Service.

Advanced Database Mapping: lavorare con rappresentazioni idonee a livello database

Advanced Database Mapping diventa rilevante quando un requisito non può essere descritto soltanto come lo spostamento di un campo applicativo supportato verso un altro campo supportato. Estende la mappatura supportata a campi e colonne database sottostanti idonei, compresi campi specifici della piattaforma e campi personalizzati che restano entro la capacità Standard.

La disponibilità è volutamente più limitata perché la gestione a livello database dipende dall’architettura su entrambi i lati della migrazione. Sia la piattaforma di origine sia la piattaforma di destinazione devono essere Open-Source. Se una delle due è Non-Open-Source, Advanced Database Mapping non è disponibile.

Questa condizione architetturale risponde soltanto alla prima domanda di idoneità. Un percorso tra piattaforme idoneo non rende automaticamente mappabile ogni campo o colonna. Il requisito concreto deve comunque essere verificato rispetto a:

partecipazione supportata del campo o della colonna database di origine;
disponibilità di un campo o una colonna di destinazione compatibile;
sufficiente compatibilità del Value Type;
relazioni e significato dei dati supportati;
esclusione dei dati Tax dall’ambito Standard della mappatura.

L’Add-on è quindi particolarmente utile quando l’azienda può identificare con precisione il valore a livello database che deve essere preservato, il punto compatibile in cui deve essere collocato nello store di destinazione e i risultati che dimostreranno che la mappatura è realmente utilizzabile.

Nella sequenza di elaborazione, Advanced Database Mapping viene eseguito dopo Advanced Data Mapping e prima di Data Transformation. Questa posizione conta quando la mappatura database stabilisce un valore che deve poi essere ricalcolato o riformattato. Data Transformation riceve il risultato disponibile dopo entrambe le fasi di mappatura, quindi la mappatura database può diventare l’input diretto della regola finale che modifica il valore.

La mappatura database rimane inoltre distinta dall’implementazione sulla destinazione. Memorizzare correttamente un valore in un campo o una colonna compatibile sulla destinazione non dimostra che tema, estensione, workflow applicativo, regola fiscale o funzione storefront interpreteranno o mostreranno quel valore come previsto. Questi risultati richiedono una propria validazione.

Esempi autonomi di utilizzo di Advanced Database Mapping

Esempio: usare una colonna numerica Product personalizzata supportata come prezzo sulla destinazione. In un percorso idoneo Open-Source-to-Open-Source, un merchant può avere una colonna database personalizzata supportata, come regional_base_price, che deve popolare un campo o una colonna prezzo compatibile sulla destinazione. Advanced Database Mapping è rilevante perché il valore proviene dal livello database. Il requisito architetturale da solo non basta: devono essere confermati la colonna di origine specifica, la destinazione, la compatibilità del Value Type e l’ambito Standard.

Esempio: preservare un valore database specifico della piattaforma e supportato. Una piattaforma di origine Open-Source può conservare un importante valore Product in una colonna database specifica della piattaforma invece che nel livello dei campi standard. Se la piattaforma di destinazione Open-Source selezionata dispone di una destinazione compatibile e supportata e il requisito rimane una mappatura diretta che preserva il valore, Advanced Database Mapping può trasferire quel valore nel campo o nella colonna prevista sulla destinazione. Questo non implica che ogni tema, app, estensione o workflow della destinazione userà automaticamente il valore memorizzato.

Data Transformation: modificare il valore finale sulla destinazione

Data Transformation è adatto quando la destinazione è già nota ma il valore che deve esistere in quel punto deve cambiare.

Schemi comuni includono:

applicare una regola aritmetica a un valore numerico;
aggiungere, rimuovere o ristrutturare testo mediante un’espressione supportata;
normalizzare valori in una rappresentazione di destinazione concordata;
calcolare un valore finale partendo dai dati stabiliti da una fase di mappatura precedente.

La distinzione più utile è semplice: la mappatura risponde a dove deve andare questo valore? La trasformazione risponde a quale deve diventare il valore risultante?

Poiché Data Transformation viene eseguito per ultimo, lavora sul valore disponibile sulla destinazione dopo Advanced Data Mapping e, quando idoneo, Advanced Database Mapping. È quindi particolarmente utile come fase finale di un requisito composto. Se, per esempio, la mappatura a livello database stabilisce il Price sulla destinazione, una trasformazione successiva può calcolare il Price finale a partire da quel valore mappato invece di usare un precedente valore del campo di origine.

Data Transformation non sceglie quali record partecipano e non decide quale campo o colonna di destinazione deve ricevere un valore di origine. Queste decisioni appartengono alle fasi precedenti. Una trasformazione ben definita parte quindi da un campo di destinazione noto, da un valore di input noto dopo la mappatura e da una regola supportata chiara per produrre l’output previsto.

Esempi autonomi di utilizzo di Data Transformation

Esempio: aumentare del 12% il prezzo risultante sulla destinazione. Un merchant può voler impostare Regular Price sulla destinazione a un valore superiore del 12% rispetto a quello stabilito dalla fase di mappatura precedente. Data Transformation è adatto perché la destinazione è già nota e deve cambiare il valore risultante. Un calcolo supportato come Regular Price x 1.12 è quindi una trasformazione, non una decisione di mappatura.

Esempio: normalizzare un valore di testo sulla destinazione. La sorgente e la destinazione possono rappresentare lo stesso significato operativo con convenzioni testuali diverse. Quando una regola di trasformazione supportata può normalizzare il testo finale nella rappresentazione richiesta, Data Transformation è l’Add-on pertinente. La regola agisce sul valore disponibile sulla destinazione dopo le fasi di mappatura applicabili; non seleziona i record e non decide quale campo di destinazione deve ricevere il valore di origine.

Perché l’ordine di elaborazione degli Add-ons è importante

Quando vengono utilizzati più Add-ons, l’elaborazione avviene in un ordine fisso:

Data Filter -> Advanced Data Mapping -> Advanced Database Mapping -> Data Transformation

La sequenza offre un modo chiaro per ragionare sui requisiti di migrazione composti:

Selezione: quali record sono autorizzati a proseguire?
Destinazione del campo: dove devono essere rappresentati i campi di origine supportati?
Destinazione a livello database: una migrazione idonea Open-Source-to-Open-Source richiede una mappatura supportata di campi o colonne database oltre il livello standard dei campi?
Valore finale: quale deve diventare il valore risultante sulla destinazione una volta completata la mappatura?

Ogni fase applicabile lavora sul risultato stabilito dalle fasi precedenti. Questo non significa che ogni migrazione abbia bisogno di tutti e quattro gli Add-ons o che ogni Add-on debba agire sullo stesso campo. Significa che il requisito va progettato come un unico percorso ordinato dei dati, non come un insieme di regole indipendenti configurate separatamente.

Combinazioni comuni di Add-ons

Molti requisiti reali hanno bisogno soltanto di due o tre fasi. Riconoscere lo schema aiuta a valutarne l’idoneità prima di concludere che sia necessario un lavoro personalizzato.

Schema del requisito aziendale	Combinazione probabile di Add-ons	Perché è adatta
Migrare soltanto un sottoinsieme definito di record e poi modificare uno dei loro valori sulla destinazione.	Data Filter + Data Transformation	Il filtraggio definisce chi partecipa; la trasformazione modifica il valore richiesto soltanto per quei record.
Inviare un campo di origine supportato a un diverso campo di destinazione compatibile e poi modificare il valore risultante.	Advanced Data Mapping + Data Transformation	La mappatura stabilisce la destinazione; la trasformazione lavora sul valore che vi è disponibile successivamente.
Usare un valore idoneo a livello database come valore di destinazione e poi applicare una regola di calcolo o normalizzazione.	Advanced Database Mapping + Data Transformation	La mappatura database stabilisce il valore sulla destinazione; la trasformazione produce il valore finale. Per la fase di database mapping entrambe le piattaforme devono essere Open-Source.
Limitare i record, reindirizzare campi supportati e poi modificare i valori risultanti sulla destinazione.	Data Filter + Advanced Data Mapping + Data Transformation	Il flusso combina ambito dei record, controllo della destinazione e modifica del valore finale senza richiedere mappatura a livello database.
Limitare i record, applicare mappatura di campi supportati, usare una mappatura database idonea e poi trasformare il risultato finale.	Tutti e quattro gli Standard Add-ons	Ogni fase risolve una parte diversa dello stesso requisito composto e alimenta la fase successiva pertinente.

La presenza di più fasi non trasforma automaticamente il progetto in un caso da Custom Service. Se ogni operazione rimane nell’ambito Standard supportato del proprio Add-on, il requisito combinato può essere gestito comunque con Standard Add-ons. La gestione personalizzata diventa rilevante quando una delle operazioni richiede una modifica, l’interpretazione di dati non supportati, una logica su misura o un’altra capacità esterna ai limiti Standard.

Un metodo pratico di pianificazione consiste nel partire dal risultato previsto nello store di destinazione e procedere a ritroso. Identifica prima il valore o la rappresentazione finale, quindi stabilisci se sono necessarie trasformazione, mappatura database, mappatura dei campi, filtraggio dei record o una combinazione di questi controlli.

Esempio: quattro Add-ons si completano per soddisfare un requisito reale di migrazione

Consideriamo una migrazione OpenCart-to-WooCommerce in cui i campi Product richiesti sono supportati e la colonna database personalizzata selezionata supera i controlli applicabili di mappatura e compatibilità. Entrambe sono piattaforme Open-Source, quindi il percorso può essere valutato per Advanced Database Mapping.

Il merchant vuole ottenere quattro risultati collegati:

migrare soltanto Products abilitati e ancora disponibili a stock;
usare il Short Description di origine come Description sulla destinazione;
usare una colonna database Product numerica personalizzata e supportata, denominata regional_base_price, come Regular Price sulla destinazione;
aumentare del 12% il Regular Price risultante durante la migrazione.

Nessun singolo Add-on risolve l’intero requisito.

Fase 1: selezionare i record Product

Data Filter applica le condizioni Product concordate, per esempio stato abilitato e quantità a stock superiore a zero. I Products che non soddisfano le condizioni non proseguono nelle restanti fasi di elaborazione Add-on per questo ambito di migrazione.

Il filtro risolve soltanto il problema della selezione. Non decide come descrizioni o prezzi devono essere rappresentati nello store di destinazione.

Fase 2: reindirizzare il campo descrizione supportato

Advanced Data Mapping mappa il campo di origine supportato Short Description verso il campo di destinazione compatibile Description.

Questo cambia la destinazione del valore supportato mantenendo distinta l’operazione di mappatura da qualunque modifica successiva del valore.

Fase 3: stabilire il prezzo da una sorgente a livello database

Advanced Database Mapping mappa il valore numerico personalizzato e supportato regional_base_price verso la destinazione compatibile Regular Price.

Questa fase è possibile nell’esempio soltanto perché entrambi i lati del percorso sono piattaforme Open-Source e si presume che il requisito specifico relativo al campo o alla colonna superi i controlli di idoneità dello Standard Add-on. Non si deve presumere che una colonna personalizzata sia idonea solo perché Advanced Database Mapping esiste.

Fase 4: calcolare il prezzo finale sulla destinazione

Data Transformation applica quindi il calcolo richiesto a Regular Price, per esempio:

Regular Price x 1.12

Poiché Data Transformation viene eseguito dopo entrambe le fasi di mappatura, lavora sul Regular Price stabilito da Advanced Database Mapping e non su un precedente valore di prezzo non più rilevante.

Il risultato finale mostra perché gli Add-ons devono essere valutati come una sequenza coordinata di elaborazione. Data Filter definisce i Products partecipanti, le fasi di mappatura stabiliscono dove vengono rappresentate le informazioni pertinenti e Data Transformation produce il prezzo calcolato finale.

Il risultato migrato deve comunque essere validato. L’esempio dimostra la gestione dei dati, non garantisce che ogni regola di prezzo a valle, tema, estensione, comportamento fiscale o presentazione storefront venga configurata automaticamente dalla migrazione.

Come interagiscono gli Add-ons quando operano sugli stessi dati

Gli Add-ons combinati possono interagire in modi diversi. Comprendere lo schema è più importante che contare semplicemente quanti Add-ons sono presenti.

Schema di interazione	Che cosa accade in termini concettuali	Implicazione per il lettore
Stessi record, campi diversi	Data Filter stabilisce i record partecipanti, mentre regole separate di mappatura o trasformazione agiscono su campi diversi all’interno di quei record.	Gli Add-ons sono coordinati dall’ambito dei record anche quando non operano sulla stessa destinazione.
Fasi di mappatura diverse, stessa destinazione	Advanced Data Mapping e Advanced Database Mapping possono entrambi contribuire a stabilire una destinazione. La fase di mappatura applicabile eseguita più tardi determina il valore disponibile per l’elaborazione successiva.	Le regole di mappatura sovrapposte devono esprimere un’unica strategia intenzionale per il dato finale, non obiettivi indipendenti.
Mappatura seguita da trasformazione	Una fase di mappatura stabilisce il valore o la destinazione, poi Data Transformation modifica il valore che esiste dopo la mappatura.	Le regole di trasformazione devono essere progettate sul risultato mappato, non su un precedente valore di origine che non è più l’input rilevante.
Filtraggio e successiva elaborazione	Data Filter esclude i record dalla popolazione che partecipa alla migrazione prima di qualunque mappatura o trasformazione.	Gli Add-ons successivi devono essere valutati rispetto alla popolazione filtrata che li raggiungerà realmente.

Questo modello rende più semplice analizzare requisiti composti. Il merchant può scomporre la richiesta aziendale in ambito dei record, destinazione, rappresentazione a livello database e logica del valore finale, quindi verificare se i vari elementi si rafforzano a vicenda o introducono ipotesi in conflitto.

Il caso più delicato si verifica quando più regole di mappatura incidono sullo stesso campo o sulla stessa colonna di destinazione. In questa situazione, l’ordine di elaborazione determina il valore disponibile per Data Transformation. La progettazione più sicura parte dal valore finale atteso nello store di destinazione e ripercorre la sequenza a ritroso, confermando quale fase deve stabilire ogni risultato intermedio.

Questa verifica a ritroso è utile anche quando gli Add-ons operano su campi diversi. Può far emergere regole non necessarie, destinazioni che non supportano il significato della sorgente, trasformazioni che si aspettano l’input sbagliato o record che avrebbero dovuto essere esclusi prima dell’elaborazione successiva.

La compatibilità non consiste soltanto nel far corrispondere i nomi dei campi

Un campo di origine e un campo di destinazione possono avere etichette simili senza essere compatibili. Le decisioni di mappatura devono considerare se la piattaforma di destinazione può rappresentare correttamente il valore di origine.

Per gli Add-ons di mappatura, il campo o la colonna di destinazione deve avere una capacità del tipo di valore sufficiente per il valore di origine. Un valore numerico di origine può spesso essere rappresentato in una destinazione testuale, mentre un testo arbitrario non può essere trattato in modo sicuro come numero soltanto perché alcuni valori di esempio sembrano numerici. Quando la compatibilità è incerta, deve essere validata e non presunta.

Gli Add-ons di mappatura hanno inoltre limiti funzionali. I dati Tax sono fuori dall’ambito supportato di Advanced Data Mapping e Advanced Database Mapping. Requisiti che coinvolgono tipi di dati, campi, colonne, relazioni, script o comportamenti applicativi non supportati possono richiedere Tailored Add-on, Custom Add-on o una revisione più ampia tramite Custom Service.

Standard, Tailored e Custom Add-ons

La funzione necessaria e il livello di personalizzazione richiesto sono decisioni separate.

Livello Add-on	Significato	Gestione del prezzo
Standard Add-on	Add-on preconfigurato usato entro il proprio ambito fisso supportato.	Prezzo fisso di catalogo.
Tailored Add-on	Funzione di uno Standard Add-on che richiede adattamento, modifica o ampliamento dell’ambito oltre la capacità Standard.	Valutato e quotato tramite Custom Service.
Custom Add-on	Funzionalità Add-on su misura fuori dall’ambito funzionale del catalogo Standard Add-on.	Valutato e quotato tramite Custom Service.

Un requisito non diventa Custom Service soltanto perché combina più Standard Add-ons. Se ogni operazione rientra nell’ambito Standard applicabile, il flusso combinato può essere composto interamente da Standard Add-ons.

Allo stesso modo, le espressioni custom field o database column non definiscono automaticamente un progetto personalizzato. Il requisito deve essere prima valutato rispetto ai limiti supportati di Advanced Data Mapping o Advanced Database Mapping. Custom Service diventa rilevante quando il risultato desiderato va oltre ciò che questi controlli supportati possono offrire.

Add-ons e Custom Service risolvono problemi diversi

Gli Add-ons gestiscono requisiti circoscritti di elaborazione dei dati. Custom Service gestisce lavoro più ampio, su misura o non standard quando il requisito non può essere soddisfatto attraverso la migrazione supportata e il comportamento degli Standard Add-ons.

Custom Service diventa rilevante quando l’operazione richiesta non rientra più nel modello circoscritto degli Standard Add-ons. Segnali tipici includono dati non supportati di applicazioni o estensioni di terze parti, script o elaborazione API su misura, relazioni o logiche di migrazione non standard e funzionalità Add-on che devono essere adattate o sviluppate oltre il catalogo Standard. L’ambito non standard più ampio viene trattato nella guida dedicata a Custom Service; la decisione importante qui è riconoscere quando un Add-on da solo non descrive più il lavoro.

Una migrazione può anche usare Standard Add-ons all’interno di un ambito Custom Service più ampio. La presenza di Custom Service non cambia ciò che fa ciascun Add-on; cambia la gestione complessiva richiesta per il lavoro specifico del progetto.

Come Add-ons, Entity Points e prezzi si collegano tra loro

Entity Points e Add-ons rispondono a domande diverse di pianificazione.

Gli Entity Points misurano la capacità conteggiata per Products, Customers, Orders e Blog Posts. Gli Add-ons controllano specifici comportamenti di elaborazione supportati. Un Add-on non crea un nuovo peso Entity Points e un tipo di dati non conteggiato non diventa conteggiato soltanto perché viene usato un Add-on.

I prezzi fissi degli Standard Add-ons indicati nel catalogo sopra sono separati dalla capacità Entity Points. Tailored e Custom Add-ons non usano tali prezzi fissi Standard come preventivo finale, perché il lavoro aggiuntivo viene valutato nell’ambito di Custom Service.

Quando un Add-on idoneo viene aggiunto in seguito alla stessa migrazione acquistata, l’upgrade applicabile segue il principio del pagamento della sola differenza. L’Add-on modifica il pacchetto di servizio di quella migrazione; non cambia il percorso fisso dalla piattaforma di origine alla piattaforma di destinazione e non fa ripartire la durata del servizio.

Come valutare se un Add-on è adatto a un requisito reale

Una valutazione utile parte dal risultato desiderato nello store di destinazione, non dai nomi degli Add-ons. Il requisito aziendale può quindi essere scomposto nelle decisioni che le quattro fasi controllano realmente.

Domanda di valutazione	Che cosa rivela la risposta
Quali record devono partecipare al risultato?	Se è necessario Data Filter.
Il valore di origine è già corretto ma deve essere collocato in un diverso campo di destinazione supportato?	Se è necessario Advanced Data Mapping.
Il requisito dipende da un campo o una colonna database sottostante, ed entrambe le piattaforme sono Open-Source?	Se deve essere valutato Advanced Database Mapping.
Dopo il completamento della mappatura, il valore sulla destinazione deve cambiare?	Se è necessario Data Transformation.
Quali risultati dimostreranno che valore, destinazione, relazione e significato operativo sono corretti?	Che cosa deve essere validato prima di considerare il requisito soddisfatto.

Il linguaggio usato nel requisito offre spesso indizi utili. Parole come includere, escludere, soltanto o condizione descrivono di solito la selezione dei record. Mappare, collocare, inviare o destinazionedescrivono in genere la mappatura dei campi. Riferimenti a colonne database, campi specifici della piattaforma o campi personalizzatipossono richiedere Advanced Database Mapping quando l’intero percorso tra piattaforme e l’ambito supportato risultano idonei. Calcolare, normalizzare, aggiungere, rimuovere, convertire o ristrutturare indicano di solito una trasformazione del valore.

Sono segnali diagnostici, non approvazioni automatiche. Un campo con il nome giusto può avere un Value Type incompatibile. Un campo personalizzato può rientrare in uno Standard Add-on di mappatura, mentre un altro può dipendere da logiche non supportate e richiedere Custom Service. Una migrazione Open-Source-to-Open-Source può essere architetturalmente idonea per Advanced Database Mapping mentre la colonna database specifica rimane fuori dall’ambito supportato.

Il requisito più solido descrive quindi cinque elementi insieme: tipo di dati e record interessati, valore di origine, destinazione prevista, eventuale regola sul valore finale ed elementi che confermeranno il risultato. Una volta esplicitati questi punti, la combinazione di Add-ons può essere valutata rispetto ai limiti supportati invece di essere scelta soltanto in base al nome della funzione.

Questo approccio orientato al risultato evita due errori opposti. Evita di trasformare un requisito supportato in Custom Service soltanto perché coinvolge più controlli, ma evita anche di estendere uno Standard Add-on oltre la funzione supportata solo perché il nome sembra collegato al requisito.

Conclusione

Gli Add-ons Next-Cart sono più utili quando vengono compresi come fasi distinte di un unico modello supportato di elaborazione dei dati, non come un elenco di funzioni indipendenti. Data Filter seleziona i record, Advanced Data Mapping modifica le destinazioni dei campi supportati, Advanced Database Mapping estende la mappatura idonea a campi e colonne database supportati quando sia la piattaforma di origine sia quella di destinazione sono Open-Source, e Data Transformation modifica i valori risultanti sulla destinazione.

La sequenza fissa di elaborazione fa parte della decisione. Ogni fase applicabile lavora sul risultato stabilito dalle fasi precedenti; per questo i requisiti combinati devono essere progettati attorno al risultato finale nello store di destinazione e validati come un unico flusso coordinato.

Gli Standard Add-ons restano capacità supportate e circoscritte. Quando la funzione richiesta necessita di modifiche, logiche ampliate, sviluppo su misura o gestione non supportata, il requisito passa a Tailored Add-on, Custom Add-on o a un ambito Custom Service più ampio, invece di forzare la capacità Standard oltre il suo limite previsto.

Domande frequenti

Come può un’azienda capire se ha bisogno di uno o più Add-ons?

Scomponi il requisito in selezione dei record, destinazione dei campi, rappresentazione a livello database e modifica del valore finale. Se il risultato aziendale comprende più di una di queste operazioni, possono essere appropriati più Add-ons. Il numero degli Add-ons conta meno del fatto che ogni fase risolva una parte distinta e supportata dello stesso risultato.

Più Standard Add-ons possono essere usati nella stessa migrazione senza Custom Service?

Sì. Combinare più Standard Add-ons non trasforma da solo la migrazione in un caso Custom Service. Ogni operazione deve rimanere entro l’ambito Standard supportato del proprio Add-on, le fasi devono formare una strategia coerente e il risultato combinato deve essere validato rispetto all’obiettivo aziendale previsto.

L’ordine degli Add-ons è importante quando se ne usano diversi?

Sì. La sequenza è Data Filter, Advanced Data Mapping, Advanced Database Mapping e infine Data Transformation. Ogni fase applicabile lavora sul risultato stabilito dalle fasi precedenti, quindi eventuali regole sovrapposte devono essere pianificate come un’unica sequenza.

Advanced Database Mapping è disponibile quando soltanto la piattaforma di destinazione è Open-Source?

No. Sia la piattaforma di origine sia la piattaforma di destinazione devono essere Open-Source perché Advanced Database Mapping sia disponibile. Se una delle due è Non-Open-Source, l’Add-on non è disponibile.

Qual è la differenza tra Advanced Data Mapping e Data Transformation?

Advanced Data Mapping modifica la destinazione compatibile di un campo di origine supportato senza cambiare il valore nell’operazione di mappatura. Data Transformation modifica invece il valore del campo selezionato sulla destinazione. Quando vengono usati entrambi, la mappatura stabilisce dove appartiene il valore prima che la trasformazione applichi la regola supportata che produce il valore finale.

Due Add-ons di mappatura possono incidere sulla stessa destinazione?

Possono partecipare a un requisito che converge sulla stessa destinazione, ma le regole devono essere progettate come una sequenza unica e non come mappature indipendenti. Advanced Database Mapping viene eseguito dopo Advanced Data Mapping, quindi il valore stabilito dalla fase di mappatura applicabile più tarda è quello disponibile per Data Transformation.

Un campo personalizzato o una colonna database può comunque rientrare in uno Standard Add-on?

Potenzialmente sì. Un campo personalizzato o una colonna database deve essere prima valutato rispetto all’ambito supportato di Advanced Data Mapping o Advanced Database Mapping. La parola custom non significa automaticamente Custom Service, ma un comportamento non supportato o su misura richiede comunque una revisione aggiuntiva.

Advanced Data Mapping e Advanced Database Mapping supportano i dati Tax?

No. I dati Tax sono esclusi dall’ambito supportato di entrambi gli Add-ons di mappatura.

Gli Add-ons modificano il calcolo degli Entity Points?

No. Gli Entity Points continuano a usare il modello conteggiato di Products, Customers, Orders e Blog Posts. Gli Add-ons incidono sul comportamento di elaborazione supportato e sui prezzi separatamente dalla capacità Entity Points.

Quando un requisito relativo a un Add-on deve passare a Custom Service?

Custom Service diventa appropriato quando il requisito supera le capacità supportate della migrazione Standard e degli Add-ons, compreso il lavoro Tailored o Custom Add-on e altre logiche di gestione dei dati su misura o non supportate. Il fattore decisivo è il limite delle capacità supportate, non la semplice presenza di più Add-ons, di un campo personalizzato o di una colonna database.

Your privacy choices