I am trying to run a batch using System.Diagnostics.Process , but it is not giving any error nor giving the result
I am using PU34
System.Diagnostics.Process myProcess = new System.Diagnostics.Process(); System.Diagnostics.ProcessStartInfo myProcessStartInfo = new System.Diagnostics.ProcessStartInfo("cmd.exe");
myProcessStartInfo.Arguments = '"C:\\Users\\admin144423\\Documents\\batch1.bat"'; myProcessStartInfo.UseShellExecute = false; myProcessStartInfo.RedirectStandardOutput = true; myProcessStartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle::Hidden; myProcessStartInfo.CreateNoWindow = true; myProcess.StartInfo = myProcessStartInfo; myProcess.Start(); myProcess.BeginOutputReadLine();
I tried the batch file from other drives as well giving shared permission, but it doesnot show any error.
On executing this bat file from command prompt, I am getting the result.
Am I missing something?
First of all, the whole idea of accessing a local file looks wrong to me, because you won't be able to put such a file to environments managed by Microsoft. If it can't work in production, do you really spend any time with it? It sounds like you should throw it away and prepare a more meaningful design.
We should be able to help you if you explain the business requirement to us.
I am trying to run a perl script to convert the edi files to csv (This code snippet was already customised in Ax2012).
The perl command is executed with 2 arguments , I tried upgrading the same code in D365 FO, but could not do as System.Diagonostic was givng the error code as non-zero..
I thus tried giving a local path in my code and was trying to check if is giving expected behaviour.
Since EDI conversion using logic apps involves Premium plan and pricing is little high, customer needs similar solution which is being used in Ax2012.
Thus this was my workaround, and did not work.
I see many potential problems. The web server can't reach the file. There is no perl.exe to execute. The web server doesn't have permissions to execute it. The batch file does something wrong. And so on. You would have to collect more information than just that the error code is not zero. But I would still verify that your architecture can work in production at all. If not, solving these problem would give you nothing, therefore it would be a waste of time.
Are you limited to PERL for some reason? The remark about Logic Apps suggests that you aren't, therefore you can think about other alternatives, such as using .NET libraries via .NET Interop, XSLT, Azure Functions, or something.
This is what Perl script does : It reads the EDI file and converts to csv file for importing.
Bat file has following command : perl -perlscipt.pl -input edipath.edi -output -outputfile.csv
I executed the above command as bat and as powershell script, and got the proper result. Only when it is called from System.Diagonistics, it is not working.
As you said, I tried using azure web jobs . I created a simple powershell script and uploaded the script as a new web job and set it it manual.
param([string] $scriptPath,[string] $inputPath,[string] $outputPath)perl $scriptPath -input $inputPath -output $outputPath
Arguements for the webjobs are passed from logic apps like this
I created a on-premises gateway to get access to the azure vm.
On running logic app, I can see the perl script in my vm location is called .
But it is failing with this weird error.
Again, this ps script is getting executed properly on running in ps editor.
Do I need to modify my ps script when called from webjobs ? Webjob set up has only the above script , not as zip file. I am checking if I have missed something .
Please let me know if my approach is correct.
Running it with your your profile and credentials in an interactive session is clearly a completely different thing than trying to execute it inside a web server using a different account and default paths. Please look again at the list of potential problems and add "access to perlscipt.pl and edipath.edi" to the list.
Regarding your Powershell script, shouldn't it be -input $inputPath -output $outputPath instead of -input:$inputPath -output:$outputPath?