Webservice su Navision / Dynamics Microsoft versione 5 ... o altro?

Question

Vai taglie!

Questa domanda mi è guadagnato un badge Tumbleweed (7 viste in 7 giorni!), Che è in qualche modo una forte conferma che Navision ha una quota di mercato molto limitata, che - ho il sospetto - dovrebbe essere un conferma Navision è né tutto quel grande pezzo di software ...

Ma hey ... questo è quello che abbiamo ottenuto come back-end, quindi sono pronto a combattere con questo. : -O

Se c'è qualche sviluppatore Navision audace che è in grado di far luce su questo ... la taglia è lì per voi! :)

---

Original post

Ho recentemente implementato un sistema di e-commerce piuttosto complesso che interagisce con un lascito di back-end basata su Navision 5. Finora lo scambio di dati tra le due piattaforme è avvenuto tramite file XML, ma questo metodo è abbastanza goffo e inclini molto per contrattempi.

I nostri bisogni sono:

1. esporre alcuni elementi della logica di business di ciascuna piattaforma all'altra (ad esempio: "Qual è l'importo totale mai acquistato da questo cliente", "quali sono i prodotti attualmente in offerta ?", "come molti nuovi clienti si sono registrati sul sito?", ecc ...).
2. disporre di meccanismi di feed-back / validazione per le varie operazioni (ad esempio: "Ecco il nuovo ordine da parte del cliente X" ... "Ok, capito, l'ordine sarà ora iniziare da lavorare" ... "Ok, Ricevuto, bye!").
3. Se possibile, evitare di giocare in giro con i file , ma mantenendo tutto ciò accada in termini di chiamate / porti / servizi ...

Il modo più naturale che potrei pensare a sarebbe quello di integrare i due sistemi tramite webservice, ma Navision 5 non supporta in modo nativo. Così ho fatto la mia "due diligence" e ha trovato un paio di cose su MSDN compreso questo articolo e quest'altro .

In base a questi articoli non dovrebbe essere così difficile creare un webservice su Navision 5 , ma quando ho proposto questa soluzione per il team responsabile del sistema legacy, ci hanno detto che si tratta di "teoria pura" e non sanno di chi mai implementato.

Non ho motivo di dubitare della loro parola, ma chilometraggio può variare ... e ho pensato che forse nel SO comunità ci sono professionisti provenienti da altri paesi che in realtà attuato qualcosa di simile e sono a disposizione di condividere la loro esperienza.

Quindi, la mia domanda è di due-piegato:

1. C'è qualcuno che ha provato questo a casa e sarebbe disponibile a condividere un po 'su quello che sono state le maggiori difficoltà, se il risultato finale è affidabile, se pensano che il risultato è valsa la pena sforzo, ecc ...?
2. C'è qualcuno che ha affrontato un problema simile, ma risolto con un approccio diverso e che sarebbe a disposizione per presentare la loro soluzione ( "Non ho mai fatto io stesso, ma se dovessi farlo lo farei in questo modo .. ." tipo di risposte sono i benvenuti)?

Grazie in anticipo per il vostro tempo! :)

Answer 1

Anche io carillon con una risposta non troppo utili su Nav 6:)

Ho appena completato un progetto utilizzando Nav 6. Sorprendentemente, i webservices sono molto facili da esporre e consumare. E 'davvero una cosa da poco per andare a trovare un oggetto nell'interfaccia di webservices e barrare una casella per dirgli di esporsi.

Unsuprisingly, i webservices non funzionano come ci si aspetta, si deve usare per un po ', spesso per tentativi ed errori per ottenere oggetti e proprietà a persistere, come è davvero delicato per quanto riguarda la sequenza di eventi che si utilizza per salvare e oggetto. E ogni oggetto sembra funzionare in modo leggermente diverso. ad esempio: Per creare un cliente, alla fine ho scoperto che si deve creare e salvare un cliente vuoto, massaggiare il nuovo record con un codeunit, poi prendere il record e quindi scrivere gli attributi del cliente e salvare di nuovo. I atteso per creare solo un nuovo cliente (), impostare gli attributi e salvare in un colpo solo veloce.

Credo che non siete troppo appassionato di aggiornamento a nav6, ma la parte superiore della mia testa, ecco come si potrebbe simulare i servizi web:

