Question: Running a .EXE program from a BPM?


10.2.200 here… We have an E9 BPM that ran an external program, and I’m uplifting it to E10. However, I’m getting errors on trying to use Process.StartInfo and the Process.Start method. I’ve added a reference to System.Diagnostics in the References section of the BPM, but still getting errors. Anyone else have these issues in doing the same thing? Ideas to fix the problem? ANy help would be greatly appreciated!

What errors?

Also consider that calling an EXE from BPM will run on the server, not the client.

Like 500000 flags raised on me reading this… I’m gonna reserve judgement but running an EXE on a BPM strikes me a horrible idea… for many many reasons.
Can we get some context?

Below is the uplifted C# code and the original ABL:
string CmdArgs = String.Empty;

Process ProcExE = new Process();
ProcessStartInfo proc = new ProcessStartInfo();
proc.CreateWindow = false;
proc.UseShellExecute = false;
proc.FileName = “E:\Epicor\EpicorData\Utility\BPMRcvLbl.exe”;
proc.WindowStyle = ProcessWindowStyle.Hidden;

foreach (var ttRcvHead_iterator in (from ttRcvHead_Row in ttRcvHead
where ttRcvHead_Row.RowMod != " "
select ttRcvHead_Row))
var ttRcvHeadRow = ttRcvHead_iterator;

proc.Arguments = ttRcvHeadRow.PONum.ToString() + " " + ttRcvHeadRow.PackSlip.ToString();
ProcExE = Process.Start(proc);


define variable CmdStr as Character.

for each ttRcvHead no-lock
where ttRcvHead.RowMod <> ’ ':

assign CmdStr = 'E:\Epicor\EpicorData\Utility\BPMRcvLbl.exe ' + string(ttRcvHead.PONum) + " " + ttRcvHead.PackSlip.

/* {lib/PublishInfoMsg.i &InfoMsg = CmdStr &InfoSeverity = {&MESSAGE_INFO}} */

OS-COMMAND Value(CmdStr).

The two errors I’m getting relate to referencing the System.Diagnostics class:
CS0246: The type or namespace name ‘Process’ could not be found (are you missing a using directive or an assembly reference?)

CS0246: The type or namespace name ‘ProcessStartInfo’ could not be found (are you missing a using directive or an assembly reference?)

I wonder if they put some security in place to keep people from doing this…

You could try to call out the full names:


Also, you are placing the usings in the usings tab right? And I wonder if this did work, if this code should be marked as Asynchornous

Are you sure this wouldnt be better suited if you moved the logic from the EXE directly into the BPM? The problems I forsee, are many:
You are calling the EXE every row and waiting
You have no chance for error handling
Is that exe modifying any info in epicor?
What if exe hangs? It’s gonna lock your BPMs
It appears to print labels, Epicor has some tools for that

1 Like

The program we’re trying to run was written in-house to select and print the type and quantity of labels the user needs when receiving shipments. We pass the PO and packslip and it’s recorded in a file for later selection and printing of labels.

I know that companies in general arent keen on reinventing the wheel, but in this case, I wonder if a better solution all the way around would be to use a UD table to store that data right in Epicor. The only changes would be in the other exe that select/prints, it would just query e10 for that data. You could use rest or other methods to access Epicor, or in a quick pinch just query the epicor db in SQL.

At any rate, I am not trying to change your mind. Do you know if you are adding the using statments in the usings window?

Also did you try full qualified names: System.Diagnostics.Process

Afterthought - if you are just writing a flat file, why not do that in the BPM?

I did add System.Diagnostics to the Usings tab, and just tried using the full name. Getting different errors about properties on ProcessStartInfo, however I’ll take everyone’s advice and look at other methods of recording the info. Thanks to everyone!

1 Like

That is what we have done… using a UD table for all labels generated…


1 Like

Not that I’m encouraging calling an .exe in a BPM,

but should you be including something like this after your code:


That’s how I tested calling an exe from a button (after searching on here)