Navision in den 'Wolken'

Guten Morgen allerseits,

zuerst moechte ich meinen tiefsten Respekt allen NAV-Experten und -Berater, die in diesen Foren teilnehmen, ausdruecken. Da ich nicht aus Deutschland stamme, entschuldigen Sie bitte meine sprachlichen und schriftlichen Fehler.

Meiner Ansicht nach ist NAV 2009 ein grossartiges Produkt und die 3-Tier Architekture ist ein riesiger Schritt zu der Zukunft dieses ERP-Produkts. Der RTC hat ein schoenes Look&Feel und stellt eine bessere Navigation und einfachere Datenverarbeitung bereit.

Ich denke aber, dass es auch einige Probleme gibt, das groesste – die allgemeine Leistungsfaehigkeit des RTC. Meiner Meinung nach wird je weitere Version Navision ein bisschen langsamer. Der RTC ist langsamer als der Classic-Client und die 3-Tier Architekture verusacht wahrscheinlich weiteren Rueckstand. Ich bin mir nicht ganz sicher ob die allgemeine Leistungsfaehigkeit genug waere, wenn es da zu viele Benutzer gibt oder die Datenbank zu gross ist (mehr als 15-20 GB).

Ich vermute, dass ein fehlender Part des Produkts eine voll-funktionelle Web-Version vom RTC ist. Meiner Meinung nach wenn ein schneller Server kombinierbar mit einem voll-funktionellen Web-Client da waeren, wuerde das Navision zu einem echten „Cloud“-Service und Nummer 1 innerhalb der ERP-Systemen machen.

Ich moechte die hier teilnehmende Experten, Berater und MVPs bitten, wenn es geht, ihre Ansicht ueber folgende Punkte ausdruecken:

1. Besteht Bedarf an einem schnelleren NAV-Server?
2. Besteht Bedarf an einer voll-funktionellen Web-Version von RTC?
3. Duerfen solche Komponenten als Add-Ons funktionieren oder muessen sie umbedingt einen Teil des Produkts sein?

Vielen Dank im Voraus!

da ich nicht viel dazu sagen kann aber durch die Entwicklung der Wirtschaft beobachten konnte würd ich sagen:

zu 2. noch nicht, aber als Vorbote zu agieren ist eindeutig Marktvorteil würde ich sagen...
zu 3. ich denke Modulartig wäre besser. Denn noch sind Web-Applications nicht sehr verbreitet.

Zuletzt geändert von Cr4cks am 16. Oktober 2009 12:16, insgesamt 2-mal geändert.

da ich nicht viel dazu sagen kann aber durch die Entwicklung der Wirtschaft beobachten konnte würd ich sagen:

zu 2. ja
zu 3. ja

Sorry Cr4cks, wenn ich da zwischen "Grätsche", aber meinst du nichst selbst auch, das die Antworten auf das vorhergehende Posting ein wenig knapp und auch (zumindest für mich) fragwürdig Argumentiert sind?!

Ich persön. habe mich der Anwort enhalten, da ich keine detailierte Antowrt geben könnte (höchstens den Verweis auf die Systemanforderungen). Ich denke hier sind wirklich Spezialisten gefragt, die ggf. mit ähnlichen Anforderungen bereits gearbeitet haben.

Sorry Cr4cks, wenn ich da zwischen "Grätsche", aber meinst du nichst selbst auch, das die Antworten auf das vorhergehende Posting ein wenig knapp und auch (zumindest für mich) fragwürdig Argumentiert sind?!

Man nehme ein bisschen E-Commerce und ein ERP-System was die Systematischen Abläufe unterstützt und schon spart man immense Kosten in der Aufbereitung der Daten die für z.b. Steuerprüfer erforderlich sind...

Das was google im Angebot hat, "wie oft wird meine seite besucht", "wieviel traffic hab ich im monat" etc würde sich unabhängig von dritten darstellen lassen... ganz geschweige von Finanzsachen "wie hoch sind meine einkünfte?","wo liegt verkaufspotenzial vor","Wo lohnt es sich werbung zu tätigen", welches CMS kann so etwas bieten? ich kenne keins...

Der Markt der Web-Applications wird (da bin ich mir äußerst sicher) die "normalen" Programme vom Markt schieben... denn eine Webapplication lässt sich nunmal einfacher, besser und schneller in die Vertriebsebene(deutschlandweit,europaweit etc) integrieren... Das Internet machts möglich =)

2. Besteht Bedarf an einer voll-funktionellen Web-Version von RTC?

Prinzipiell ist der RTC doch webfähig. Ist eine Frage von DNS und Portfreigabe und ob der Admin bereit ist das zuzulassen. Ansonsten bleibt ja noch RWW oder TS.

3. Duerfen solche Komponenten als Add-Ons funktionieren oder muessen sie umbedingt einen Teil des Produkts sein?

