[Gelöst] [CC]-[RTC] - Dateien auf Netzlaufwerk speichern ?

Hi,

ich versuche mit dem CC Änderungsprotokollposten zu exportieren:

Code:


ChangeLogFile.CREATE('D:\ChangeLogEntries\NavChangeLog-'+FORMAT(WORKDATE)+'.txt');
ChangeLogFile.CREATEOUTSTREAM(varOutputStream);
IF recChangeLogEntries.FIND('-') THEN BEGIN
  REPEAT
   ....
  UNTIL recChangeLogEntries.NEXT = 0;
  ChangeLogFile.CLOSE;
END;



Das funktioniert aber nur mit Lokalen Laufwerk

Und wenn ich im RTC :

Code:

REPORT.SAVEASPDF(111,c:\topten.pdf);

ausführe, funktioniert das auch nur auf Lokale Laufwerke.

Sobald ich auf ein Netzlaufwerk zugreife, entweder per \\, oder es einbinde mit Laufwerkbuchstaben, klappt das speichern nicht,
der Pfad sei ungültig oder nicht Existent.

Probleme haben die Benutzer welche dem NAS und den Webservices zugeordnet sind.

Ist es nicht möglich direkt aus NAV auf Netzlaufwerke zu speichern ? Oder gibt es einen Trick?

Es scheint mir so als wenn die Dienste (NAS und Webservices) das gemeountete Laufwerk nicht sehen, weil es nicht als System User gemeountet wurde?
Also eine Zugriffsrechte Geschichte?

Komisch finde ich auch folgendes:
Ich starte aus Visual Studio 2012 heraus eine C# Anwendung, diese greift auf die Webservices zu, wo ich mit "navwebserviceuser" angemeldet bin, führe SaveReportasPDF aus, um eine Datei auf c:\temp zu speichern, das passiert auch, als Datei besitzer werde aber ich eingetragen (Peter K.) , müsste die Datei nicht mit Dateibesitzer "navwebserviceuser" erstellt werden?


Vielen Dank.

Zuletzt geändert von elTorito am 18. Juni 2013 15:37, insgesamt 1-mal geändert.

ich würde sagen, es fehlen die zugriffsrechte

Das sollte weiterhelfen:
Managing network files in RTC

Falls zusätzlich noch die Filetabelle verwendet werden soll, ist da bei Netzwerkpfaden einiges zu beachten, Lösung siehe hier.

Das sollte weiterhelfen:
Managing network files in RTC

Hmm. Wenn ich richtig verstanden habe , dient das dazu wenn ein tier nicht in der Domäne ist ? Bei uns ist alles auf der gleichen Maschine, Lokal also, und der gleiche User.

Konkret lautet der Fehler:

Der Aufrufer verfügt nicht über die erforderliche Berechtigung, oder der angegebene Pfad ist schreibgeschützt.

Danke

Das sollte weiterhelfen:
Managing network files in RTC

Hmm. Wenn ich richtig verstanden habe , dient das dazu wenn ein tier nicht in der Domäne ist ? Bei uns ist alles auf der gleichen Maschine, Lokal also, und der gleiche User.

Konkret lautet der Fehler:

Der Aufrufer verfügt nicht über die erforderliche Berechtigung, oder der angegebene Pfad ist schreibgeschützt.

Danke

Das kann man auch lokal nutzen, siehe hier unten.

Letztendlich wurde eine Samba Freigabe auf dem Webserver als Lokales Laufwerk "gemountet" , aus Navision heraus speichere ich nun einfach auf D:\.

Danke für eure Unterstützung.

Ich benötige eure Hilfe ...
Bei manchen (nicht allen!) Stellen, an denen der RTC eine Datei auf einem Serververzeichnis (UNC-Pfade, nicht auf dem Service Tier) direkt abspeichern soll, erhalten die RTC-Benutzer ebenfalls die Fehlermeldung:

Der Aufrufer verfügt nicht über die erforderliche Berechtigung, oder der angegebene Pfad ist schreibgeschützt.

Der gleiche Aufruf im CC funktioniert tadellos, die Datei wird erstellt.

Mir sind aktuell zwei Server (nennen wir sie server1 und Server2) bekannt, auf denen wir Dateien ablegen. Genauer gesagt, sind es zwei unterschiedliche Partnermodule, die die Dateien ablegen wollen. Aus diesem Grunde möchte ich das Problem nicht über eine Änderung des C/AL Codes lösen, sondern über eine korrekte Delegation.

