Collegare sorgente DB con sistema esterno

[Jeff Vice]

Ciao,
sono in fase di valutazione sull'utilizzo di PrestaShop per un progetto di E-Commerce che avrà classiche funzionalità che PrestaShop risolverebbe perfettamente.

Ora la questione è legata alla base dati per gli utente, i prodotti e le categorie che dovrebbero essere lette attraverso web services esterni realizzati ad hoc.

E' possibile inserire una sorta di wrapper nel codice di PrestaShop, sempre che non lo faccia già autonomamente, per fargli acquisire questi dati dall'esterno invece che dalle sue tabelle interne?
Ovviamente sono conscio che le prestazioni sarebbero probabilmente non entusiasmanti, ma trattandosi di un sistema intranet le performance non sono il nodo cruciale.

Le fasi di acquisto ed ordini sarebbero gestite normalmente da PrestaShop salvando tutto sul suo sistema.

Sarei interessato a trovare una soluzione del genere anche perché i prodotti sono veramente tanti (un qualche migliaio) e, potendo variare abbastanza frequentemente sul loro gestionale interno, un'altra soluzione di script di sincronia mi sembrerebbe più intricata per questo progetto.

Qualcuno è in grado di dirmi se si riesce a realizzare qualcosa del genere con PrestaShop?

 

Grazie,
Jeff

[Guest]

sinceramente non ho capito niente di cosa devi fare

[Jeff Vice]

Vorrei usare PrestaShop come frontend per l'acquisizione ordini di prodotti che ho su un gestionale remoto accessibile verso web services rest.

Quindi vorrei capire se PrestaShop può avere un'impostazione di base dati remota per i prodotti o più probabilmente mi permette di creare un'interfaccia per far credergli di utilizzare le sue solite tabelle di prodotti realizzando io la gestione con i web service, cosicché da fargli credere che tutto funzioni come il solito.

TIA,
J.

[fedesib]

Ciao,

forse puoi dare un'occhiata a questa discussione:

Oppure lavorare con i webservices di PS:

https://devdocs.prestashop.com/1.7/development/webservice/

Buona giornata,
Federica

[marsaldev]

Ciao @Jeff Vice,

quello che chiedi, secondo le funzionalità di base di PrestaShop, è impossibile (o quasi).

Le varie entità e la configurazione di base è fatta in modo da lavorare con un db dedicato, è possibile cambiare la tipologia di connessione (quindi anche base di dati remota, db delocalizzato) ma le tabelle e la struttura deve essere quella dichiarata nelle entità.

Il tuo obiettivo potrebbe essere raggiungibile, ma dovresti fare talmente tante modifiche strutturali che alla fine ti ritroveresti con una piattaforma che non è più PrestaShop 😊

Mi spiace, ma forse dovresti orientarti su altre soluzioni.

 

Un caro saluto

[Jeff Vice]

Grazie @fedesib e @marsaldev,

infatti anche io credo che le modifiche che dovrei fare per avere la base dati integrata attraverso web services esterni come sorgente non ne valga molto la pena perché dovrei modificare proprio tanto.

L'idea di usare PrestaShop era legato al fatto che tante funzionalità (es. integrazione metodi di pagamento) potevo già utilizzarle o avere altre espansioni aperte per il futuro.

Credo che mi dirigerò verso una soluzione custom dedicata per il cliente... sempre che non decida che gli possano andare bene degli aggiornamenti asincroni della base dati attraverso importazioni.

 

Ciao,
J.

Edited October 7, 2019 by Jeff Vice (see edit history)

[marsaldev]

Ciao @Jeff Vice,

eh già, avevo immaginato che l'idea di utilizzare già funzionalità presenti, tipo i metodi di pagamento, poteva essere molto comodo.

Forse potresti considerare un bridge connettore come microservizio che comunichi tramite webservices dal gestionale a PrestaShop, e sviluppare un modulo che comunichi con il microservizio e quindi far comunicare PrestaShop -> Gestionale.

Ragionandoci così su due piedi, la vedo l'unica strada percorribile al momento 😊

In questo modo manterresti le funzionalità utilissime di un e-commerce, gestione ordini, pagamenti, ecc, senza re-inventare la ruota; e puoi avere la comodità di un front office già sviluppato 😊

 

Un caro saluto

[Jeff Vice]

Grazie @marsaldev,

provo a ragionarci sulla possibilità di risolvere con un modulo, ma credo che la più veloce e meno problematica mi rimanga l'aggiornamento della base dati in maniera asincrona.

Ciaooo,
J.

[marsaldev]

@hardware-store

Sostanzialmente risolvi comunque con la creazione di un bridge, e utilizzi una base dati temporanea, aggiungendo un elemento in più alla comunicazione 😊

Nulla è impossibile, ovviamente, ma bisogna fare i conti con tanti altri aspetti in confronto all'obiettivo da raggiungere 😊

L'iniezione diretta di dati sarebbe da evitare (se ci riferiamo lato PrestaShop) in quanto si andrebbero ad escludere l'esecuzione degli hook di tipo "action", vitali per tutti i moduli.

