Navision und Linux-Webserver

Hallo,

wir wollen in einem Browserfenster folgendes gerne machen:
-Anzeigen von Artikelbeständen
-Buchen von Artikel Zu-/ Abgängen
-Eingabe von Aufträgen

Unser Webbrowser ist ein Linux-/ Apache Server.
Wir haben eine Native Datenbank.

Da ich von der Integration von Navision auf einer Weboberfläche fast keine Ahnung habe frage ich Euch, wie muss ich Vorgehen?
Ist eine Kommunikation zwischen Navision und einem Apacheserver möglich?


Gruß Mikka

Hi Mikka,

zwei Möglichkeiten fallen mir ein.

1. Möglichkeit:
Man könnte einen oder mehrer Dataports erstellen. Der Export der Dataports werden dann über einen CronJob stündlich eingelesen und in eine MySQL-Datenbank geschrieben. Die eigentliche Internetseite muss dann nur die Daten aus der MySQL-Datenbank darstellen.

2. Möglichkeit:
Eine kleine Software erstelle die die C/FRONT-Schnittstelle nutzt. Die Software könnte über einen geplanten Task stündlich die Daten aus Navision lesen und direkt in eine MySQL-Datenbank schieben. Oder das Programm erstellt automatisch eine HTML-Datei.

Gruß, Marc

Danke Marc,

an die Vaiante mit dem Zwischenpuffern habe ich bereits gedacht.
Es ist jedoch erforderlich, das die Daten möglichst in "Echtzeit" dargestellt werden.
Es müssen immer die aktuellen Bestände ersichtlich sein.
Selbst wenn ich im Sekundentakt die Anfragen mit Navision einlese, so wird das Antwortverhalten sehr bescheiden sein.

Eine Buchung muss daher so schnell wie Möglich von der Weboberfläche in Navision erledigt sein.

Ich vermute, wenn ich alles auf Microsoft-Basis hätte, mit einem SharePoint-Server, währe das kein Problem oder?!
Gruß Mikka

@Mikka

Du musst nur die Architektur "ewtas" umbauen.
Dein Apache-Server setzt zur Abfrage eine XML-Datei zusammen.
Diese Abfrage sendet Du mit HTTP/Post an einen Windows-Rechner (z.b. XP mit IIS).
Auf diesem Rechner läuft ein ISAPI-DLL die Deine Abfrage an den Navision-ApplicationServer weiterleitet.
Das ganze funktioniert in der Praxis bestens.
Das haben wir bei mehreren Kunden im Einsatz.
(WebShop mit Echtzeitabfrage der Bestände bzw. Preise / Rabatte)

Gruss

Danke martinst,

(ich glaube wir werden noch gute Freunde )

Die Theorie habe ich (glaube ich) verstanden, jetzt muss ich mal schauen wie ich das ganze mit unseren Web-Entwickler auch zum laufen bringe.
Gruß Mikka

>>ich glaube wir werden noch gute Freunde
Sind wir das nicht schon

Gruss

Hallo,

als besagter "Web-Entwickler" hab ich dazu noch eine Frage.
Bisher war von mir geplant über SOAP einen Webservice zu benutzen, der
von einem Mediator (Windows Intranet Server oder Navision Server) zur Verfügung gestellt wird, um Daten von Navision zu erhalten. Eine Testimplementierung mit einem Tomcat-Application Server und Navision4 (ODBC) war jedoch sehr ernüchternd. Eine Antwortzeit von 4-5 Sekunden ist eigentlich nicht akzeptabel. Diese Antwortzeit besteht komischer Weise immer, egal, ob es ein Datensatz oder 200 sind?!

Wir haben ja Mikkas alte Gurke im Verdacht, das die Platten das nicht packen

Meine eigentliche Frage war: Die Lösung mit dem XML entspricht doch jetzt einem Webservice über SOAP, oder habe ich das falsch verstanden.

Für weitere Anregungen wären wir dankbar.

Gruß Chris

ODBC kann man für solche Sachen eher vergessen.
Mit XML wird die Kommunikation um einiges schneller.
Ich habe schnell bei einem unserer Kunden via HTTP eine Preisabfrage gemacht.
Hier der Header der Antwort:
<!--elapsed time navision 250 milliseconds (In 11:52:12.578 Out 11:52:12.828)-->

