[Gelöst] Webservice UNC Pfad

Hallo.

Ich möchte per Webservice-Aufruf XML Datei verarbeiten, die auf einem UNC Pfad liegt.
Also sprich eine externe Anwendung ruft einen NAV Webservice auf, übergibt einen Parameter (Filename) und NAV verarbeitet dann dieses File in einem definiertem UNC Pfad.

Über den Classic Client funktioniert das einwandfrei, allerdings schaffe ich es nur per Webservice auf lokale Pfade (also z.B. C:\Temp des Service Tier Hosts) zuzugreifen. Sobald UNC Pfade ins Spiel kommen, wird das File erst gar nicht gefunden.

Codeunit mit UNC Aufruf FileExists('\\server\pfad\file.xml')

Code:

IF (wshFSO.FileExists(AuftragsfertigungSetup.EPlanBOM2NavisionPATH + KonstAuftrag + '.xml')) THEN BEGIN
     ....
END ELSE
  ERROR('File not found: %1.xml', AuftragsfertigungSetup.EPlanBOM2NavisionPATH + KonstAuftrag);

Und die Codeunit die als Webservice fungiert:

Code:

...
IF NOT Eplan2BOM.RUN THEN BEGIN
  result := STRSUBSTNO('Error in processing ' + pConstructionJob + ': %1', COPYSTR(GETLASTERRORTEXT, 1, 990));
  EXIT(result);
...

Ergebnis Webservice Aufruf mit ganz einfacher Shell Anwendung aus Visual Studio:
C:\temp>eplan2bom
Status:200 OK
<Soap:Envelope xmlns:Soap="http://schemas.xmlsoap.org/soap/envelope/"><Soap:Body
><RunTask_Result xmlns="urn:microsoft-dynamics-schemas/codeunit/BOMImport"><retu
rn_value>Error in processing K123456: File not found:

srveplan
EPLAN
Temp
K123456.xml</return_value></RunTask_Result></Soap:Body></Soap:Envelope>


Ihr seht also, dass der UNC Pfad scheinbar zerbröselt wird, jeder Backslash wird als LineFeed interpretiert.

Wie gesagt, sobald entweder im CC oder per Webservice mit lokalen Pfaden (C:\...) gestartet, funktioniert es.
Der Webservice läuft ursprünglich als NETZWERKDIENST, habe aber sogar testhalber schonmal den Domänenadministrator als Konto eingetragen, keine Änderung.

Meine Vermutung ist wie gesagt, das der UNC Pfad nicht richtig übergeben wird.

Hat jemand schon mal ähnliche Probleme gehabt oder sogar eine Lösung

Zuletzt geändert von JoergR am 19. März 2013 16:10, insgesamt 1-mal geändert.

hast Du lokale UNC-Pfade ausprobiert?

Hab ich gerade gemacht, sehr interessant

Auf dem Service Tier Host den Ordner C:\Temp freigegeben und in NAV hart reingeschrieben:


IF XMLDoc.load('\\localhost\temp\K123456.xml') THEN BEGIN
..


erscheint über Webservice Aufruf:
C:\temp>eplan2bom K12345
Status:200 OK
<Soap:Envelope xmlns:Soap="http://schemas.xmlsoap.org/soap/envelope/"><Soap:Body
><RunTask_Result xmlns="urn:microsoft-dynamics-schemas/codeunit/BOMImport"><retu
rn_value>Error in processing K12345: This message is for C/AL programmers: The c
all to member load failed: Zugriff verweigert
.</return_value></RunTask_Result></Soap:Body></Soap:Envelope>


Der dienst läuft jetzt momentan als NETZWERKDIENST, aber zumindest scheint der UNC Pfad doch richtig zu funktionieren.

Daraus schlussfolgere ich, dass der Zugriff auf den "echten" UNC Pfad ebenfalls wegen Zugriffsproblemen nicht klappt und der Pfad erst in der Ausgabe zerstückelt wird.

Hab ich gerade gemacht, sehr interessant

Auf dem Service Tier Host den Ordner C:\Temp freigegeben und in NAV hart reingeschrieben:


IF XMLDoc.load('\\localhost\temp\K123456.xml') THEN BEGIN
..


erscheint über Webservice Aufruf:
C:\temp>eplan2bom K12345
Status:200 OK
<Soap:Envelope xmlns:Soap="http://schemas.xmlsoap.org/soap/envelope/"><Soap:Body
><RunTask_Result xmlns="urn:microsoft-dynamics-schemas/codeunit/BOMImport"><retu
rn_value>Error in processing K12345: This message is for C/AL programmers: The c
all to member load failed: Zugriff verweigert
.</return_value></RunTask_Result></Soap:Body></Soap:Envelope>