Das ist wohl erstmal eine lizenzrechtliche Frage. Wer darf alles von woher wie auf NAV zugreifen? Mitarbeiter oder Geschäftspartner? NAV bietet doch außerdem die Möglichkeiten Webservices zur Verfügung zu stellen (auch hier wieder eine Frage was der Admin zuläßt), die von anderen Anwendungen konsumiert werden können.

Volker

Prinzipiell ist der RTC doch webfähig. Ist eine Frage von DNS und Portfreigabe und ob der Admin bereit ist das zuzulassen. Ansonsten bleibt ja noch RWW oder TS.

Nunja, unter "Webfähigkeit" verstehe ich etwas anderes. Natürlich sind die Funktionalitäten alle auch "aus dem Web" erreichbar, aber ich habe keinerlei transparente Abbildung von Pages als HTML beispielsweise. Unter Webfähigkeit verstehe ich beispielsweise die Integration in SharePoint, die transparente und automatische Umsetzung der Page Metadaten in Webforms/WebParts, sprich automatisches generieren von HTML Code aus Pages.

Und um diese Antwort abzurunden und auch Romens Frage zu beantworten:

1. Ja natürlich, man benötigt immer einen schnelleren Server :) Microsoft ist sich darüber im Klaren, dass der Sprung zur 3-tier Architektur der richtige war, aber auch, dass es im ersten Schritt ein wenig Geschwindigkeit gekostet hat. Aber der Gewinn einer dynamischen Erzeugung und des automatischen Layouts aus Metadaten, ein extrem wichtiger Punkt auf dem Weg zum Ziel, darf man dabei nicht vergessen. Auch der erste Schritt zur besseren Skalierbarkeit, auch wenn viele schimpfen, ist erfolgreich getan. Und an der Geschwindigkeit wird auf jeden Fall gearbeitet.

2. Kann ich auch nur mir "Ja" beantworten. Da ich allerdings 3 mit "muss im Produkt enthalten sein" beantworte, warte ich bis zur Umsetzung durch Microsoft

Vielen Dank fuer alle bis jetzt ausgedruckte Meinungen. Hier sind einige weitere Erklaerungen (noch einmal entschuldigen Sie bitte mein Deutsch, aber ich bevorzuge hier auf Deutsch und nicht auf Englisch schreiben):

- Alle Meinungen von Nav-Berater, Entwickler, MVPs und Produkt-Architekten sind herzlich willkommen. Wir haben nicht so viel Erfahrung mit Hunderten von Kunden (nur seit 2 Jahren in Nav-Bereich), deswegen moechten wir zuerst die andere erfahrene Menschen anhoeren und dann weitergehen. Zur Zeit muessen wir fuer einen von unseren Kunden eine "custom" Nav-Webanwendung erstellen. Die Webanwendung muss viele Pages von RTC reproduzieren und durch Intranet/Internet zugreifbar sein. Wir koennen das pro-Kunde (custom) machen oder das Problem prinzipiell loesen. Es ist nicht dringend und wir haben Zeit dafuer. Wenn wir das Problem prinzipiell loesen, koenten auch andere interessierte Berater/Entwickler die Webanwendung benutzen. Das wird aber viele Bemuehungen brauchen, deswegen muessen wir zuerst uns ueberzeugen.

- RTC ist eigentlich nicht ganz webfaechig. Meiner Meinung nach muss ein Webanwendung in ein Browser (IE, Firefox, Chrome, usw) ausgefuert werden. Ein Webanwendung braucht keine "Client-Side" Installationen (oder nur einige Browser-Addons), sondern nur Server Installationen, Anpassungen und Konfigurationen. Webdienste sind auch nicht echte Webanwendungen.

- Ich denke auch, dass eine Zustimmung von Microsoft fuer eine solche "prinzipielle" Anwendung noetig ist. Als ich mich errinere, die Politik von MS war immer die aeusseren Entwicklungen zu unterstuetzen. Das Problem fuer mich ist, dass ich z. Zeit weiss nicht an wen von MS zu wenden. Ich hoffe, das sie auch die Foren lesen und ihre Meinungen ausdruecken koennen oder mit uns in Kontakt kommen. Wir haben auch andere Ideen fuer NAV-Verbesserungen und moechten die weiter (auch in einer Partnerschaft mit MS) entwickeln.

Bitte schreiben Sie weiter.

Hallo Rumen,

