rmw Geplaatst: 24 december 2013 Delen Geplaatst: 24 december 2013 Er is nog geen FMS13 subforum, dus daarom maar even hier. Bij het omzetten van een FMS12 naar FMS13 loopt een server side script ineens niet meer. Het blijkt dat het importeren van een XML bestand met een XSLT omzetting fout 718 teruggeeft. Dat is een fout in het parsen van de XML. Aanbod XML en XSLT bestand zijn, natuurlijk , niet gewijzigd. Een FM13 client kan het script wel uitvoeren: zelfde XML, zelfde XSLT. Iemand hier al ervaring mee? Is er in het parsing mechanisme van de server wat gewijzigd? Zijn er beperkingen van kracht geworden die in FMS12 als 'undocumented feature' toevallig nog wel beschikbaar waren? Ik kan in de release notes niks vinden.... rmw Quote Link naar reactie
0 Felix Geplaatst: 24 december 2013 Delen Geplaatst: 24 december 2013 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 rmw Geplaatst: 24 december 2013 Auteur Delen Geplaatst: 24 december 2013 Volgens mij volg ik die regels netjes, want dat was met FMS12 ook al het geval. Maar waarom doet FM13 Pro het dan wel goed en de server niet? En die parser is tussen FMS12 en FMS13 niet gewijzigd volgens mij... rmw Quote Link naar reactie
0 Felix Geplaatst: 24 december 2013 Delen Geplaatst: 24 december 2013 (aangepast) . 5 oktober 2015 aangepast door Gast Quote Link naar reactie
0 menno Geplaatst: 24 december 2013 Delen Geplaatst: 24 december 2013 krijg je fout 718 ook niet als het xsl-bestand niet wordt gevonden of onleesbaar is? In welke directories staan je xml en xslt? Quote Link naar reactie
0 rmw Geplaatst: 25 december 2013 Auteur Delen Geplaatst: 25 december 2013 Het bevreemd me, omdat ik 'slechts' de installatie van FMS12 vervangen heb door FMS13. Alle bestanden, alle rechten, alle directories zijn gelijk gebleven. De import is via een URL en het XSLT bestand staat in de Documents directory van FMS13. Dat is de enige locatie die je bij import/export in een server side script tot je beschikking hebt (naast TemporaryPath, maar dat is wat lastig voor een locatie van een vast bestand ) Mogelijk dat het XML bestand dat ik via de URL opvraag niet goed terug komt???? We puzzelen verder (als de kerst voorbij is ) rmw Quote Link naar reactie
0 menno Geplaatst: 25 december 2013 Delen Geplaatst: 25 december 2013 Ik heb ff een uurtje zitten testen met diverse bestanden en opties ... met fms12 is het geen enkel probleem om iets te importeren van een URL of uit de documents-directory (tekst, xml, fmp etc.etc). Precies hetzelfde met fms13 lukt dat met xml/xsl van geen kanten, niet van een URL en niet uit de d-d. Het lijkt mij een bug. Ik gebruik exact deze techniek voor een koppeling met een boekhoudpakket, dus ga daar voorlopig niet upgraden naar fms13. Ter info: fms12/13 zijn (uiteraard allebei afzonderlijk) geïnstalleerd op een Windows 2008 R2 server. Ik heb op beide machines in de directory C:\Program Files\Filemaker\Filemaker Server\Data\Documents de bestanden Data.xml en Stylesheet.xsl staan. Verder heb ik in mijn netwerk op een webserver dezelfde bestanden gepubliceerd. Ik heb een identiek SomeData.fmp12 op de beide fms's geshared. In SomeData zit één script: Importeer xml-data. Laat ik deze op een FMP-advanced draaien of op fms12, dan loopt het als een zonnetje, waarbij het niet uitmaakt of via een URL of lokaal importeer .... op fms13 werkt het helemaal niet, ik krijg altijd 718 : error in parsing XML (from Xerxes) Lijkt me duidlijk een bug: fms kan geen xml mbv xsl importeren. Ik heb ook nog even getest of een fmpxmlresult wel kan worden geïmporteerd en dat lukt prima, maar zodra een xsl aan de import wordt gekoppeld, dan wordt altijd error 718 teruggegeven. Ook nog even getest met fms13 op een MacOSX 10.9 ... het setje bestanden vanaf de windows-server gekopiëerd naar de mac en daar werkt het gewoon. Het probleem beperkt zich dus tot windows. Quote Link naar reactie
0 rmw Geplaatst: 25 december 2013 Auteur Delen Geplaatst: 25 december 2013 menno, wat moeten we zonder jou 'Het zelf doen' zou mijn vrouw zeggen Top dat je het zo gedetailleerd heb willen nazoeken! Nu is het wachten op v2 rmw Quote Link naar reactie
0 menno Geplaatst: 25 december 2013 Delen Geplaatst: 25 december 2013 Was niet zonder eigenbelang, want ik wilde net gaan pushen om op zoveel mogelijk plekken fms13 te gaan inzetten. Voor een aantal projecten ga ik dat ff uitstellen. Op het forum van Filemaker heb ik inmiddels een bug-report neergezet met een voorbeeld waarmee ze kunnen testen. Quote Link naar reactie
0 rmw Geplaatst: 4 april 2014 Auteur Delen Geplaatst: 4 april 2014 Ben (nog) niet in de gelegenheid dit in v2 uit te testen, maar wel erg benieuwd of het is opgelost... Al iemand die er wat over kan zeggen? rmw Edit: de update is voor Pro en Advanced en niet voor de server...er valt dus nog niets te testen of te zeggen...sorry Quote Link naar reactie
0 menno Geplaatst: 10 mei 2014 Delen Geplaatst: 10 mei 2014 Heb de server 13v2 vandaag getest met xml/xsl-import (op windows server 2008) en het werkt weer als een zonnetje Door FMI opgelost dus. Quote Link naar reactie
0 Petterderhaag Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Beste Iedereen, Dit is mijn eerste post en bij voorbaat excuses als het hier niet gebruikelijk is om op 'oude' forum-posts te reageren. Ik loop (volgens mij) tegen exact hetzelfde probleem aan. Ik wil zowel een import als export via xml doen. Ik heb daarvoor XSLT's in elkaar gehackt die via een client (mijn eigen, FM Pro Advanced 14) als een zonnetje draaien. Wil ik hetzelfde via de server side doen dan krijg ik altijd een 718 server error terug. De achterliggende gedachte bij deze processen is dat ik data uit een ander systeem haal; daarmee communiceer ik via XML. Idealiter laat ik de import (en export van FM) 's nachts elke dag lopen en heb ik er geen omkijken meer naar. Op het moment moet ik dus elke dag deze imports/exports draaien, waardoor mijn Filemaker weer een half uur bezig is en ik er niets mee kan. Lastige in mijn specifieke situatie is dat ik gebruik maak van FMS hosting en dus niet zomaar in de server-logs kan gaan zitten neuzen en afhankelijk ben van mijn Hosting Partij om bestanden aan te passen of zelfs system-level scripts in te stellen! Hier zijn ze overigens wel heel erg behulpzaam bij. Ter info: ik werk zelf op een Macbook, terwijl de server op een virtuele windows server gehost staat. Mijn vraag is dus, is er iets dat ik nog anders kan doen/proberen om de situatie op te lossen? Alvast hartelijk dank voor jullie hulp! Petter Quote Link naar reactie
0 menno Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Welkom Petter! Welke versie FMS draait bij jouw hosting? Waar staan de xsl's? In de documentenmap van de FMS? Op het web? Op een ander pad? mvg, Menno Quote Link naar reactie
0 Petterderhaag Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Hoi Menno, De FM-versie die draait is 13.0.9.905. De xsl's staan op een ftp-server die afhankelijk van de import een ander adres heeft. Deze naam wordt doorgegeven dmv een $variabele die afhankelijk van de import/export wordt opgesteld vantevoren in hetzelfde script. Dit werkt lokaal hartstikke goed, server-side dus minder. Mijn hosting partij heeft getest met de xslt's in de documents folder maar dat mocht niet baten. Een kleine inzage in het script, met wat achtergrond: het gaat om een import voor verschillende dealers en per dealer een drietal verschillende files. Hier loopt de import doorheen. Op het moment dat alle bestanden voor alle dealers zijn geïmporteerd stopt het script. Lokaal werkt het script in mijn Documents folder, aan de server-zijde zou het dus de Documents folder aldaar moeten zijn. Dank voor eventuele inzichten! Petter # FTP Import Script Set Variable [ $param ; Value: Case(IsEmpty(Get(ScriptParameter)) ; 0 ; Get(ScriptParameter)) ] Set Variable [ $server_path ; Value: Get(DocumentsPath) ] Set Variable [ $files ; Value: Case($param = 0 ; List("Worklist.xml" ; "Reports.xml" ; "Quotations.xml"); $param = 1 ; "Worklist.xml"; $param = 2 ; "Reports.xml"; $param = 3 ; "Quotations.xml" ) ] Set Variable [ $$log_import ; Value: "Import started on " & Get(CurrentTimestamp) & ". From Script: " & Get(ScriptName) ] Set Variable [ $ftp ; Value: ] Set Variable [ $ftp_dea ; Value: $ftp & "OUT/" ] Set Variable [ $ftp_xslt ; Value: $ftp & "XSLT/" ] Perform Script [ “IMPORT_SET_DEA” ] Set Variable [ $dealist ; Value: Get(ScriptResult) ] Set Variable [ $exit_2 ; Value: ValueCount($files) ] Set Variable [ $exit_1 ; Value: Case(IsEmpty(ValueCount($dealist)) ; 1 ; ValueCount($dealist) / 2) ] Loop Set Variable [ $count_1 ; Value: $count_1 + 1 ] Set Variable [ $dea_id ; Value: GetValue($dealist ; (($count_1*2) - 1)) ] Set Variable [ $dea_name ; Value: GetValue($dealist ; $count_1*2) ] Loop # Second loop to download each different file Set Variable [ $count_2 ; Value: $count_2 + 1 ] Set Variable [ $file ; Value: GetValue($files ; $count_2) ] Set Variable [ $file_xslt ; Value: Left($file ; Length($file) - 3) & "xslt" ] Set Variable [ $address ; Value: $ftp_dea & $dea_name & "/" & $file ] Set Variable [ $address_xslt ; Value: $ftp_xslt & $file_xslt ] If [ $file = "Worklist.xml" ] Go to Layout [ “IMPORT_LEA” (IMPORT_LEA) ] // Show All Records Import Records [ No dialog ; $address; $address_xslt ; Add; Mac Roman ] Set Variable [ $lasterror ; Value: Get(LastError) ] Set Variable [ $foundcount ; Value: Get(FoundCount) ] Set Variable [ $foundtable ; Value: Get(LayoutTableName) ] Else If [ $file = "Reports.xml" ] Go to Layout [ “IMPORT_LEA_ACT” (IMPORT_LEA_ACT) ] // Show All Records Import Records [ No dialog ; $address; $address_xslt ; Add; Mac Roman ] Set Variable [ $lasterror ; Value: Get(LastError) ] Set Variable [ $foundcount ; Value: Get(FoundCount) ] Set Variable [ $foundtable ; Value: Get(LayoutTableName) ] Else If [ $file = "Quotations.xml" ] Go to Layout [ “IMPORT_HOT” (IMPORT_HOT) ] // Show All Records Import Records [ No dialog ; $address; $address_xslt ; Add; Mac Roman ] Set Variable [ $lasterror ; Value: Get(LastError) ] Set Variable [ $foundcount ; Value: Get(FoundCount) ] Set Variable [ $foundtable ; Value: Get(LayoutTableName) ] End If Perform Script [ “LOGGING” ; Parameter: List("lasterror" ; $lasterror) ] Perform Script [ “LOGGING” ; Parameter: List("foundcount" ; $foundcount & " From: " & $foundtable) ] Exit Loop If [ $count_2 >= $exit_2 ] End Loop # Setting the count variable to 0, otherwise the 'GetValue' command does not work properly Set Variable [ $count_2 ; Value: 0 ] Exit Loop If [ $count_1 >= $exit_1 ] End Loop Quote Link naar reactie
0 menno Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Ik denk dat het downloaden van xslt's niet lukt. Ik denk dat het ftp'en de boosdoener is. Probeer te achterhalen of je de xslt's niet gewoon mer http en zonder login kan bereiken, dan weet je of het werkt. Quote Link naar reactie
0 menno Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Ik zit nu achter mijn computer en heb je script wat nader bekeken .... wat in jouw voorbeeld niet is te zien, is hoe je de bestanden ophaalt .... dat is waarschijnlijk met "Insert from URL" en dat zal nog wel goed gaan, maar daarna kan je alleen maar doen "Export field contents" naar de document-directory en dat is niet mogelijk met FMS .... zodoende is het pad naar de xslt ongeldig en dus is de xslt ongeldig en dus zal de parser een foutmelding geven en dat is 718. Als je de te importeren xml's ook in die directory zet met dezelfde methode, dan zullen die daar ook niet staan. Het is op zich begrijpelijk dat je niet zomaar bestanden in die documents-directory mag plaatsen, want je zou op die manier allerlei (schadelijjke) binaries kunnen plaatsen. Records exporteren lukt weer wel, want in welk beschikbaar (fm, txt, dbf etc) formaat je dat ook doet, het blijven tekst-gegevens uit FM en die zijn per definitie ongevaarlijk voor de server. Quote Link naar reactie
0 Petterderhaag Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 UPDATED na het lezen van Menno's uitgebreidere reactie: Ik voeg de records toe door de "import records" stap toe te passen. Deze halen dan via 'calculated' het bestand op dmv een opgezette variabele: <...> Set Variable [ $file ; Value: GetValue($files ; $count_2) ] Set Variable [ $file_xslt ; Value: Left($file ; Length($file) - 3) & "xslt" ] Set Variable [ $address ; Value: $ftp_dea & $dea_name & "/" & $file ] Set Variable [ $address_xslt ; Value: $ftp_xslt & $file_xslt ] If [ $file = "Worklist.xml" ] Go to Layout [ “IMPORT_LEA” (IMPORT_LEA) ] // Show All Records Import Records [ No dialog ; $address; $address_xslt ; Add; Mac Roman ] <...> $ftp_dea --> ftp://:@ /OUT/ $ftp_xslt --> ftp://:@ /XSLT/ De foutmelding die ik overigens krijg is "719". Dat verwees mij weer naar: http://support.goya.com.au/discussions/base-elements/319-error-719-error-in-transforming-xml-using-xsl-from-xalan . De bestanden die aangeleverd worden zijn door een Microsoft SQL server aangemaakt en daardoor dus UTF-16. Zou dat een mogelijke fout kunnen opleveren? -- EINDE UPDATE -- Hey Menno, Helaas staan de bestanden beschermd op een ftp-server. Ik ga even kijken of ik ergens een open ftp server kan vinden waarbij ik het via een aantal bestandjes kan testen. Denk je echt dat het dat is? Schijnbaar (ik kan dat dus helaas niet zelf testen) zijn lokale xslt's in de documents folder ook niet genoeg. Wat ik me afvraag; heb ik nou een weinig gangbare methode om data te im- en exporteren in Filemaker databases uitgekozen? Groeten, Petter Quote Link naar reactie
0 menno Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Het probleem is niet de ftp-server, maar "Export-Field-Contents" dat kan gewoon niet op FMS. De xml-import kan volgens mij niet met het ftp-protocol overweg. Je kan daar alleen file(win/mac): gebruiken of direct/calculatie http, maar geen ftp. Je zou de beheerder kunnen vragen voor jou een mapje te maken in de documenten-directory dat van FMS is, maar voor jou van buiten af wél benaderbaar (anders kan je niks onderhouden). Dan kan je de xml-bestanden gewoon via http importeren en de xslt's aanwijzen in de documents submap. [EDIT]Ik zie nu dat dat ook niet gaat, want de xml's staan ook op een FTP-server ..... gaat dus niet op deze manier. Je zal de bestanden eerst op een plek moeten zetten waar de FMS er met HTTP(S) bij kan komen[/EDIT] Quote Link naar reactie
0 menno Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Jouw methode is helemaal niet zo raar, alleen FMS bedient niet alleen jou, maar nog een heel groepje andere gebruikers (in potentie dan uiteraard). Als al die gebruikers nou theoretisch hetzelfde doen als jij en ook nog eens dezelfde bestandsnamen zouden gebruiken, dan zit je elkaar behoorlijk in de weg. Daarnaast is er ook nog eens de security-issue die ik voorheen al noemde met binairies enzo. FMS kan alleen maar tekst-gegevens exporteren vanuit de eigen records en importeren kan alleen met data die al lokaal in de documentenmap staat of via http Quote Link naar reactie
0 Petterderhaag Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Dank voor je snelle reacties en het meedenken; ik ben gewoon oprecht nieuwsgierig (en licht gefrustreerd, dat wel ) naar waaróm het niet aan de server-zijde werkt. Het script is getest op compatibele stappen en zou voor zover ik in de documentatie lees gewoon moeten werken. De documentatie van Filemaker, helaas niet superduidelijk (http://help.filemaker.com/app/answers/detail/a_id/13579/~/importing-xml-data) heeft het over een HTTP-request, hier valt dan ook de ftp-server onder. Overigens gebruik ik "Export Field Contents" nergens; het is puur een import records from XML, de locatie laat ik via calculation plaatsvinden want de url staat in een variabele ingesteld. Nogmaals, lokaal werkt dat zonder problemen, via de server levert dat een vertalingsprobleem (error 719) op. Gelukkig zou de import/export alleen maar vanuit één account (namelijk de Admin-account) gebeuren, en zitten er derhalve ook geen documenten in de Documents Folder van Filemaker Server, omdat die allemaal direct vanuit de FTP worden ingelezen. Quote Link naar reactie
0 menno Geplaatst: 21 oktober 2015 Delen Geplaatst: 21 oktober 2015 Zo, ben net thuis en heb jouw methode eens geprobeerd en direct met ftp ipv http iets van mijn server te downloaden, met een xml en een xslt aldaar. Vanaf de client ging dat prima en daarna het fm-bestand op de server gezet en vervolgens met PSOS de download door de FMS laten doen .... werkt perfect! Eerlijk gezegd wist ik helemaal niet dat je ook FTP direct kan gebruiken in de http-request, weer wat geleerd Het werkt dus gewoon wél (overigens heb ik het nu getest met FMS 14, maar dat maakt denk ik niks uit, want aan de import is helemaal niets gewijzigd sinds 13) en dus is er inderdaad een probleem met het besstand dat je importeert, of met de xslt. Fout 719 - "Fout tijdens omzetten van XML met behulp van XSL (uit Xalan)" is waarschijnlijk correct, want als ftp niet werkt of het pad klopt niet of de credentials kloppen niet, dan krijg je in alle gevallen fout 1631 - connection failed Kan je niet gewoon eens zelf een xml-bestand aanmaken met een xslt (zodat je 100% zeker weet dat die bestanden werken) en die uploaden naar de bewuste FTP-server en kijken wat er gebeurt. Dan weet je tenminste enigszins waar je moet gaan zoeken. Quote Link naar reactie
0 Petterderhaag Geplaatst: 28 oktober 2015 Delen Geplaatst: 28 oktober 2015 Kleine Update: Heb met hulp van de BaseElements plugin een werkende éérste stap gekregen (downloadt, converteert en importeert zowel lokaal als server-side de xml mbv de xslt). Overigens met exact dezelfde xslt; de xml verandert constant van content. Wellicht is Xalan minder tolerant wbt fouten? Blijf het gek vinden dat het lokaal wel lukt, maar server-side niet. Nu weer verder uitbouwen en dan ben ik van mijn probleem af! Mochten mensen daar interesse in hebben dan kan ik altijd wat schrijven over hoe ik het gedaan heb. Er zitten nogal wat verschillen in de paden die FM gebruikt tegenover die nodig voor de Plugin. Quote Link naar reactie
Vraag
rmw
Er is nog geen FMS13 subforum, dus daarom maar even hier.
Bij het omzetten van een FMS12 naar FMS13 loopt een server side script ineens niet meer.
Het blijkt dat het importeren van een XML bestand met een XSLT omzetting fout 718 teruggeeft.
Dat is een fout in het parsen van de XML.
Aanbod XML en XSLT bestand zijn, natuurlijk , niet gewijzigd.
Een FM13 client kan het script wel uitvoeren: zelfde XML, zelfde XSLT.
Iemand hier al ervaring mee?
Is er in het parsing mechanisme van de server wat gewijzigd?
Zijn er beperkingen van kracht geworden die in FMS12 als 'undocumented feature' toevallig nog wel beschikbaar waren?
Ik kan in de release notes niks vinden....
rmw
Link naar reactie
21 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.