Das ist natürlich eine schnelle Antwortzeit.

Das grundlegende Konzept der ISAPI hab ich mir kurz angelesen. Das ist also als Applikation in einer DLL zu sehen. Die XML Verbindung vom Webserver zur ISAPI ist auch klar.

Mir klemmt es noch im Verständnis in der Verbindung von der ISAPI nach Navision. Benutzt Ihr da C/FRONT oder welche alternative Verbindungsmöglichkeit haben wir über den Navision Applikationsserver (Mikka haben wir sowas?).

Gruß Chris

Nein, C/Front wird nicht verwendet.
Sondern der Navision-Application-Server mit den zugehörigen Kommuniktionskomponenten.
Die Verbindung aus der DLL zu Navision erfolgt dann via diesen Komponenten via NamedPipe oder MessageQueue.

Gruss

@TakaBo
Ja, den Applikationsserver haben wir. Bisher noch nie genutzt (ausser zum Testen!).
Die Lizenz haben wir auch

Anbei vier Links zum Thema:
Talking with Navision: Say Hello to Navision and Expect Navision to Be Polite
Talking with Navision: Accessing Navision Business Layer through a Web Service
Talking with Navision: Exposing .NET Components to Navision

Message Queuing (MSMQ)


Gruß Mikka

Hei das ist ja super. Dann sollten wir uns den Vorschlag von martinst (Danke erstmal an dieser Stelle) genauer angucken. Zu unterbieten sind 250ms

Gruß Chris

>>Zu unterbieten sind 250ms
Mit welcher Version (Applikation)

AFAIK soll das NAV4.0 sein. Ob der Applikation Server eine eigene Version hat weiss ich nicht, da ich der "Webprogrammierer" bin

Mit 4.0 wirst Du diese Antwortzeit nie schlagen.
Insbesondere nicht wenn Du irgendetwas auf den Tabellen 36 bzw. 37 (Verkaufskopf und Verkaufszeile) machen musst.

Ich bin gespannt.

Gruss

Ich bin auch gerade an einer Lösung am basteln für die Kommunikation zwischen linux/apache/php <-> NAS <-> Nav.

Nach langem suchen im Goorakel habe ich herausgefunden das der NAS einen offenen Socket port 8085 stellt womit ja php komunizieren kann.
Hat schon jemand erfahrungen damit gemacht und weiß wie der handle funktioniert.

Habe auch eine über Lösung mit soap (kann php auch) gelesen. Gab aber wenig informationen.

Der Standart Internet ->Webserver->Webservices ->Queue ->Nas ->Navision ist ja ziemlich komplex und einen Windowsrechner mit iis ins Internet stellen ist ja auch keine gute Idee

GRuß

Windowsrechner mit iis ins Internet stellen ist ja auch keine gute Idee

Das ist der Gund, warum wir auch eine entsprechende Lösung auf Linux suchen.

Ich stehe z.Z. mit einen NSC in Kontakt, der uns über einen Drittanbieter eine Lösung vorstellen möchte.
Gruß Mikka

Drittanbieter eine Lösung vorstellen

Solche sachen habe ich mir auch schon jetzt von Mittlerweile 3 angesehen.
Aber auch die haben das Rad nicht neu erfunden. Immer die selbe geschichte mit sql und php queries. Einfach ein bekanntes Frontend (xt-commerce...) nehmen und die queries austauschen. Dafür brauche ich kein Geld aus dem Fenster zu werfen. Wenn es um mehr geht wie z.B. im Webshop zur kasse gehen => F11 Buchen Packliste drucken (Codeunits launchen) höhrt die Weisheis auf.
Wenn du so eine Lösung, die nicht auf dem IIS aufsetzt, währe ich sehr interessiert.
Solange bastel ich lieber an den Sockets rum.

Gruß

Ich werde dich und die anderen hier im Forum "auf dem Laufenden" halten.
Nächste Woche werde ich vermutlich mehr Wissen.
Gruß Mikka

