Zugriff per Web Service auf angepasste Pages?

Hallo zusammen,

ich bin noch komplett neu im Thema Dynamics NAV. Ich habe zwar bereits Erfahrung mit der Anbindung von zahlreichen anderen Warenwirtschaftssystemen (z.B. SAP Business One, Lexware, OrgaMax usw.), allerdings noch keine Erfahrungen bei Dynamics NAV. Es geht darum eine Schnittstelle für einen Kunden zu entwickeln, die Gebuchte Verkaufslieferungen in eine Datei exportiert. Nach einiger Recherche habe ich herausgefunden das man mit einem externen Programm (C#/.NET) am einfachsten über die Web Services (SOAP) auf die Pages zugreifen kann. Dazu muss die jeweilige Page im Menüpunkt Verwaltung->IT-Verwaltung->Allgemein->Web Services nach außen freigegeben werden. Dies hat in einem ersten Test auch sehr gut funktioniert und ich konnte die Gebuchten Verkaufslieferungen per SOAP Web Service mit C# abrufen.

Nun zu meiner eigentlichen Frage. Das externe Tool das ich entwickeln möchte soll nicht nur für einen Kunden sein sondern an beliebige Dynamics NAV Anwendern verkauft werden. Nun habe ich Dynamics NAV so verstanden das man Pages mit dem Dynamics NAV Developement Environment auch anpassen kann, also z.B. ein weiteres Feld hinzufügen. Sehe ich das richtig? Wenn ja, dann bedeutet das doch eigentlich das der Webservice für die Page Gebuchte Verkaufslieferungen (ID 130) bei jedem Kunden anders aussehen kann/generiert wird, da ggf. benutzerdefinierte Felder hinzugekommen sind, oder? Somit ist eine universelle Schnittstelle die für alle Dynamics NAV installationen funktioniert fast nicht möglich, bzw. der Webservice-Zugriff muss auf jeden Kunden angepasst werden der die Page verändert hat.

Sehe ich das richtig oder habe ich einen generellen Denkfehler? Leider hab ich aktuell nur die Demo-Version mit der Demo Company Cronus AG, daher kann ich das verändern von Pages leider nicht testen.

Besten Dank vorab für Eure Antworten,

Gruß

Hannes

Ja, im Prinzip hast du mit deiner Einschätzung vollkommen recht.

Die Frage ist aber auch hier wieder, was man genau erreichen möchte. Einerseits könnte man seine Lösung natürlich auf dem Standard basieren lassen und Kunden mit einer Anpassung im NAV müßten dann für die Anpassung der Schnittstelle zusätzlich zahlen. Das machen viele Anbieter im NAV-Umfeld so und ist eigentlich nichts ungewöhnliches. Andererseits müßte man sich auch die Frage stellen, ob es wirklich sinnvoll ist die komplette Standard-Page als Web Service zu veröffentlichen. Viele Felder auf dieser Page werden nämlich nur NAV-intern benötigt und sind für eine externe Zusatzanwendung eher uninteressant. Daher könnte man sich vielleicht eine eigene Page bauen, die eben nur die erforderlichen Felder enthält und die man immer zusammen mit der Schnittstelle ausliefert. Dadurch kann man sicherstellen, daß der Web Service nicht durch individuelle Anpassungen verändert wurde. Wenn ein Kunde jetzt ein zusätzliches, individuelles Feld hat, was er in der Schnittstelle unbedingt braucht, dann kann man das auch gut vertreten, daß dies zusätzlichen Aufwand erfordert.

Hi,

vielen Dank für die Info. Ja hatte es fast vermutet dass das ganze so abläuft. Eine Frage hätte ich noch. Da ich noch keine Erfahrungswerte habe, würde mich eine grobe Abschätzung interessieren: Ist es eher der Regelfall das die Pages gebuchte Lieferungen bzw. Gebuchte Verkaufsrechnungen oder auch Aufträge und Artikel verändert werden oder eher die Ausnahme. Also Prozentual gesehen, benutzt da ein Großteil den Standard oder eher was angepasstes?

Gruß

Hannes

also bei uns nutzen 90% der Kunden die Standardpages (bzw. die unserer Branchenlösung) ohne Anpassungen.

Aber wie HattrickHorst bereits erwähnte, kannst du natürlich dir eine eigene Page bauen und diese dann veröffentlichen - wäre wohl sinnvoller

Hallo,

die Geb. Beleg Pages sind standardmäßig nicht editierbar, also auch über den Webservice dann nicht.
Die Frage ist, warum es über den Webservice editiert werden soll? (Lesen sollte reichen:-)).



Gruß
Aydin

Also Prozentual gesehen, benutzt da ein Großteil den Standard oder eher was angepasstes?

In der Verkaufszeile und Verkaufskopf bzw. den gebuchten Pendants gibt es in vielen Installationen Erweiterungen, sei es durch Add-ons oder Individualprogrammierungen, davon sind dann i.d.R. auch alle Pages betroffen, die diese Daten anzeigen.

Hallo,

wow das ging ja schnell

@sweikelt: Ja der Weg über die eigene Page ist durchaus eine Überlegung wert. Allerdings fehlen dann vielleicht genau die Informationen die in den zusätzlichen Feldern stecken. Das müsste man dann in kauf nehmen.
@aydina81: Bei den gebuchten Belegen stimmt es das mir lesen reicht. Allerdings könnte es in einer erweiterten Version auch interessant sein z.B. Aufträge oder Kunden zu importieren, dort sind dann bestimmt Änderungen denkbar. Ist es so das der Standardsatz an Felder nicht editierbar ist und ich nur Felder hinzufügen kann, oder kann man generell auch die standard-Felder entfernen? Das würde das ganze noch deutlich vereinfachen.
@Kowa: Ok, solange es nur Erweiterungen sind könnte man das evtl. sogar dynamisch abfangen. Die Frage ist auch hier (wie zuvor bei aydina81), können bestehende Felder auch entfernt werden oder kommen im Regelfall neue Felder hinzu?