Non sono proprio dell'idea che con "100 righe di codice" te la cavi, ma magari mi sbaglio.

Ad ogni modo sarebbe interessante capire come è strutturata la comunicazione che hai impiegato tra danea e ps 😊

 

Un caro saluto

 

[Jeff Vice]

Ciao @marsaldev e @hardware-store,

grazie per il confronto e se avessi tempo e modo proverei a dedicarmici in quella direzione.

Fortunatamente da un confronto con il cliente, il realtime non sarà più necessario e  si arriverà a fare un job notturno di estrazione dati dal loro gestionale così d'averli disponibili per una successiva importazione in PrestaShop.

Quindi questa soluzione mi appare più pratica e veloce, facendo delle upsert per tenere allineati i dati in PrestaShop.
Vi sembra anche a voi questa una soluzione più immediata e facilmente mantenibile?

Grazie,
J.

[marsaldev]

@hardware-store

👍 

Con le iniezioni dirette si fa sempre prima, ma bisogna stare attenti a non creare pasticci nel db 😊 per il resto siamo abbastanza allineati 😉

@Jeff Vice

E' sicuramente la soluzione più rapida e facilmente mantenibile 😉

 

Grazie a voi per il confronto 😉

[Antonio FaqEcommerce]

Ciao

Scusate se mi intrometto     a parte concordare che oltre un certo numero di prodotti è indispensabile ragionare con l'iniezione in DB evitando le classi, tuttavia c'è un aspetto che nelle precise e argomentate analisi, è stato trascurato, ovvero.... dopo la prima importazione è plausibile che gli aggiornamenti ricorrenti coinvolgano solo ed esclusivamente le quantità e/o il prezzo, pertanto anche utilizzando le classi, i tempi non sarebbero (salvo casi particolari in cui ci sia un numero di moduli aggiuntivi che vengono interessati da queste operazioni) lunghissimi e a prescindere da questa considerazione, resto dell'idea che l'inserimento a DB è la soluzione migliore, anche se si perdono funzioni come quella del mail alert per i prodotti per il quale magari l'utente aveva richiesto di essere avvisato in un eventuale rientro in stock ....

Io nelle varie situazioni in cui mi sono trovato sia nel caso di utilizzo delle classi che di iniezione a DB ho ragionato nell'effettuare un confronto dei dati tra la precedente importazione e quella che vado a fare, limitando quindi le operazioni ai soli prodotti che hanno avuto una variazione dei dati e in questo modo oltre a ridurre in modo importante i tempi, riduce anche il carico di lavoro del DB, in base a come lo fai magari stressa un pochino la RAM e il processore, ma sicuramente tempi e operazioni a DB sono infinitamente ridotte.

Con i csv o gli altri tipi di file è abbastanza semplice, pertanto se la scelta per la quale il tuo cliente ha optato è quella di creare un job notturno con importazione classica CSV, valuta la possibilità di questa strada per poter fare anche più job giornalieri e circoscrivere al massimo il rischio di vendere prodotti esauriti o a prezzo errato.

Buon Lavoro

[Antonio FaqEcommerce]

1 minute ago, hardware-store said:

Non mi trovo in accordo con questo pensiero...scusa ma sembra che te la vai a cercare.

Guarda che mi sa che hai letto troppo velocemente e non hai capito cosa ho scritto.... io sono perfettamente in linea con il tuo pensiero.... 

I miei sistemi aggiornano 35 csv fornitori ogni ora in un CRM dedicato e da qui aggiorno una dozzina di ecommerce con la stessa frequenza ( parliamo di 350/400 mila prodotti ) per i quali faccio anche il match degli EAN in modo che vengano raggruppati in un unico SKU (simil ASIN di AMAZON) per evitare prodotti duplicati (odiati dai motori e vietati da eBay per chi lo usa)

e la soluzione iniezione è l'unica possibile, tuttavia la mia riflessione, e qui forse non mi sono spiegato bene, relativamente all'uso delle classi per solo prezzo e quantità, andrebbe analizzata studiando la movimentazione dei prodotti e la sua necessità a sfruttare le eventuali funzioni gestite dalle classi.....

In buona sostanza la mia riflessione andava incontro a quelle che possono essere le esigenze del cliente, che come giustamente tu "vai predicando"      devono essere modulate e occorre far comprendere lui benefici e utilità delle cose che desidera.... 

In conclusione se io dovessi scegliere ( e lo scelgo ogni giorno da 9 anni ... ), iniezione a DB e al massimo altri script e job  che agiscono a compensare eventuali funzioni come per esempio la più semplice e stupida, la generazione dell'indice per la ricerca....

Ti invito a rileggere, almeno per una volta che la pensiamo allo stesso modo....e mi auguro che concordi con me almeno sul fatto che un match selettivo per limitare i record da importare sia una strategia valida e da tenere in considerazione....

ps: cmq un giorno o l'altro ti telefono.... sento crescere il desiderio di conoscerti   (non è una dichiarazione nè una proposta indecente!)