SRP_Run_Command with OEngineServer

paxton

Greetings!


As I am using SRP_Run_Command to make a zip file using 7z.exe, I put "VAR" in the Output parameter, and I check for the presence of "Ok" in the output. If not there, I print out the command and output strings. I get the output on the dev machine, no problem.

example:
command = "7z a \\monkey\mediafiles\audio\62083\62083.zip \\monkey\mediafiles\audio\62083\*.mp3"
output = "VAR"
SRP_Run_Command(command,output)

Running OECGI/Openinsight 9.1.1 behind Apache2 server
interact with the browser (localhost)

Everything works fine on my development machine with OECGI (no Oengine server)

But when I move to the (test) production machine where I use OECGI3 there is some sort of failure and I am not getting any output.

When I run 7z from the command prompt window on the production machine, entering the exact command as reflected in my error message, it works fine. (I get the 7z output)

After installing 7zip and the SRP Utilities on the OECGI3 machine I restarted the oEngineServer (I have the folder with the 7z.exe on my path)

In all cases the files I am zipping are located in a share on a Linux machine and the resulting zip is placed in the same folder. No security on the shares.

Does OECGI3 need some registry tweaks for this to work?

Thoughts?

Paxton

BarryStevens

So you are running as an API via a browser?

Would it be able to see this: \\monkey\mediafiles\
Should not you be referencing a virtual directory name that points to this folder.

paxton