hast du dich schon mal mit der NAV- Sharepoint- Anbindung (employe-Portal) auseinandergesetzt? Vielleicht hilft dir das ja schon weiter. So viel ich weiß benötigt dieses System auch nicht den RTC.
Meiner Meinung nach, kommt es auf den Anwendungsfall an, ob es sinnvoll ist die Webservices zu nutzen oder eine eigene Lösung über eine NAS- Socket- XML Kommunikation zu lösen (wie es bisher recht zuverlässig mit Webshop-Anbindungen funktioniert).
Webservices bieten zwar eine standardisierte Schnittstelle zwischen Web-Anwendungen und NAV, haben aber den Nachteil das man einen sehr großen Overhead zwischen Anwendung und dem eigentlichen Nutzcode hat, den man nicht beeinflussen kann. Weiter muss sich die WEB-Anwendung an die Gepflogenheiten NAV halten, d.h. der WEB-Entwickler muss NAV kennen, wenn er z.B. Aufträge anlegen will, damit er die Felder in der richtigen Reihenfolge korrekt füllt. Änderungen an den WEB-Services, der NAV- Datenstruktur, oder NAV-Programmlogik haben einen direkten Einfluss auf die WEB-Anwendung.
Eine XML-Schnittstelle über den NAS definiert zwar einen recht starren Rahmen, es kann aber eine Schnittstelle sauber definiert werden, so das sich der WEB-Entwickler um seine Oberfläche bzw. WEB- Anwendung kümmern kann, und wenn er etwas aus NAV wissen will oder mitteilen will, macht er das über in den WEB-Sprachen bekannte einfache Protokolle. Da er hier nicht direkt auf NAV-zugreift, kann NAV als Empfänger der Nachricht auch bei NAV-Strukturänderungen in den meisten Fällen eine kompatible Schnittstelle bereithalten.

Gruß, Fiddi

Hallo zusammen,

ich habe da auch mal eine Frage bezgl. Webservices.
Ich bin zurzeit dabei, für einen Kunden einen Webservice aus NAV2009 nutzbar zu machen.
Meine Frage schon mal vorweg:

Ist es möglich, aus den Pages in NAV2009 heraus einen HTML-Code zu "exportieren", die dann als Designvorlage für Webparts im Share Point Server 2010 verwendet werden kann?
Oder ist es evtl. möglich, diese "exportierten" Pages als Benutzeroberfläche in Share Point 2010 so einzubauen, dass sie als Eingabeform (z.B. Form 50 "Einkaufsbestellung") direkt (in Verbindung mit NAV2009 als Webservice) nutzbar sind?

Folgendes geplantes Szenario:
Über Webservice in NAV2009 (also mit Tabelle 2000000076 "Web Service", einer eigenen Codeunit und einem eigenen XML-Port) eine Einkaufsbestellung im Share Point Server 2010 bereitstellen.
Dazu sollen im Visual Studio 2010 Webparts in C# (C Sharp) entwickelt werden, die dann in den Share Point Server 2010 eingebunden werden. Die Eingabeoberfläche/Eingabeform des Webparts (z.B. Nachbildung der Form 50 Einkaufsbestellung) muss manuell programmiert werden und der Inhalt der im XML-Port aus NAV2009 heraus gelieferten Felder muss ebenfalls in C# (C Sharp) manuell dem Webpart zugewiesen werden.

Kann man nicht den Weg über die C# (C Sharp) Programmierung irgendwie umgehen und die NAV2009 Page für die Einkaufsbestellung irgendwie im Share Point Server 2010 "unterbringen"???
Ist dieser Weg
NAV2009 Webservice -> in C# programmierter Webpart -> Einbindung des Webparts in Share Point Server 2010
nicht anders lösbar?


Und wo ich gerade dabei bin...
... wofür wird eigentlich die Tabelle 6701 "Web Part" benutzt? Kann ich das evtl. darüber realisieren?

Mein Problem ist, dass ich noch sehr wenig Erfahrung in C# habe.

Vielen Dank für eine Antwort,
Gruß,
naviii

Guten Morgen,

Sharepoint 2010 hat die Business Connectivity Services (BCS), die externe Daten in Sharpoint als Liste einbinden können. Wenn man das ganze mit InfoPath-Formularen in Sharepoint kombiniert sollte nicht allzu viel an Code zu schreiben sein. Ein separat zu programmierendes Webpart ist da erstmal nicht nötig.

Möchte man den Weg über Webpart gehen, könnte es u. U. sinnvoll sein die Daten von NAV via WCF (Windows Communication Foundation) dem Webpart zur Verfügung zu stellen (siehe z. B. http://it-republik.de/dotnet/sharepoint-magazin-ausgaben/SharePoint-spricht-Office-000407.html für SAP). Außerdem sollte man bei den Webparts über ein sandboxed Lösung nachdenken um Amok-laufende Webparts vom Rest des Sharepoint-Servers fernzuhalten.

Und hier noch was zum Lesen: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c010fc68-b47f-4db6-b8a8-ad4ba33a35c5&displaylang=en

Volker

Hallo vsnase,

danke für die Antwort und die Links.
Das hat mich schon (im Kopf) ein ganzes Stück weiter gebracht, nur die Umsetzzung fehlt noch
Ich muss mich aber die nächsten tage damit auseinander setzen. Werde mich mir (hoffentlich) guten Ergebnissen hier wieder melden.

Gruß,
naviii