Action Development Guide
ADDITIONAL INFORMATION
We've now covered the major development tasks involved in writing an Action and making it work in a deployment environment. There are a few additional tasks that developers typically do to wrap the Action up as a nice package, which is what we'll cover in this section.
Action Metadata
The plugin.properties file contains properties related to the current release of the Action, many of which are set based
on prompts at the time the plug-in is created. But you can edit this file to update some of these values as needed, but note that you should
not edit some of them. Here are the properties:
- plugindesc
- This specifies a description of the plug-in; edit this to describe what the primary purpose of the Action is. This information is presented in the documentation.
- uuid
- The unique ID for this plug-in (autogenerated, DO NOT EDIT). When you create a new version of one of your Actions, if for some reason you decide to "start fresh" and create a brand new Action but want the new one to replace the old when imported into Sentinel, then you can copy the UUID from the old Action to the new one.
- entitlement
- This is used internally at NetIQ only.
- integrators
- This property defines a list of the Integrators that this Action can be used with. At this time it is used primarily for documentation.
- requiredobjects
- This defines the list of objects that the Action must receive at its input in order to function correctly. Possible values include EVENT, CORRELATED_EVENT, INCIDENT, and NONE; multiple objects can be separated with a '+'. NONE means the Action can be used anywhere; the other values constrain where the Action will be presented for use in the UI. This is usually set during Action creation.
- useforrouting
- This property specifies whether the Action can be used for routing of event data; that it can be attached to one of the Event Routing Rules in Sentinel Log Manager or Sentinel 7. Such Actions will typically do as little processing as possible and will likely work on batches of events at a time (see below) for efficiency.
- usebatch
- This property specifies whether the Action can handle batches of events at a time; if so, when the Action fetches events from its input it will get them in a batch. If used for routing, the routing framework will batch up a set of events before triggering the Action.
Action Documentation
Each Action plug-in also includes a document template that you can use to document details about your Action, how to set up and
configure the Action, provide output samples, that sort of thing. The template resides in the doc subdirectory within the Action and
can be edited with the free LibreOffice word processor. Note that the documentation template that you see only includes the sections that we expect
Action developers to edit; that material is then merged with some boilerplate sections to generate a couple output PDF documents, one of which is embedded
directly in the Action plug-in and one of which is external.
The documentation template and the expected documentation should be pretty self-explanatory once you open the document. There are some special features, however, which are common to all SDK documentation and are described here. After reviewing that material, note that Actions in particular have some additional special replacement variables, including:
- @INTEGS@
- This variable will be replaced by the list of Integrators that this Action will work with.
- @USEBATCH@
- This variable will be replaced by a true/false value which informs whether the Action can handle batches of multiple events at a time.
Action Versioning
Actions are versioned using a hybrid scheme that describes not only the version of that particular Action but also the version of the SDK against which the Action is built.
A 2011.1r4 Action, for example, represents the fourth version of a particular Action built against the 2011.1 SDK template.
Each time you release a new version of an Action that you maintain, you should increment its release number to indicate to consumers that it is a new Action, that they
should replace their old ones. Doing so is very simple: just edit the release.properties file in the Action directory and set the number to the new version. In fact,
a production build currently prompts you to increment this automatically; it assumes that if you are doing a final production build then maybe the next build should be
a new version.
FIN
This is the end of our Action Development Guide, we hope you've found it useful. Thanks!
- Back up to Develop to Sentinel