HI, Barry.
Thanks for the response.
Terminology is tricky. For development, I have Apache web server, OI and a Browser all running on the same machine (localhost).
the HTML pages use javascript to 'talk to' OI though OECGI. Works great. the files I am zipping are on a network share and it does not need to be mapped to a drive letter. works fine as \\monkey\mediafiles\.... (or, if Apache handles it, //monkey/mediafiles)

On my production machine, the only difference is the use of OECGI3 oengineserver . (the main web application has been running for years (thedce.com)

I have a 'test' production machine (h.thedce.com) set up like the real production machine to be sure the work I do with localhost transfers before going 'live'.
I do not believe there is a problem with accessing the network share as I can issue the 7z command from the command prompt with the same syntax and it works fine on all machinies. Using the same command in the SRP_Run_Command in my IO program seems to not return anything when running on the machine with oecgi3 (Oengineserver), but works fine on localhost. The only difference I know of so far is oEngineServer.

I'm puzzled.

BarryStevens

OK, that is now past my level of knowledge

DonBakke

Paxton - Your OECGI/OEngineServer session might not see the same folders. In fact, I would doubt it. Can you try UNC paths instead?

paxton

Don,
Thanks for the reply. I am using UNC paths.
In my example:
command = "7z a \\monkey\mediafiles\audio\62083\62083.zip \\monkey\mediafiles\audio\62083\*.mp3"
output = "VAR"
SRP_Run_Command(command,output)

Zip Works from command line anywhere, works from SRP_Run_Command when not using oengineserver.
But that is a good idea to explore. I can map the drive and see if that makes a difference. also,
I will build some simple cases, to eliminate network and sharing and report back.
Nice forum, by the way.

paxton

Don,
Did some research. It appears to be something with the combination of oengineserver and the zip program (7-zip) the command line versoin is 7z.exe
....
command = "ipconfig"
output = "VAR"
SRP_Run_Command(command,output)
doc = output //doc is sent to the browser
return
works with oengineserver and the output is returned to my browser

command = "7z a c:\1temp\1temp.zip c:\1temp\*.txt"
output = "VAR"
SRP_Run_Command(command,output)
doc = output
return
Fails and returns nothing to the browser using oengineserver
but works and returns the results if NOT using oengineserver

I wonder if oengineserver is losing the arguments or parameters of the 7z command.
any ideas

DonBakke

I doubt that the problem is related to losing arguments. Earlier when I suggested using UNC (BTW, I overlooked that this was what you were already doing...sorry about that), I was thinking your problem was due to the differences in the way a Windows Service has access to the environment versus a Desktop Application. We know from past experience that Engines which are managed through the OEngineServer don't always have access to the same resources (like mapped drives) and will fail. That was why I suggested UNC.

So, I still think we are dealing with a similar root problem: the Windows Service is not providing your 7-zip command line everything it needs to perform correctly. I simply have no idea as to what it is missing. Perhaps it is a Working Directory issue. Perhaps it is an environmental setting issue. It is hard to say without directly working on this myself.

paxton

Thanks, Don for the weekend reply.

Ah, the Windows service. Thanks for the ideas. I'll tinker around with passing Working Directory .
Is the Windows command prompt window a Windows Desktop Application? (since the command works there)

DonBakke

I don't have enough technical knowledge to answer that question. Others on my team might have an answer for you.

CorbyNagel

Paxton,

Can you explain what you mean by "Is the Windows command prompt window a Windows Desktop Application? (since the command works there)"?

Windows command prompt is definitely an application made for Windows, specifically Windows desktop. But the way you are saying it makes me think you are looking for it to be classified in some way.

paxton

Hi Corby.
Thanks for the post. I assume you have followed the saga above. I was just wanting to understand some terminology since Don mentioned "Windows Service" vs "Windows Desktop Application". The command line version of the 7-zip program works at the Windows command prompt but does not work when using OEngineServer with the SRP_Run_Command, but does work if not using OEnginveServer. I am guessing there is a problem related to the fact that 7z.exe uses 7z.dll (or maybe 7-zip.dll)

Nothing else for you or Don to do at this time. I am very appreciative of your help, input and time.
I'm going to tinker around with other ways to solve my application requirement.

paxton

Greetings FYI
I have confirmed that the associated .dll is not the issue.
I tried the original info-zip command... zip.exe with the same results. windows command ipconfig works fine with oengineserver.

DonBakke

Paxton - These results do not surprise me. I would have expected the command line to behave the same as the DLL call. They probably are both impacted by the same environmental differences. IPCONFIG is not constrained by such differences.

I know this is for a hobby, but at some point I suggest you consider whether your personal time is more valuable than than the cost of a working utility (SRP Zip).

paxton

Don,
I looked at SRP_Zip, the cost is OK, but it did not look like it did what I wanted.
In my application, I look up a particular folder's location in the OI database and then zip all the mp3 files in that folder leaving the zip file in the folder. Then I return the path to the zip file to the browser where the HTML5 attribute downloads the file.
As I said, a hobby, so I only work on this as the mood strikes :-)
My next plan, which I am now researching, is to use Apache2 cgi-bin to run a bat file with my zip command in it. I found info on how to do that so that is the next project.

Another thought is to use php, I used php in the early days to call OpenInsight, but it has been a long time.
I have also used php to perform downloads but have switched to using the capabilities of HTML5.

Did I misunderstand what I could do with SRP_Zip?

DonBakke

Paxton - Yes, I think you do not understand what you can do with the SRP Zip utility. Perhaps if you explained what you thought it was designed to do I can help explain things better. However, I thought the examples posted in the product information page basically duplicate what you are describing.

paxton

OK, Don. I took another look. In my case.
hZip = SRP_Zip_Open("\\monkey\mediafiles\59766\59766.zip")
   // I presume that if 59766.zip does not exist, it creates it and if succesful returns a filehandle else null
if hZip then
      resp = SRPZip_AddFile(hZip,"\\monkey\mediafiles\59766\*.mp3","","")
      SRP_Zip_close()
      // This leaves the file 59766.zip in the folder \\monkey\mediafiles\59766
end
Did I get that right? I presume resp contains a success or failure code?
When the mp3's are zipped into 59766.zip are the paths included (hope not, want just the files so no path will show up when unzipped.)
And, will the utility handle Unicode characters in the filenames? I bet that answer is 'of course', if Windows handles the characters the utility will.

DonBakke

Paxton - I get the impression you have not gone over to the technical documentation site for the SRP Zip utility. I think this will help you sort through your questions. But, to give you a quick response:

• SRP_Zip_Open will create the zip file if it does not already exist.
  
• SRP_Zip_AddFile does not add OS files. It adds data that you pass in via the Data argument. So, you cannot wildcard the filename in this routine. Rather, you write code that loops through the OS files you want, OSRead them, and pass this into the SRP_Zip_AddFile routine. You can name the file with or without a path.
  

paxton

Bingo!

Got SRP_Run_Command to run 7x.exe using oengineserver by putting 7z.exe and 7-zip in the Oinsight folder.

Got to thinking that the registry settings for oengineserver included a working directory setting. Although the folder with 7z.exe in in the PATH (Which I thought would be enough), oengineserver with SPR_Run_Cpmmand must only look in the registry's setting working directory.

I retried using the working directory parameter in SPR_Run_Command, and it works fine. I thought I had tried that, and I am sure Don suggested that, but maybe I was thinking the PATH would work.
Anyhow, now works and exactly as advertised...my bad.

Thanks you,
Paxton

DonBakke

Nice!

paxton

Greetings!
FYI
A further note on my findings.
To review, using 3 systems:
DEV is Win7 with no oengineserver
TEST production is Win 10 with Oengineserver
LIVE Production is WHS 2011 with Oengineserver

SRP_Run_Command works on the DEV system without the workingDirectory parameter set, with the .exe in the PATH
SRP_Run_Command works on the TEST system with the workingDirectory parameter set to the location of the .exe (which is NOT the Oinsight folder)
SRP_Run_Command does not work on the LIVE system with the workingDirectory parameter set to the location of the .exe (which is NOT the Oinsight folder)
SRP_Run_Command works on the LIVE system without the workingDirectory parameter set and the location of the .exe in the Oinsight folder

Do not understand why there is a difference between the Win10 and the WHS2011 systems, but there is.
PATH, folders .exe locations are identical on all systems.
Bottom line everything works every time when the SRP_Run_Command is calling a .exe in the Oinsight folder.