Hallo,
gibt es mittlerweile neue Erkenntnisse zu dieser Problematik?
Ich möchte mittels XML-RPC oder SOAP auf Navision zugreifen. Antwortzeiten von 250 Millisekunden hören sich schonmal gut an.

Mit dem XML-Manager für Navision (Microsoft zertifizierte Schnittstellen Lösung (Framework) ist XML-Datenaustausch schnell realisierbar.

Wir habe letztes Jahr bei einem Kunden einen kleinen Leistungstest gemacht. PHP Seite auf RedDot und Linux ruft über Webservice und XML-Manager Artikelverfügbarkeiten in Navision ab. Gemessen wurde die Zeit absenden von der PHP Seite bis Empfang auf der PHP Seie. Ergebnis ca. 300 Anfragen (Artikelverfügbarkeit / Sekunde).

Hi @ all,

Bisher war von mir geplant über SOAP einen Webservice zu benutzen, der
von einem Mediator (Windows Intranet Server oder Navision Server) zur Verfügung gestellt wird, um Daten von Navision zu erhalten. Eine Testimplementierung mit einem Tomcat-Application Server und Navision4 (ODBC) war jedoch sehr ernüchternd. Eine Antwortzeit von 4-5 Sekunden ist eigentlich nicht akzeptabel. Diese Antwortzeit besteht komischer Weise immer, egal, ob es ein Datensatz oder 200 sind?!

Genau das tun wir. Die Antwortzeiten liegen im ms Bereich, Verzögerungen gibt es nur, wenn Navision die Daten, die reinkommen nicht schnell genug abgearbeitet bekommt :)

Für die Kommunikation setzen wir auf die aktuelle MS Soap Type Library und die 'Microsoft XML, v5.0' (und die entsprechenden Methoden) als Applikationsserver.

Klappt bidirektional hervorragend. lediglich die Fehlersuche ist aufgrund der recht spartanischen Fehlemeldungen etwas mühsam.

Hei das ist ja super. Dann sollten wir uns den Vorschlag von martinst (Danke erstmal an dieser Stelle) genauer angucken. Zu unterbieten sind 250ms

Gruß Chris

Hallo Christian,
du hast ja vor einigen vielen Monaten eine nWettbewerb gestartet

Ich kann es unterbieten 42,85 ms (und das quer durch Deutschland nach Österreich und zurück).
Allerdings muss ich Fairerweise sagen, das dieses ein rechnerischer Wert ist für 1400 Datensätze in 14 Anfragen per Webservice verarbeitet handelt!

Wenn ich es mit einer einzelnen Abfrage mache, liege ich bei ca. 500 - 1500 ms

Tachchen Leute :)

Da ich diesen Thread mehr als Interressant finde (ich komme aus der Webentwicklung) ist mir doch glatt eingefallen das es ja "neues"(eigtl uralt) gibt im Asynchronen Kommunizieren mit Servern... Habt ihr schonmal versucht mit AJAX eure Probleme in griff zu bekommen?

Gut, ich bin Newby im NAV aber es ist doch möglich automatisch XML zu exportieren?!
Warum holt ihr dann nicht mittels Ajax (asynchron Javascript and XML) diese Dateien die ihr braucht?

Ich glaube wenn ich gerade völlig falsch liege, liegt das daran das ich mit Begriffen wie SOAP o.ä. nichts anfangen kann... Für mich gabs nur 2 Serverarten ^^ PHP-Server und SQL-Server... mehr braucht man doch heut zu tage nicht


---------------------

[EDIT] Ich hab mal die Rechtschreibfehler entfernt...

Zuletzt geändert von Cr4cks am 2. Oktober 2009 10:05, insgesamt 1-mal geändert.

Weil es das gleiche in Grün ist AJAX ist im weitesten Sinne nichts anderes als eine Schnittstelle für den Datenaustausch zwischen Client und Server. Also Soap ( auch XML aber mit definiertem Contract ) sehr ähnlich. Eine Vereinfachung tritt nicht ein, da bei AJAX, um Cross Site Scripting zu verhindern, die XML nicht vom Navision Server direkt geliefert werden kann, sondern diese auch erst durch den Webserver laufen muss.

Mit freundlichem Gruß
Chris