Der dienst läuft jetzt momentan als NETZWERKDIENST, aber zumindest scheint der UNC Pfad doch richtig zu funktionieren.

Daraus schlussfolgere ich, dass der Zugriff auf den "echten" UNC Pfad ebenfalls wegen Zugriffsproblemen nicht klappt und der Pfad erst in der Ausgabe zerstückelt wird.

Das mit den fehlenden Rechten war meine Vermutung.
Ist das Thema damit gelöst?

Hm bislang klappen nur lokale UNC Pfade, sobalds nach "außen" geht wird der Zugriff verweigert. Der Webservice-Dienst läuft testhalber unter meinem Windows-Benutzer, mit dem ich manuell über auf die externen UNC Netzpfade zugreifen kann.

Es scheint noch eine andere Einstellung am Webservice oder an dem c# Proxy nicht zu stimmen. Ich nehme dabei an, dass der Aufruf in der Navision Codeunit mit dem User passiert, der im Webservice-Dienstekonto eingerichtet ist.

Vielleicht fällt jemanden was hier auf:

Code:

using System;
using System.Data;
using System.Net;
using MSXML2;


namespace Eplan2BOM
{
    class Program
    {
        static void Main(string[] args)
        {
           
            if (args.Length == 0) {
                Console.WriteLine("Parameter 1 must be construction job number");
                Environment.Exit(-1);
            }

            string user = "username";
            string pw = "password";

            string domain = "ntdomain";

            string url = "http://servicetier:7047/DynamicsNAV/WS/Mandant/Codeunit/BOMImport";           

            //COM XML library
            MSXML2.XMLHTTP XMLHTTP = new XMLHTTP();
            MSXML2.DOMDocument XMLDoc = new DOMDocument();
            string xmlText;

            xmlText = "<?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><RunTask xmlns=\"urn:microsoft-dynamics-schemas/codeunit/BOMImport\"><pConstructionJob>" + args[0] + "</pConstructionJob><result></result></RunTask></soap:Body></soap:Envelope>";                     

            XMLHTTP.open("POST", url, false, domain+"\\"+user, pw);
            XMLHTTP.setRequestHeader("Content-type", "text/xml");
            XMLHTTP.setRequestHeader("SOAPAction", url+":RunTask");
            XMLHTTP.send(xmlText);
            Console.WriteLine("Status:" + XMLHTTP.status + " " + XMLHTTP.statusText);
            //XMLDoc.load(XMLHTTP.responseXML);
            Console.WriteLine(XMLHTTP.responseText);
           

        }       
    }
}



Hm bislang klappen nur lokale UNC Pfade, sobalds nach "außen" geht wird der Zugriff verweigert. Der Webservice-Dienst läuft testhalber unter meinem Windows-Benutzer, mit dem ich manuell über auf die externen UNC Netzpfade zugreifen kann.

Es scheint noch eine andere Einstellung am Webservice oder an dem c# Proxy nicht zu stimmen. Ich nehme dabei an, dass der Aufruf in der Navision Codeunit mit dem User passiert, der im Webservice-Dienstekonto eingerichtet ist.

Vielleicht fällt jemanden was hier auf:

Code:

using System;
using System.Data;
using System.Net;
using MSXML2;


namespace Eplan2BOM
{
    class Program
    {
        static void Main(string[] args)
        {
           
            if (args.Length == 0) {
                Console.WriteLine("Parameter 1 must be construction job number");
                Environment.Exit(-1);
            }

            string user = "username";
            string pw = "password";

            string domain = "ntdomain";

            string url = "http://servicetier:7047/DynamicsNAV/WS/Mandant/Codeunit/BOMImport";           

            //COM XML library
            MSXML2.XMLHTTP XMLHTTP = new XMLHTTP();
            MSXML2.DOMDocument XMLDoc = new DOMDocument();
            string xmlText;

            xmlText = "<?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><RunTask xmlns=\"urn:microsoft-dynamics-schemas/codeunit/BOMImport\"><pConstructionJob>" + args[0] + "</pConstructionJob><result></result></RunTask></soap:Body></soap:Envelope>";                     

            XMLHTTP.open("POST", url, false, domain+"\\"+user, pw);
            XMLHTTP.setRequestHeader("Content-type", "text/xml");
            XMLHTTP.setRequestHeader("SOAPAction", url+":RunTask");
            XMLHTTP.send(xmlText);
            Console.WriteLine("Status:" + XMLHTTP.status + " " + XMLHTTP.statusText);
            //XMLDoc.load(XMLHTTP.responseXML);
            Console.WriteLine(XMLHTTP.responseText);
           

        }       
    }
}



