Bodo's Dynamics NAV Blog

Bodo ist ein Dynamics NAV Urgestein. Er programmiert NAV seit DOS Zeiten und hat auch keine Scheu vor .NET. Viele Neueinsteiger wurden von ihm in den letzten Jahren zu NAV Entwicklern ausgebildet.

In diesem Blog veröffentlichen Bodo und andere Superhelden Interessantes aus der Welt von Dynamics NAV.

SharePoint, InfoPath und NAV Web Services - Krimi, Teil 2

Verfasst von Stefan am Freitag, 14. September 2012

Tags: infopath, sharepoint, security, webservices, nav, 2009

WAS BISHER GESCHAH

Nun, da ich die widerspenstigen WebServices gezähmt hatte, wollte ich mich so kurz vor dem Ziel doch nicht von einer kleinen Tabelle unterkriegen lassen. Doch wie schafft man es einen neue Zeile per InfoPath über einen selbsterstellen Proxy an einen "Create..." NAV WebService zu übergeben? Die Einstellungen der "Wiederholten Tabelle" machen einem wenig Mut: Alles Grau.

Internetrecherche führte zu keinem spontanen Wissenszuwachs, also musste ich mir selber eine Lösung überlegen: Wenn die Tabelle keine Möglichkeit bietet, muss es halt eine Extra-Aktion werden.

Doch woher bekomme ich überhaupt die "leere" Zeile, die ich dann über das InfoPath-Formular ausfüllen und per Button speichern kann?
Ganz klar, ich brauche einen neuen WebService "GetEmpty...", der mir die passende XML Struktur zurückliefert, denn ohne die leeren XML-Elemente, bleiben die Eingabeelemente inaktiv.

Also, eine neue Datenverbindung eingerichtet und die passenden Eingabe-Elemente an die "GetEmpty..." Struktur gebunden. Noch schnell einen Button darunter zum Speichern platziert und fertig... wäre schön gewesen, aber:

Man darf nicht der Versuchung erliegen zum Speichern eine Datenverbindung vom Typ "Daten senden" anzulegen, denn die validiert immer die ganze XML Struktur - was in meinem Fall immer zu einem Validierungssfehler führt, da zum Zeitpunkt des Drückens meines Buttons nicht alle Pflichtfelder gefüllt sind. 

Was muss man also tun um Daten zu senden? Richtig, man legt im InfoPath eine Datenverbindung vom Typ "Daten empfangen" an!

Dann überträgt man die zu sendenen Daten als "Abfrageparameter" und ignoriert die Rückgabe. Dafür kopiert man per Regel die Werte aus der "GetEmpty..." Struktur in die "QueryFields" der "Create..." Struktur und ruft dann die neue Datenverbindung zum "Daten abfragen" auf - die aber in Wirklichkeit nur sendet - ist eigentlich ganz logisch.

Das gleiche Pattern muss man verwenden, wenn man vorhandene Zeilen in der Tabelle editieren möchte:

Man nimmt einen Button (das kleine Diskettensymbol) und erstellt eine Regel, die die Daten aus der Datenverbindung der Tabelle in die "QueryFields" der Datenverbindung "Update..." (Vom Typ: Daten empfangen) kopiert.

Der nachfolgende Aufruf der "Read..." Datenverbindung sorgt dafür, dass es keine optimistischen Locks gibt, wenn man die gleiche Zeile mehrmals speichert.

Mit diesem Erfahrungsschatz steht dem nächsten InfoPath + SharePoint + Dynamics NAV Projekt nichts mehr im Weg, hoffentlich.