This component will be unavailable if file system access has been disabled in the system settings.
This component executes a native operating system command on which the application is running. This can be any command, but the typical use case would be to execute a shell script.
The component has these parameters:
Execute path
The first one is the full path to the executable file on the native file system.
Additional arguments
The second attribute is optional extra command line arguments (multiple arguments can be written, separated by a space character). You can also set this to be an XPath expression (if you click the T-icon on the right) to set a dynamic value. If you want to include one long string with predefined lengths and positions, then you can consider to include trailing blanks for each fixed length variable, that you concat together. You need to include the parameters in double quotes (" ") in order to ensure, that spaces are not interpretated as a parameter separator.
Here is an expression, which sets a fixed length for multiple variable and concatenates them together - while adding a preceding and trailing double quote:
concat('"',
substring(concat($interform.input.spooled.user, ' '), 1, 10),
substring(concat($interform.input.spooled.JobName, ' '), 1, 10),
substring(concat($interform.input.spooled.user, ' '), 1, 10),
substring(concat($interform.input.spooled.splf, ' '), 1, 10),
substring(concat($interform.input.spooled.splfNbr, ' '), 1, 10),
substring(concat($interform.input.spooled.formtype, ' '), 1, 10)
, '"')
So in short you should include the value for this parameter in double quotes like so:
"Hello world"
as spaces outside double quotes will be interpreted as a separator of parameters.
Disable default arguments
It is highly recommended to activate this in order to disable default arguments.
The value of the info parameter as described below can contain the name and value of all workflow variables, but you can disable this by activating this option. It is highly recommended to enable it.
When the O/S command is executed and this default arguments are included, the following command line arguments are passed to the native executable (in this order):
1. Parameter, Program
The name and path of the program.
2. Parameter, PDF file
The name and path of the PDF file, that was just created (if any was created).
3. Parameter, Info
Depending on the parameter, Disable default arguments (described above) this parameter my contain an XML file with all workflow variables, that have been defined, followed by the value of the variable. This XML structure can get so large, that it cannot be contained in a single parameter, so the recommendation is to activate the 'disable default arguments' parameter to exclude this XML structure.
4. Parameter, Additional
The value of the extra optional variable setup on the workflow component, Execute native OS command.
1.The path and filename of the last file that was written to the filesystem from the workflow (technically the value of workflow variable "interform.plugin.archiver.folderName" and "interform.plugin.archiver.fileName" ). If these workflow variables are not set, then this argument will not be included.
2.An XML document containing all current workflow variables (same format as in InterFormNG).
3.The optional extra arguments set on the workflow component and are extra command line arguments (multiple arguments can be written, separated by a space character).
Treat error as warning
As default an exit value other than 0 will result in an error, the same will also happen if something is written in the stderror.
If the checkbox "Treat error as a warning" is checked, then the exit value and stderror will be written as a warning and allowing the workflow to proceed afterwards
The current workflow body will be passed to the native executable as stdin.
After this component has been executed, the workflow body will be the stdout output from the native executable (treated as CSV data type in the workflow).
You can e.g. convert the csv file (that contains the returned data from the script/program) into XML and then query this file in order to determine, if the script/program processed without any error.
Here is an example of how you can do that:
This workflow first creates a PDF file and then calls a bat file via the Excecute native O/S command component. This component overwrites the payload (the input file for the Create PDF file) with a CSV file. In the example above this CSV file is converted into an XML file and this XML file is written to an output file.
Here is an example of what XML file this workflow can create:
This is the output from this bat file:
10-4 file was transfered OK
PROGRAM: %0%
PDFFILE: %1%
INFO: %2%
Demo sources can be found in the members, FROMNG2,FROMNG2_73 and FROMNG2C in the source file APISRC inside the IFORMNG2 library. You should not use this source for production, but you can use this as a base for your first test program(s). You should never place any user exit programs in the IFORMNG2 library, as that will cause a problem after an upgrade of InterFormNG2.
The program will be executed in a job called, QJVAEXEC in the IFORMNG2 subsystem, so if any errors should occur during processing of this program, then this job will stop with a message waiting (MSGW). However if the parameter list of your program does not match the expected number, then the QJVAEXEC job will just stop without a MSGW and even without indicating an error.
Here is an example of how a program can be called on the IBM i. In this example we have a workflow, that monitors an output queue, and we want to call a program on the IBM i to send a message to the user profile, that generated the spooled file.
The workflow is setup like this:
Monitoring an output queue:
Only action is this:
This calls the program, SNDMSG2USR i the library, KSE. The source, that is used looks like below:
/*********************************************************************/ /* Example source for a program, that can be called from InterFormNG2*/ /* */ /* The program can be called from InterFormNG2 via the workflow */ /* component, Execute native O/S Command. */ /* */ /* This program is setup to match a call from this component with a */ /* single parameter, which is the user profile on the IBM i. */ /* */ /* The default arguments should be disabled. */ /* */ /* The input parameter is determined with null (hex 00), so the */ /* length of the user profile is determined via a search. */ /* */ /* For illustration the program sends a message to the user. */ /* */ /* The use case is a workflow, that is triggered by a spooled file */ /* found on a monitored output queue, and we want to send a message */ /* to this user. */ /*********************************************************************/ PGM (&PARMS) DCL &PARMS *CHAR 3840 DCL &USRPRF *CHAR 10 DCL VAR(&LENGTH) TYPE(*DEC) LEN(5) VALUE(10) DCL VAR(&LASTPOS) TYPE(*DEC) LEN(5 0) VALUE(10) DCL VAR(&NULL) TYPE(*CHAR) LEN(1) VALUE(X'00')
CHGVAR VAR(&USRPRF) VALUE(&PARMS)
/* FIND THE LAST NON-NULL POSITION */ CHGVAR VAR(&LASTPOS) VALUE(%SCAN(&NULL &USRPRF)) CHGVAR VAR(&LASTPOS) VALUE(&LASTPOS - 1)
IF COND(&LASTPOS *LE 0) THEN(CHGVAR + VAR(&LASTPOS) VALUE(10))
/* TRIM TRAILING NULLS */ CHGVAR VAR(&USRPRF) VALUE(%SST(&USRPRF 1 &LASTPOS))
SNDUSRMSG MSG('Your spooled file has arrived in + InterFormNG2') TOUSR(&USRPRF)
ENDPGM |
On the Windows platform you can call a bat file via this option. On the windows platform you need to state the full path including the name of the bat file in this workflow element:
You need to specify the full path like below:
An example of how a bat file can be called is included in the section, Call bat file from the workflow.
It is even possible to run Windows Powershell from a .bat file like so:
powershell.exe -Command "& {THECOMMAND}"
If there are any double quotes (") in the command, then they should be written as a single quote (').
Example:
powershell.exe -Command "& {Get-Service | Where-Object {$_.status -eq 'stopped'}}"