Die Ablage auf „Server1“ hatte bisher immer auch im RTC funktioniert, die Ablage auf „Server2“ je nach Funktionsaufruf mal ja, mal nein.
Wir sind div. Tipps aus dem Internet durchgangen, unter anderem auch diese hier:
http://blogs.msdn.com/b/nav/archive/201 ... n-rtc.aspx
Leider hat das unsere Situation nur noch verschlimmbessert; plötzlich funktioniert die Ablage auf Server1 ebenfalls nicht mehr – selbst nach Rücknahme unserer Änderungen nicht. Irgendetwas müssen wir für die Rücknahme übersehen haben?
Selbstverständlich haben wir in der Zeit keinem Benutzer (auch nicht dem NAV-Dienst-User) irgendwelche Rechte entzogen.

Zu unserem NAV-Dienst-User:

• Er ist kein lokales Systemkonto, sondern ein „normaler“ Domänenbenutzer. Die Einrichtung erfolgte allein durch unseren früheren Partner und kann deshalb nicht gänzlich nachvollzogen werden.
• Er hat Schreibrechte auf benötigten Serververzeichnisse: Wenn ich mich als dieser User mit dem Ziel-Serververzeichnis verbinde, darf ich dort Dateien erstellen.

Außerdem erwähnenswert:

• In unserem NAV arbeiten User aus zwei verschiedenen Domänen. Der NAV-Dienst-User gehört zu älteren Domäne.
• Bevor wir die ersten Änderungen ausprobiert haben, war eine Delegation bereits eingerichtet, und zwar als cfis für "Server1". Ab dem Augenblick, wo wir "Server2" (ebenfalls cfis) hinzugefügt haben, funktionierte "Server1" nicht mehr.

Hallo,

ich kenne auch so ein Problem, konnte das in sofern festnageln, als ein direkter Download vom Servicetier auf den Zielpfad (auch lokales Laufwerk) schief ging. Daher immer erst Download in lokale Tempdatei und dann in den Zielpfad verschoben.

Gruß, Fiddi

Nach dieser Lektüre weise ich morgen unserem NAV-Dienst für die Testdatenbank mal temporär einen User der anderen Domäne zu (+ Delegation auf diesen, natürlich) und schaue, was passiert ... Wer das liest und jetzt schon weiß, dass es völliger Murks ist, möge mich bitte aufhalten

Kleine Planänderung:
Nachdem ich - warum habe ich das nicht als allererstes getan? - den Onlinehilfeartikel How To: Set Up Delegation gelesen habe:

When the RoleTailored client and Microsoft Dynamics NAV Server are on different computers, file operations that are initiated from the RoleTailored client, such as RENAME and COPY, fail if the destination for the file operation is not on the computer running Microsoft Dynamics NAV Server. One solution is to configure Microsoft Dynamics NAV Server to delegate on behalf of the RoleTailored client as described in this topic. In this case, you may also need to configure Microsoft Dynamics NAV Server to delegate to the cifs service on the destination computer. To avoid this complication entirely, define file operations so that the destination is always on the computer running Microsoft Dynamics NAV Server. You can then use a shared folder on the computer running Microsoft Dynamics NAV Server and share it with all users who require access to the files.

... versuche ich es nun organisatorisch über einen freigegebenen Ordner auf dem NAV-Server zu lösen. Mal schauen, ob sich das als praktikabel herausstellt. Werde dann diesen Beitrag hier updaten.

Update1:
Freigabe funktioniert.
Wichtig ist, den Ablagepfad in der NAV-Einrichtung weiterhin als UNC-Pfad zu pflegen, damit die Dateiablage auch parallel mit dem CC klappt.
Die Benutzer, die Zugriff auf den freigegebenen Ordner brauchen, müssen auf ihrem Rechner mit einem Netzlaufwerk versorgt werden, damit sie schnell zum neuen Zielverzeichnis finden.
Wir probieren, ob wir mit Hilfe von RoboCop die Dateien vom NAV-Server auf den eigentlichen Zielort verschieben können. Dies hätte den Vorteil, dass a) der NAV-Server nicht zum File-Server verkommt, und b) sich für die Benutzer rein gar nichts ändert (außer dass Bestätigungsmeldungen einen Pfad nennen werden, den die Benutzer nicht kennen).