Gruß

Hannes

@Kowa: Ok, solange es nur Erweiterungen sind könnte man das evtl. sogar dynamisch abfangen. Die Frage ist auch hier (wie zuvor bei aydina81), können bestehende Felder auch entfernt werden oder kommen im Regelfall neue Felder hinzu?

Beides, dafür gibt es keine Regel. Am Anfang werden die Anwender meist von den vielen Feldern erschlagen, dadurch werden vielfach die angezeigten Felder auf das im Betrieb unbedingt notwendige "runtergekocht", aber sobald Sonderwünsche hochkommen, die sich mit den vorhandenen nicht abbilden lassen, werden dort dann wieder gezielt Erweiterungen vorgenommen.

Ich habe es auch schon andersherum erlebt. Da wollten die Anwender anfangs besonders viele Felder auf den Ansichten eingeblendet haben. Vielleicht weil sie dachten, ihnen würden irgendwelche Informationen vorenthalten. Trotz entsprechender Hinweise darauf, dass die Ansicht dann ziemlich überladen sein könnte und der möglichst schnelle Arbeitsablauf nicht mehr gegeben sein könnte, ließen sich die Anwender nicht von diesem Plan abbringen. Nach ein paar Wochen wurde dann alles wieder zurückgedreht, weil man erkannte, dass die meisten Felder eh nicht dauerhaft genutzt werden und die Übersichtlichkeit der Ansicht dramatisch darunter leiden musste. Für die seltenen Fälle, in denen die Informationen der ausgeblendeten Felder doch benötigt werden, kann man sich über Help > "About This Page" alle Felder der aktuellen Tabelle ansehen.

Dynamisch abfangen wird aber nach meiner Erfahrung schwierig, weil die von NAV herausgegebenen SOAP Schemata als sequentielle Struktur erstellt werden. Zumindest war das noch in NAV 2009 R2 so. Ist das mittlerweile in 2013 R2 anders?

Hallo,

ok, wenn es wirklich so ist das zum Teil die Standardpages reduziert werden, dann wird es kompliziert. Dann vermute ich dass es das einfachste ist eigene Pages (z.B. kopien der Orginal-Pages) mitzuliefern. Ich habe herausgefunden das die Page Customer Card als einzige auch in der Demo Version verändert werden kann und konnte etwas rumspielen. Mit einer eigenen mitgelieferten Page hat man eine saubere, verlässliche Datenbasis und einen gleichbleibenden Webservice. Mann kann diese mitgelieferten Pages standardmäßig um z.B. 20 Felder (BenutzDef1-20) erweitern, die erstmal leer sind. Hat ein Kunde nun spezielle zusätzliche Felder, kann er diese Werte in die BenutzDef1-20 Felder konfigurieren ohne das sich der Webservice verändert. Das könnte funktionieren. Problematisch wird es nur wenn es keine einfachen Felder sondern verknüpfungen zu anderen Pages/Tabellen sind. Ich vermute das sowas bei Auftragspositionen problematisch ist, aber das könnte man mal außen vor lassen.

Das dynamische auswerten der SOAP Service ist wohl etwas zu komplex, aber funktionieren könnte es trotzdem

Gruß

Hannes

Es ist richtig, dass man einer Page Felder hinzufügen kann, die dann auf Variablen basieren, aber die gelten dann nur im Kontext der Page selbst. Wenn die Werte irgendwo in der Datenbank hinterlegt werden sollen, brauchst du auch noch entsprechende Felder in der Tabelle dahinter. Wenn du einfach irgendwelche (Dummy-)Felder hinzufügst, dann hast du nachher vielleicht Probleme mit dem Datentyp oder mit Relationen (wie du schon sagst) oder mit Geschäftslogik, die beim Füllen eines dieser Felder ausgeführt werden soll. Also so einfach ist das nicht, einen Web Service komplett dynamisch und generisch zu halten. Daher ja schon am Anfang meine Frage, was du damit erreichen möchtest?

Ok, alles leider nicht so einfach wie erhofft. Im Detail sollen Aufträge (Aufträge, Rechnungen, Lieferscheine) exportiert werden um Sie an Versanddienstleister (DHL, DPD usw). zu übergeben. Das sollte mit mitgelieferten Pages recht gut gehen. Allerdings sollen auch Aufträge importiert werden, z.B. von Webshops oder Online-Marktplätzen. Diesen Import sehe ich problematischer da zusätzliche Felder angesprochen werden müssen und ggf. Codesegmente ausgeführt werden müssen. Auch der Export von Artikel an Webshops und Marktplätze ist angedacht, auch hier könnte es prolematisch werden.

Gruß

Maruu

Hallo,

mal als Tipp.
Beim Zurückschreiben kannst du zu Not auch eine Codeunit nutzen.
Entsprechende Funktionen schreiben, die entsprechende Aufträge anlegen usw.
Du kannst dir auch eine Buffer Tabelle generieren (mit Feldern die du brauchst) und vorher alles reinschreiben und eine Codenunit Funktion anschubsen, die alle Datensätze verarbeitet.

Im Grunde musst du bei dem Webservice nur umdenken und alternativen suchen
(Was für dich am Einfachsten umzusetzen und die Anforderung abdeckt )

Gruß
Aydin