Ga naar inhoud
  • 0

Server sided script: aanroep van een ander script?


SuperWimmie

Vraag

Dag allemaal,

 

Ik gebruik FM Pro en FM Server versie 13.0.9.905.

 

Zodra ik een "Perform Script on Server" doe, dan doet hij dat goed. Ik heb rekening gehouden met records en layouts, omdat het script een nieuwe user hanteert die dat allemaal mee moet krijgen.

In dat script gebruik ik het commando Perform Script om andere scripts aan te spreken, die o.a. berekeningen bevatten.

 

Nu blijkt dat de server deze tweede aangeroepen scripts niet uitvoert.

 

Qua rechten lijkt er niets aan de hand te zijn.

Zodra ik op FM Pro als admin inlog, lijkt het alsof de script wel worden uitgevoerd, maar wel erg traag, met het bekende kopje koffie op het scherm.

Alsof het toch via het werkstation wordt uitgevoerd, zo lijkt het.

Log ik in als beperktere gebruiker, dan is het het script veel sneller klaar, maar dan blijken de extra aangeroepen scripts niet te hebben gewerkt.

 

Iemand enig idee hoe dit zit?

Link naar reactie

16 antwoorden op deze vraag

Aanbevolen berichten

  • 0

Ah, opgelost.

 

Ik had een foutje in de scriptparameters zitten (één zoekargument op een te hoog regeltje in de parameters).

Eenmaal gerepareerd werkt het perfect!

 

Dank voor de reactie, Felix!

 

Aanvulling: wel vreemd dat als ik als Admin ben ingelogd, het programma blijkbaar de instellingen (gevonden set records) overneemt naar de server toe.

Zodra ik niet als admin ingelogd ben, grijpt hij vervolgens wel mis omdat de server blijkbaar toch als "admin" aan de slag gaat.

Er is dus verschil in gedrag, afhankelijk of de gebruiker wel of niet als admin is ingelogd.

Link naar reactie
  • 0

Wat ik begrepen heb is dat de serversided script met de zelfde rechten start als de persoon die hem aanroept.

Een serversided script werkt als een nieuwe gebruiker die inlogt, dus die zal een start script doorlopen (indien aanwezig)

en daarna het script doorlopen. Het is dus zaak om te controleren of het startscript (indien aanwezig) geen roet in het

eten gooit, je kunt dit eventueel ook afvangen in het start script zodat als het startscript van de server wordt opgestart

deze wordt afgebroken.

 

Het script wat je serversided start heeft voor zover ik weet niet de zelfde selectie als de gebruiker, je moet er dus voor zorgen

dat de selectie wordt overgebracht als je op een selectie een bewerking wilt doen. Het is erg handig om de handelingen van

een serversided script in een log op te slaan, zodat je kunt volgen waar een script de mist ingaat.

 

Groet, Ruben

Link naar reactie
  • 0

Als je een script op server laat uitvoeren heb je bepaalde gegevens nodig.

Ik heb vernomen dat je deze niet kan meegeven via een variabele.

Via welke mogelijkheden is dit wel mogelijk ?

 

Op de databank staat ook een script dat geactiveerd wordt bij het sluiten van de databank.

Ik merk dat de scriptstap "script op server" uitvoeren deze scriptstap ook gaat activeren.

Is er een mogelijkheid om dit te omzeilen.

Link naar reactie
  • 0

Variabelen werkt inderdaad niet, omdat de server compleet opnieuw inlogt met een andere user (of sessie) om het script te draaien.

 

Parameters.

Dat is de oplossing.

 

Via de Enter kan je een script opgeven met parameters, waar elke regel een aparte parameter wordt.

 

Via

getvalue ( get ( scriptparameter ) ; 1 )

lees je de eerste regel van de parameter uit in het serverscript.

 

Door meerdere parameters op te kunnen geven kan je vrijwel alle info overdragen naar de server toe.

Link naar reactie
  • 0

Dat klopt inderdaad: je moet gegevens doorgeven via een scriptparameter. En terug ook weer met get(scriptresult), als dat nodig is.

 

Voor de duidelijkheid: globale velden werken dus ook niet, want die zijn ook beperkt tot de sessie. En daar zit nog een adder het gras: een globaal veld kan natuurlijk een default waarde hebben, die WEL geldig blijft, waardoor het lijkt alsof het script met verkeerde waarden aan het werk gaat.

 

Wat betreft een 'close script': je sluit na het beëindigen van het serverside script inderdaad de virtuele sessie en daarmee de file. Je moet dus specifiek in het serverside script een $$variabele of globaal veld van een marker voorzien, en in het close-script op die marker testen, als je dat script niet wilt uitvoeren.

Link naar reactie
  • 0