Ömm, xmlhttp? Also ein selbstgestricktes SOAP-Envelope per http post rüberschieben finde ich "kreativ".

Wieso nimmst Du keine WebService Reference und lässt das .NET selber machen?
Warum übergibst Du nicht das komplette File über Webservice an NAV und hast im NAV in einer Setup-Tabelle den Verarbeitungs/Speicherort hinterlegt?

Das ist bis dato Limitierungen von der Anwendung, die das XML File erstellt...kann nur ein File erzeugen und in deren Post-Command Schnittstelle kann man bspw. keine Referenzen benutzen.

Der Ansatz mit MSXML als COM Bibliothek funktioniert ja auch genauso im Web bspw. über Javascript. Das passt schon so. Aber ich probiers nochmal mit der Webservice Referenz, da gibts den DefaultCredentialProvider vielleicht benutzt der dann die Anmeldedaten über die Servergrenze hinweg.

Schonmal danke soweit.

So ich habe es vorhin mal mit dem .net Webclient probiert, genau das gleiche in Grün.
Wenn das XML Automation Object erstellt und die Methode load aufgerufen wird um die XML Datei zu parsen.
Name DataType Subtype Length
XMLDoc Automation 'Microsoft XML, v6.0'.DOMDocument

c# code:

Code:

            //neue Version über Webservice Referenz                   
            com.local.entwicklung.BOMImport webservice = new com.local.entwicklung.BOMImport();
            webservice.Credentials = new System.Net.NetworkCredential(user, pw, domain);
            webservice.PreAuthenticate = true;
            webservice.UnsafeAuthenticatedConnectionSharing = true;
            webservice.UseDefaultCredentials = true;
            webservice.Timeout = 9000000;
            String result = webservice.RunTask(args[0]);
            Console.WriteLine(webservice.GetType());           
            Console.WriteLine("Running as: " + System.Security.Principal.WindowsIdentity.GetCurrent().Name);
            Console.WriteLine("Result: " + result);

Result: Error in processing K123456: This message is for C/AL programmers: The c
all to member load failed: Zugriff verweigert


Wird wohl daraus hinauslaufen müssen das der Datenstrom direkt über den Webservice verarbeitet wird.

und noch eine Feststellung, es liegt auch nicht am XML Objekt selbst. Sobald ein simples File.COPY über den Webservice auf nicht-lokale resourcen gestartet wird, wird laut Procmon eine Access Denied Meldung geworfen (obwohl der Dienst richtig "impersonated" wird)

Code:

Result: Error in processing K123456: Either the caller does not have the require
d permission or the specified path is read-only.

Also liegt das Problem ja wo anders

Das hört sich recht stark nach einem Delegierungsproblem an. Hast du SPNs und Delegierung korrekt eingerichtet (http://msdn.microsoft.com/en-us/library/dd568720.aspx), für den CIFS-Dienst im speziellen?

Falls du mit einem Windows Server 2008+ arbeitest auf dem die Freigabe liegt, schau dir bitte auch diesen Artikel an: http://support.microsoft.com/kb/2621984.

Hallo SilverX,

nein da habe ich noch nichts gemacht, das war mir bis dato unbekannt das explizite Deligierungen eingerichtet werden müssen. Ich hoffe das es daran liegt!
Ich muss mich da erst einmal einlesen.


Edit:

da bei mir der Service Tier und der SQL auf der gleichen Maschine läuft, benötigt man laut diesem Dokument hier keine Delegation.
http://msdn.microsoft.com/en-us/library/dd355184.aspx

da bei mir der Service Tier und der SQL auf der gleichen Maschine läuft, benötigt man laut diesem Dokument hier keine Delegation.
http://msdn.microsoft.com/en-us/library/dd355184.aspx

Nicht zwingend für den SQL Zugriff, aber für den Dateizugriff, wenn der UNC-Pfad außerhalb des NAV Servers liegt und der Initiator (Webservice, Client) nicht auf dem Rechner mit dem NAV Server ausgeführt wird.

Ich habe zum Test mal den Server für CIFS delegiert (also nicht den Useraccount der als Dienstekonto eingetragen ist): funktikoniert


Vielen herzlichen Dank, besonders an SilverX !

Ups, sorry ist erledigt!