Book a Demo

Author Topic: DocGen: Custom Script fragments can only be used once per session when using API  (Read 5111 times)

Uffe

  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Hi all,


This is one of those "please read it carefully and don't confuse the issue by uninformed guesswork" kind of posts. Please read it carefully and don't confuse the issue by uninformed guesswork.


When you create a document template and a template fragment, and the fragment is of the Custom Script variety, it only works once per session when you use the DocumentGenerator API (meaning you have to restart EA after each generation).
Subsequent attempts to generate the same document fail with the parent template working correctly, but the fragment producing no content at all. If you run the same document generation from the dialog, it works every time.

Some details.

A Custom Script fragment calls a function in a JScript script, which returns XML data. Has to be JScript for EA to accept it.

My generation script which uses DocumentGenerator is written in VBScript. If that script is in JScript, the generation always fails. Presumably this is due to the same bug, but that just affects me the toolmaker, not the end users.

When I say the fragment produces no content, this includes constant stuff (table header) outside the custom> content tag. Nothing is produced.

Content in the parent template which appears after the fragment does produce output, so the whole generation process doesn't break, just the fragment sub-process.


I've tried to trace how EA executes the document generation in the two cases.

When run through the GUI, the main document generation thread appears to reside in the EA process. Each Custom Script fragment gives rise to one SScripter/conhost process pair. (SScripter is EA's script runner executable, conhost is Windows' Console Host.)
In a template with multiple fragments, it looks like the SScripter process for one fragment remains for about half a second after the process for the next fragment has started up, but that might just be delays in the reporting. (I'm using the Windows Task Manager.)

Anyway, it works as expected and a trace printout in the fragment script comes out in EA's system output window.

When run through the API, there's one SScripter/conhost process pair for the main script, so far so good.
Then, the first run through the generation script, each fragment's SScripter/conhost start up, run and finish, one at a time as above.
In subsequent runs, however, the fragment processes never start. No content is generated for the fragment, and no trace printouts appear. DocumentGenerator.GetLastError() immediately after DocumentGenerator.DocumentPackage() reports nothing.

The generation script takes far less time to run, so it doesn't appear to hang-wait-timeout but rather to encounter an error and give up straightaway. I can find no zombie processes hanging around after the generation is completed, either when it works or when it fails.

I've monitored the various temp directories, and the only one where I find activity is AppData\Local\Temp, where EA creates three temp files on startup. The VBScript generation script gets "compiled" into a file here as well, which is then passed to SScripter (and deleted upon conclusion), but the JScript fragment scripts are handled differently and are not written to any files here.

I've had a look at the SScripter command line. It looks like this
Code: [Select]
SScripter.exe arg1 arg2 "arg3" "arg4" "arg5"From what I can ascertain, the arguments contain the following:
  • arg1: A number, unknown content; probably a reference to the package being documented but doesn't match anything in t_package or t_object.
  • arg2: A number; the PID of the EA session which launched the script runner.
  • arg3: A string; the GUID of the script in t_script.
  • arg4: A string containing a decimal number; probably a magic number telling SScripter what type of script is to be executed (suspiciously even in hex).
  • arg5: A string; either "Console" (for fragment scripts) or the file name of the "compiled" VBScript script in AppData\Local\Temp.

Now all this is mainly in order to show what a brilliant person I am, but also serves a background to the real question:

Is there a way to force a cleanup or reset so that the JScript fragments can be run multiple times through the API?

I can see nothing in the API itself, and I've found nothing in the temp directories (and EA's three temp files do not get modified during a generation run), but there's got to be something somewhere that's left over from the first run and then not reset until a new session is established.
"New session" means restarting EA. Reloading the project doesn't resolve the issue, neither does closing and re-opening it.


It would also appear that the behavior when using a Document Script fragment (where the script returns RTF) is similar, but worse: there running the generation through the API fails every time, but it does work when running it through the GUI.
However, I haven't analyzed this in any detail.

And finally, this is all in 13.5. We will upgrade in the next few weeks, but I need to have this document generation done before that.


/Uffe
« Last Edit: November 14, 2019, 01:29:35 am by Uffe »
My theories are always correct, just apply them to the right reality.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
This is one of those "please read it carefully and don't confuse the issue by uninformed guesswork" kind of posts. Please read it carefully and don't confuse the issue by uninformed guesswork.

[SNIP]

/Uffe
When I started reading this, I thought it sounded like one of those  "Tell 'em you're going to say it.  Tell 'em.  Tell 'em you said it. jobs.

All that was missing was a "thanks for reading this carefully..."  at the end ;)

Bugger of a problem, but.  (as we say colloquially here in WA - the rest of Oz, not so much (for Glassboy's benefit  :D))

Paolo
« Last Edit: November 14, 2019, 04:17:19 pm by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
I don't have an answer to your big question. I wouldn't expect there to be something intentional for it. At best, running some other script could clear whatever is being left in a bad state.

Correct me if I'm wrong, but I'd interpret your meta question as "How can I reliably and consistently generate my documentation?"

To answer that question... I'd suggest porting your top level script to run outside of EA, launch EA, load a model then do everything it already does. It should take minimal effort to move your VBScript to an external .vbs file and run it using cscript.exe. I don't know the specifics of your script, but it sounds achievable. Should take only a few minutes for a proof of concept at least.

Other than that... I don't know if this has been addressed in later versions. I don't have anything set up to test a situation like this. I did find a couple of lines in the release notes that may be relevant.
Quote
Dynamic Linked Document window now works with templates that use scripting
If the Dynamic Linked Document window suffered the same problem as your script, it would have failed once and never worked.

Quote
Document Script Generator - Corrected behavior when generating a report using a custom script if the results returned were greater then 16k
Probably not relevant since you mention it ran once.

Uffe

  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Hi again,


Thanks guys. I'm fairly convinced the whole problem is that SScripter is unable to recurse. I have some slight hope that this has been resolved in 1509:
Quote
Report generation where a fragment calls other fragments is now possible

... but then again, this should have worked already so p'raps not. We'll see. Meanwhile, I can make my generation work using .DocumentCustomData().
Going to an external script is not really a deployment option for me with this client, so I haven't tested that.

All that was missing was a "thanks for reading this carefully..."  at the end ;)
That'd be like tipping the waiter before they bring the food, wouldn't it?

Anyway, thanks for reading it carefully. :D


/Uffe
My theories are always correct, just apply them to the right reality.