Sharepoint può già consumare ed esporre webservices, in modo che fila non è un problema. Nav 5 non ha li 'naturalmente', ma si poteva cucinare il proprio programma che agisce come un webservice 'mediatore' - si sta già ottenendo informazioni da e verso nav, tramite la maggior parte XML. Si potrebbe costruire questo broker di prendere input come i file XML e li massaggiare da utilizzare in una chiamata webservice. Si potrebbe anche rinunciare al XML e scrivere e leggere direttamente dal Db, come tutte le informazioni Nav è memorizzato comunque. Quindi, ecco quello che penso:

NAV <-> SQL SERVER <-> Nuovo 'mediatore' webservice <-> Sharepoint

Se avete già l'API NAV giù pat e volete resuse vostro XML:

NAV <-> file XML <-> Nuovo 'mediatore' webservice <-> Sharepoint

Se si utilizza XML e sull'uso filewatchers, la latenza non dovrebbe essere troppo male, di solito filewatchers salire su una goccia o cambiamento in millisecondi.

Hmm, ma sto pensando sei probabilmente dovrebbe utilizzare BizTalk per cose come questa: NAV <-> BizTalk <-> Sharepoint

Ma io non so come sarebbe facile da configurare BizTalk per comunicare con Nav. Scommetto che è piuttosto straighforward per ottenere comunicazioni di lavoro, ma questa è la speculazione.

In ogni caso, non so quanto utile questo post è, ma forse ti dà alcune idee per andare con.

Saluti, Lance

Answer 2

Dove lavoro, siamo stati in grado di utilizzare uno dei servizi web da NAV 6 per l'integrazione con SharePoint, in modo da poter cercare un cliente o registrare e mostrarlo in una web part in SharePoint. So che la tua domanda è di circa 5 NAV in particolare, ma ho visto solo questo gruppo di lavoro sul NAV 6. E non era lo sviluppatore che ha lavorato su questo, in modo da non avere più specifiche ho paura.

Hai provato a chiedere il mibuso.com? Sono molto più Navision-fuoco.

Answer 3

Quando si dice esporre la logica di business, ciò comprende l'esecuzione di codice AL (per esempio un codeunit)? Se avete solo bisogno di eseguire query sul database è possibile utilizzare NODBC & System.Data.Odbc o l'API Cfront .NET. Uno di questi può essere facilmente avvolto utilizzando un servizio Web .NET, ed entrambi supportano il database NAV nativo. Per passare messaggi avanti si sarebbe ancora bisogno di utilizzare COM, come descritto nel primo articolo si parla.

Ogni quanto sopra sono del tutto possibile, e relativamente facile a seconda della competenza nella NET, COM e NAV.

Il secondo articolo si è collegato al descrive utilizzando il NAS. Non sono un esperto su questo, ma penso che questo potrebbe richiedere uno speciale granulo di licenza. Prima di spendere tempo implementare qualsiasi cosa la sua pena di verificare se la vostra licenza include il NAS, Cfront o NODBC.

Answer 4

Si può effettivamente fare un "aggiornamento tecnico" del NAV 5 al NAV 2009 e quindi utilizzare i webservices nativi. Significato sostituendo i exe-file e l'intera applicazione (ma non gli oggetti, che saranno ancora versione 5), e un paio di altri trucchi. Ma funziona, e quindi si hanno 2009-webservice-funzionalità sul NAV 5: -)

Answer 5

Per il beneficio di chiunque googling questo, se siete ancora in Navision 6 con il database nativo, un buon modo di collegamento è tramite la coda di messaggi di Windows.

È possibile scrivere il proprio servizio web che mette le richieste XML nella coda e quindi attendere che la risposta a pop-up. Sul lato Navision, si dispone di uno i clienti che tira la coda e mette risposte nella coda di risposta. C'è uno speciale client non-GUI chiamato NAS per questo.

Ho usato questo metodo per 15 anni per collegare motori di prenotazione per finire fuori Navision indietro. Funziona molto bene e ha il vantaggio che si può sbirciare le richieste prima che raggiungano Navision, in modo da poter proteggere il back-end da troppe richieste o difettosi.

L'unico problema di questo approccio è che il comando commit entro Navision è super costoso. E 'difficile per servire grandi volumi di richieste. Non appena il back-end ha bisogno di commettere, si è fino a solo un paio di richieste al secondo. Questo può andare bene per volume basso.

Per volume alto è necessario implementare la cache o di ottenere alcuni dei logica di business fuori. Per me è stato di essere colpiti da siti web di comparazione prezzi, ecco la soluzione è servire coloro dai servizi web scritto in Python e passano solo sulle richieste se qualcuno compra qualcosa ...