Victor, thank you for your quick reply and willingness to improve the NXSL flexibility.
At the moment if the logic is straight forward - this can be done with multiple lines in the Event Processing Policy, different scripts which return 1 or 0 (execute/not execute) and different action on each line.
Or one action which calls a script in the OS shell and there nxget and nxpush to be used as communication with the variables (DCI).
At the moment the alternative is to do actions which are calling the shell command nxpush, but if this can be done direct from the script - it will be much easier.
Quote from: Victor Kirhenshtein on March 18, 2010, 10:23:36 AMThe differences are that the External Parameter can be attached to a DCI (collected on a period), but not to the event processing policy. If trying to create management workflow in NXSL - it is needed on some events to execute action, which result to trigger a second event and action on the local server. On the Linux servers this can be done with 2 nested nxpush executions (the result from the first nxpush is being pushed back to the local server from the second nxpush), but on the Windows servers this become complicated, because of the restrictions of the Win cmd shell.Quote from: borislavl on March 17, 2010, 09:07:06 PMHow this is different from DCI with external parameter as a source?
3. Actions to be able to return a value(response from the command) to a specified DCI.
Quote from: Victor Kirhenshtein on March 18, 2010, 10:23:36 AMI understand your concerns here, I was looking for such functionality in the scripts library, so when one action with parameter %[script] is executed - to be possible to execute another action before it and pass the result to the main action. Or based on the logic in the script to execute one or more actions.Quote from: borislavl on March 17, 2010, 09:07:06 PMI'm not sure that this is needed in DCI transformation and event filtering scripts. Main concern here is performance - for example, if event filtering script calls external action and waits for it's completion, it potentially could block event processing for significant amount of time.
4. Or to call action from NXSL and receive/not receive value as response
At the moment if the logic is straight forward - this can be done with multiple lines in the Event Processing Policy, different scripts which return 1 or 0 (execute/not execute) and different action on each line.
Or one action which calls a script in the OS shell and there nxget and nxpush to be used as communication with the variables (DCI).
Quote from: Victor Kirhenshtein on March 18, 2010, 10:23:36 AMThis would be great. Even in "push" DCIs - it will be useful.Quote from: borislavl on March 17, 2010, 09:07:06 PMCould be implemented, but probably for "push" DCIs only (I mean allow to set value only for push DCIs).
5. From NXSL to be possible to set DCI values (activating their Thresholds as configured)
At the moment the alternative is to do actions which are calling the shell command nxpush, but if this can be done direct from the script - it will be much easier.