Wat ik in dergelijke gevallen doe, is vooraf testen of een script lokaal of via de server gedraaid moet worden.

 

Met dit commando is het simpel na te gaan, of er een server in het spel aanwezig is, of niet.

 

If PatternCount ( Lower ( Get ( HostApplicationVersion ) ) ; "server" ) > 0

uitvoeren serverside

else

uitvoeren lokaal

endif

 

Dit maakt het testen op een lokale computer wat gemakkelijker tijdens het ontwikkelen van dergelijke scripts.

 

Feit blijft dat je erg goed moet bedenken wat de server precies doet. Het nieuwe inlogaccount en de nieuwe sessie maakt dat simpele zaken zoals de gevonden recordset, opstartscripts etc. allemaal opnieuw moeten worden bepaald op de server.

Dat vergt enig nadenken.

Link naar reactie
  • 0

En ik zou er nog dit aan willen toevoegen: als je grote sets records aanpast of verwijdert (wat vaak de reden is om het op de server uit te voeren) kun je er niet zomaar van uitgaan dat de client dat ook allemaal bijtijds in de gaten heeft.

 

Wait for completion is wel nuttig maar biedt geen controle over de (lokale) cache, helaas.

 

HE

Link naar reactie
  • 0

Is volgende correct :

Als je bv de accountname wil meegeven dien je op de lokale laptop het volgende script op te starten.

script op server uitvoeren ["test server""; parameter:invoer::accountname] (mag je hier een variabele gebruiken)

en kan je deze in het script op de server ophalen met

variabele instellen [$$var; Waarde:Get(ScriptResultaat)]

 

Maar hoe kan je dan verschillende gegevens ophalen.

dien je dan altijd een script uit te voeren per parameter .

Link naar reactie
  • 0

Nee, het zit net even anders.

 

Je roept een "Perform script on server" aan.

Als Parameter (feitelijk kan je maar één parameter opgeven) maak je een samengestelde tekst aan, waarbij het standpunt geldt dat één parameter per regel gebruikt gaat worden.

 

Bijvoorbeeld deze parameter:

 

"server" & "¶" & get (accountname) & "¶" & TABEL::veldwaarde

 

Doordat die ene parameter uit 3 tekstregels bestaat, kan je de ene parameter bij het uitvoeren van het script weer uit elkaar trekken en per regel uitlezen wat er is meegestuurd.

Let er wel op dat veldwaarden dan ook maar uit 1 regel mogen bestaan, anders loopt het mis.

 

Het uitlezen per regel kan eenvoudig via de getvalue functie.

Dan heb je in het nieuwe script zo weer de juiste parameters te pakken en kan je de uitvoering er op sturen.

 

Dus:

$server = getvalue ( get ( scriptparameter ) ; 1 ) // en krijgt de waarde "server" mee.

$accountwerkstation = getvalue ( get ( scriptparameter ) ; 2 ) // en krijgt de naam van het gebruikte account mee.

Link naar reactie
  • 0

Zoals Wim al zegt, debuggen moet je op je werkstation met FMPA doen. Daarna kan je het script op de server laten uitvoeren.

 

Verder kan je in de log-viewer van de FMS-console kijken welke meldingen het script op de server geeft. Helaas worden daar ook zaken gelogd die er niet toe doen en vooral irritant er worden fouten gemeld die geen fouten zijn. Voorbeeld: een programma-lus waarin de stap GoTo Next Record [exit after last] in staat. Iedere keer dat het laatste record in de lijst wordt verwerkt en die er voor moet zorgen dat je uit de lus vandaan springt, wordt er een foutmelding gelogd:

Schedule "Currency Updaten" scripting error (101) at "System : Update Records : Go to Record/Request/Page".

De genoemde stap die fout zou zijn is in werkelijkheid

GoTo Next Record [exit after last]

en deze levert in de debugger in FMPA helemaal geen fout op, de enige manier om specifiek deze fout te voorkomen is een stap

Exit-Loop-If [ Get ( RecordNumber ) = Get ( FoundCount )]

voor deze stap te zetten.

Link naar reactie
  • 0
... en deze levert in de debugger in FMPA helemaal geen fout op ...

 

Om helemaal correct te zijn, dat doet ie wel: zet 'pause on error' maar eens aan in het debug menu... de uitvoering stopt :(

 

Maar dat doet niks af aan het feit dat het een behoorlijk irritante melding is.

Hij verschijnt ook het de admin console bij de schedules.. alsof het schedule niet gedraaid heeft.

De oplossing van menno is bruikbaar. Ik gebruik altijd GoToLayout[original layout] als extra stap na de loop.

Voor een script op de server maakt het tenslotte toch niet uit op welke layout hij eindigt :)

 

rmw

Link naar reactie

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.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...