Um das Thema Delegation kommen wir langfristig aber trotdzem nicht herum, da unsere ältere "Domäne1" bald durch "Domäne2" komplett abgelöst wird. Es wird also einen neuen Domänenuser für unsere NAV-Dienste geben, also müssen wir hier die Delegation ohnehin einrichten. Aber das muss aufgrund der Freigabelösung zumindest nicht sofort sein.

Daher immer erst Download in lokale Tempdatei und dann in den Zielpfad verschoben.

Hi fiddi,
welche Voraussetzungen müssen für die Verschiebung erfüllt sein?

Ich verschiebe mit Hilfe einer DotNet-Variablen 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.System.IO.File
mit RunOnClient = <No>.

Code:

FileHelper.Copy(OldFileName,NewFileName);
FileHelper.Delete(OldFileName);

Es wäre auch kürzer gegangen, aber diese zwei Zeilen Code geben die ausführlichste Fehlermeldung, die ich bei jedem Versuch erhalte:

Meldung für C/AL-Programmierer: Fehler beim Aufruf von Member Copy: Der Zugriff auf den Pfad "\\AndererServer\..\Dateiname.TXT" wurde verweigert.

Das Problem ist NewFileName; OldFileName ist hier das temp. Serververzeichnis; und die Datei wird dort auch erstellt.
Sowohl ich als auch der NAV-Dienst-User haben aber Schreibrechte für den Zielpfad auf \\AndererServer.
Was habe ich übersehen? Oder hab ich dich falsch verstanden?

Hallo,

schau dir mal die (3-tier...) FileManagement CU (419!? hab grad kein NAV) in 2009 oder noch besser in 2013 an. Dort sind eigentlich alle Funktionen drin, die man zum Filehandling in 3-Tier Umgebungen benötigt.

Der sicherste Weg ist immer "Client File" ->"Client Tempfile"->"Server Tempfile" ->"Client Tempfile"-> "Client File". Dann muss man sich nicht um irgendwelche Rechtekonflikte zwischen Client und Service-Tier kümmern.
Das einzige Problem könnte dabei die Dateigröße werden, ist aber konfigurierbar.

Gruß Fiddi

schau dir mal die (3-tier...) FileManagement CU (419!? hab grad kein NAV) in 2009 oder noch besser in 2013 an.

2013 hab ich hier nicht ... Die 419 hatte ich schon konsultiert, allerdings war mein Denkfehler, den Clientfunktionen nicht zurücksichtigen. Ich nutze nun die Funktion DownloadToFile, um die Datei vom temp. Serververzeichnis zum Zielverzeichnis zu laden. Ich sollte mich nicht zu lange mit einem Thema beschäftigen, dann sehe ich den Wald vor lauter Bäumen nicht mehr ...
Danke!

Hallo,

Die 2013er CU 419 kann noch ein bischen mehr, und sollte auch unter 2009 laufen.
Es ist bei jeglicher manueller Dateibewegung in der 3-Tier- Umgebung eine gute Idee das über die dort vorhandenen Funktionen zu Up- bzw. Downloaden. Das funktioniert dann wieder so, wie im CC.

Gruß Fiddi

*seufz* Ich fasse mal die letzten Wochen zusammen.
Fakt ist: Domänenübergreifende Delegation ist erst ab Windows Server 2012 möglich - gibt selbst unsere neue Domäne aber nicht her. Domänenübergreifend bezieht sich nicht nur auf den NAV-Dienst-Domänenenuser, sondern auch die Servermaschinen (NAV-Server, SQL-Server) selbst. Und genau letztere sind bei und noch immer auf der alten Domäne.
Wir kommen um einen kompletten Domänenumzug (also nicht nur User, sondern auch Server, CustomSettings.config usw., und das alles gleichzeitig) nicht herum, wenn wir komplett auf den CC verzichten wollen.
Einzige Alternative: Zielpfad darf nicht ein beliebiger Netzlaufwerkpfad sein, sondern ein freigegebener Ordner auf der NAV-Sever-Maschine. Was natürlich bedeutet, dass die Benutzer darauf Zugriff haben müssen und der Ordner gesichert werden muss --> der NAV-Server wird von seinem Zweck her zu einem weiteren File-Server.

Darum für alle stillen Leser: VORSICHT mit Domänenmigrationen oder überhaupt mit gemischt genutzten Domänen im Zusammenhang mit dem NAV-RTC ....
Nicht alle NAV-Partner entwickeln Produkte, die die Delegation unnötig machen oder man wenigstens selbst Zugriff auf den Code hat