Jump to content
Jeff Vice

Collegare sorgente DB con sistema esterno

Recommended Posts

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

Share this post


Link to post
Share on other sites
Guest

sinceramente non ho capito niente di cosa devi fare

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ;)

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Jeff Vice (see edit history)

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Ciao @Jeff Vice se ho capito bene vorresti sfruttare prestashop come front end per tema e funzionalità ma con la gestione del catalogo del gestionale remoto.

Se e questa la tua idea non vedo il motivo di modificare la struttura di prestashop.

L'interazione tra gestionale front end e gestione dati si che essi siano temporanei o di archivio si appoggia unicamente alla base dati.

Il web service di ps e efficace solo sotto alcuni aspetti ma poco pratico e molto poco efficace a mio parere nella gestione dei cataloghi onerosi.

Anche avendo 2 database strutturalmente diversi il problema non lo vedo.

Dovresti lavorare su 2 fronti se il catalogo e oneroso,nel mio caso mesi fa si parlava di oltre 480.000 articioli, dove nella prima parte ti serve una applicazione che converta e realizzi una base dati temporanea con i campi che ti servono.

Al secondo fronte devi lavorare per questioni di prestazioni sulla ignezione diretta dei dati.

Comporta la scrittura di qualche centinaio di righe di codice se l'applicazione e ben strtturata.

Dire che e impossibile anche no.

Prendi in esempio danea...ho un cliente dove gestisce tutto da li e usa prestashop per le vendite.

Prestashop mysql server,danea 2019 firebrid sql, database divesi e io ps non lo toccato manco una riga di codice e gli articoli sono 40.000.

Buon lavoro per il tuo progetto,non e impossibile solo impegnativo.

 

  

 

Share this post


Link to post
Share on other sites

@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 ;)

 

Share this post


Link to post
Share on other sites
28 minutes ago, marsaldev said:

Sostanzialmente risolvi comunque con la creazione di un bridge

esattamente quello che intendo solo che ho cercato di essere meno tecnico.

29 minutes ago, marsaldev said:

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.

Ni.....si parla di lavorare solo su catalogo, in ogni caso conta che io opero per questi lavori solo su VPS o server dedicati anche se il catalogo e piccolo, non puoi farlo con un hosting condiviso, occore un sistema dedicato configurato ad hoc, anche perchè non ci penso proprio ad impazzire con hosting da 3 euro al mese e tutte le restrinzioni che ne comporta, direi anche giustamente.

In ogni caso per queste iniezioni dirette lavoro con cache disattivata e provvedo al reset della cache symfony ogni volta aggirando il problema,vabbè non solo e per quanto mi sta sulle palle con symfony mi ci scontro spesso.

Questo comporta qualche secondo di attesa per il riempimento quindi lo shop ci mette 1-2 secondi a caricare, ma sono accettabili.

32 minutes ago, marsaldev said:

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

Be ho un sito di pneumatici, quale e necessario aggiornare il catalogo ogni 30 minuti, il fornitore e il più grosso di europa, ne moduli, ne l'utilizzo della classe per l'inserimento via csv e ne dal web service, che poi sfrutta la stessa classe, vanno bene in quanto gli articoli sono circa 8.000, si farebbe appena in tempo ad aggiornare il catalogo che starebbe sempre in aggiornamento.

Quindi ho optato per una iniezione diretta, non senza sorprese si parla pur sempre di operare su cms che sono realizzati da altri, però ce lo fatta con 120 righe di codice.

Considera che se ben strutturata la programmazione a oggetti con poche righe fai tanto,io vengo dal lontano asp, luaC ecc...però nel caso specifico forse sono stato ottimista lo devo ammettere.

Il lavoro e impegnativo e richiede diversi anni di esperienza, conta che io vengo anche da esperienza microsoft, tosto a dir poco quando si tratta di sviluppo.

38 minutes ago, marsaldev said:

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

he he......ci lavoro da luglio e ho finito qualche settimana fa, danea mi ha dato non poco laovoro per questa cosa.

Credimi, ci vuole tanta tanta esperienza, ma da come scrivi sai di cosa parlo, non avrei mai preso un impegno simile sicuramente 10 anni fa.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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 😉

Share this post


Link to post
Share on other sites
1 hour ago, marsaldev said:

Con le iniezioni dirette si fa sempre prima, ma bisogna stare attenti a non creare pasticci nel db

Vero, ma come ho spiegato nel mio caso con tempistiche di aggiornamento così poco distanti l'una dall'altra non c'era altra soluzione.

Quando si hanno tempisitiche di aggiornamento così strette come nel mio caso e non è stato nemmeno il peggiore, si rischia di vendere qualcosa che non si a oppure ad un prezzo errato e non è simpatico in ambedue le situazioni.

Io non Credo che PS sia stato pensato per cataloghi troppo onerosi, un catalogo con 7.000 articoli da poco caricato molto completo ci ha messo una vita e cosa che su magento questo non accade.

E anche vero che PS e gratis e aperto, quindi non mi lamento.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
39 minutes ago, Antonio FaqEcommerce said:

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 ....

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

Uno dei progetti da me citati aggiorna 8.000 articoli ogni 30 minuti e non e concepibile usare la stessa classe per i csv che ci mette 45 minuti anche solo aggiornando quantità e prezzi.

Il cliente non ha perso alcuna funzionalità questo perché e chiaro che non potevo realizzare un progetto con conseguenze simili,non e nemneno proponobile!

Un cms ps incluso si appoggia per il 95 % delle funzioni e impostazioni al db.

Tutto sta nel sapere quello che si fa se in grado di farlo.

L'iniezione diretta e fattibile senza conseguenze....lo fa il cms usando una sua classe perché io non posso usarne una mia.

Ti dirò di più....sono in fase terminale su un catalogo a iniezione diretta e non solo aggiorna quantità e prezzi ma in presenza di un nuovo prodotto lo aggiunge tutto a iniezione diretta senza alcuna perdita di funzionalità.

Sono 40.000 articoli e non e che posso impegnare risorse per ore o super server per un aggiornamento.

Stesso discorso quando e capitato con ben 480.000 articoli.....ti voglio vedere aggiornare un catalogo simile ogni 72 ore con il web service...cosa fai stoppi per 2 giorni lo shop??....dai su siamo seri parliamo di cose che si conoscono.

   

Share this post


Link to post
Share on other sites
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!) 

 

Share this post


Link to post
Share on other sites

E si allora ho capito male. 

24 minutes ago, Antonio FaqEcommerce said:

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

Ha ha ha ha.....va bene.....😊.

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More