Use Event Handlers to detect Submission Completion for IOM Local and IOM Remote connection providers

[smorrisj]

Describe the bug We're currently hardcoding the sas result htm file names with guids to get around issues that were seen with parsing the output file name from the output log to detect submission completion. In that scenario, certain environments would not output the specific text string to denote completion. With these connection providers, there is a SubmissionComplete event that can be wired up in script.ts instead, so that we can stop hardcoding result names.

Steps to reproduce Steps to reproduce the behavior: 1.) local or remote IOM connections, enter a simple test program: %put 1; 2.) navigate to the work directory, observe that the result htm file names have guids. Observe that result files are generated for submissions that do not have actual ods output.

Expected behavior We need to be using Event Handlers to detect submission completion. Also remove the uuid naming strategy that currently exists for generating result files for submissions.

Screenshots See me for internal screenshots

[scottdover]

I believe this is the bigger issue we were running into with this:

If we use one file name, we can't reliably detect if we're reading the correct file or not after a SAS program runs. For example, suppose we run a sas program that generates sashtml.htm. On a second run, we don't know if that file is associated with the 2nd run or the first. Viya solves this problem for us because the output contains a line like NOTE: Writing HTML5 Body file .... However, sas 9 doesn't do this for us.

To solve that, we need to know:

• When a sas 9 program finishes running
• if that run of the program outputs an html file
• where that html lives

So, if we use the SubmitComplete event, I still think that only partially solves the problem.

[smorrisj]

It seems like IOM should have an api or programmatic way to inspect result files without the need to parse the log. @clangsmith do you know if we're able to do this? This seems like a common problem that sas 9 apps built on top of IOM would have run into. I was hoping that the combination of using the SubmitComplete event handler on LanguageService coupled with having a programmatic way to fetch the results file would mean that we didnt need to rely on log parsing to determine completion status.

I worry that if users redirect log output, and we rely on log parsing to determine completion status, that the absence of log output will break our implementation. There are many use cases where a user might want to redirect log output to a file, for example.

For Viya, we don't need to parse the log in order to know if execution is done. We currently poll the compute job state for one of the "done" statuses to know when we should expect a result and log to fetch. The result files and log are attached to the HATEOAS links on the job that we inspect once we have a done status.

In the short term could we possibly localize the guid file naming behavior to the sas 9 connections while we figure this out? There's no real reason that we need to have this behavior for the non SAS 9 connections.

[scottdover]

In the short term could we possibly localize the guid file naming behavior to the sas 9 connections while we figure this out? There's no real reason that we need to have this behavior for the non SAS 9 connections.

I've created https://github.com/sassoftware/vscode-sas-extension/pull/815 to handle this :)

[clangsmith]

Yes, we are absolutely able to do this (use the IOM events in this way). Other clients that use IOM, such as EG and AMO, have done this for many years. I'll look through the EG code, but I'm fairly certain EG accomplishes via a combination of SubmitComplete and ODS events on the IOM interfaces. I agree, we shouldn't be parsing the log, since that is not robust. Iterative steps though.

[Zhirong2022]

Run code below with local94 or IOM connection, 'SAS code running' keeps showing on the page unless cancel the running.

proc sort data=&indsn(keep=&x &y &datalabel) %if %length(&datalabel) %then
  out=sorted(rename=(&x=X &y=VALUE &datalabel=DATALABEL));
  %else out=sorted(rename=(&x=X &y=VALUE));
  ;
  by &x;
run;

[scnwwu]

also note #608

[scnwwu]

I tried 2 forms of the event listening in PowserShell

Register-ObjectEvent -InputObject $this.objSAS.LanguageService -EventName "SubmitComplete" -Action {
      Write-Host "hello"
}

$this.objSAS.LanguageService.Add_SubmitComplete({
      Write-Host "hello"
})

Neither work, which matches this thread It appears that PowerShell can't handle events from COM object.

[smorrisj]

I've noticed that sometimes the function names can be slightly off depending on the implementation for IOM libraries. @clangsmith would this be a case for inspecting the .interop dlls to grab those specific event names?

[clangsmith]

Yes, I agree, we should be using the event handlers. Yes, the interop dlls would show you the signatures. I'm happy to show.