Definition files for displaying user-specific event attributes
You can extend the functions for linking JP1/IM to other applications by customizing JP1/IM definition files.
- Organization of this page
Customizing JP1/IM definition files
Extending functions enables you to do the following:
-
Display user-specific event attributes
-
Display the monitor window from JP1 events displayed in JP1/IM - View
-
Add new menus to the Tool Launcher window
- Note:
-
If you use UTF-8 as the encoding to save a customized definition file, save the file without attaching a BOM (byte order mark).
For details about the functions, see 4.14 Displaying user-defined event attributes in the JP1/Integrated Management 2 - Manager Overview and System Design Guide.
Overview of definition files
In a definition file, blocks that specify definitions are related to each other. Moreover, the definition files are related to each other. The following figure shows these relationships.
Naming rules for definition files
The following shows the naming rules for definition files.
Definition file |
Naming rule |
---|---|
Definition file for extended event attributes |
company-name_product-name_attr_en.conf |
Definition file for object types |
company-name_product-name_obj.en |
Definition file for executing applications |
company-name_product-name_app.conf |
Definition file for opening monitor windows |
company-name_product-name_mon.conf |
Definition file for the Tool Launcher window |
company-name_product-name_tree.conf |
Note that product-name may also be specified as series-name_product-name. We recommend that for JP1 event issuance you use as the file name the value specified in PRODUCT_NAME, with the forward slash (/) replaced by the underscore (_). Because hitachi is used as the default file name, use a name other than hitachi for company-name.
Storage locations for definition files
The following shows the storage location for each definition file.
Definition file |
Storage location |
---|---|
Definition file for extended event attributes |
Machine where JP1/IM - Manager is installed |
Definition file for opening monitor windows |
Machine where JP1/IM - Manager is installed |
Definition file for object types |
Machine where JP1/IM - Manager is installed |
Definition file for executing applications |
Machine where JP1/IM - View is installed |
Definition file for the Tool Launcher window |
Machine where JP1/IM - View is installed |
Structures of definition files
This section provides information that is common to the JP1/IM definition files that can be customized in order to link with the Event Console window and Tool Launcher window.
The information provided in this section is applicable to the following three definition files:
-
Definition file for extended event attributes
-
Definition file for executing applications
-
Definition file for the Tool Launcher window
The definition file for object types and the definition file for opening monitor windows have different structures.
Components of definition files
The principal components of a definition file are the statement, blocks, and comments. A definition file begins with the statement that represents the attributes of the entire file (definition information header), followed by blocks that describe the details of the definition and any comments.
The following describes these components of a definition file.
Statement
- Structure of a statement
-
A statement consists of multiple components that form a single meaning. A statement always begins at the beginning of a line and ends with a semicolon (;), followed by a linefeed code.
- Types of statements
-
Statements are classified as in-file statements and in-block statements.
- In-file statements
-
An in-file statement indicates attributes of the definition file. There are two types of in-file statements: statements for the definition information header, and statements for block control. Each statement in a file is prefixed with @.
- In-block statements
-
An in-block statement indicates attributes of a block. All statements that can be specified between the start-of-block statement (@define-block) and the end-of-block statement (@define-block-end) are in-block statements, except for comments. The in-block statements that can be specified depend on the block.
In-block statements are not prefixed (i.e., there is no @).
Block
- Structure of a block
-
A block consists of a set of statements. The set of statements includes a statement that declares the start of the block (@define-block), statements within the block that describe the actual definitions, comments, and a statement that declares the end of the block (@define-block-end).
Nested blocks are not allowed in a definition file.
- Block type
-
A block's type is specified in the type= parameter of the start-of-block statement (@define-block). For details about the types of blocks, see @define-block statement.
- Block priority
-
A block contains a key item that must be unique within the definition. If the definition contains multiple key items, one of the blocks is selected according to a priority ranking. The block priorities are as follows:
-
Block in the last file when file names are sorted in ascending order
-
Last block specified in the file
In other words, when definition files are linked into a single file in ascending order of the file names, the last block in the linked file has priority.
-
Comment
A comment is a line beginning with a hash mark (#) or a line consisting of only spaces, tabs, or a linefeed code. Comments do not contain definition information.
A comment is processed as a single statement. Because comments are evaluated by line, there is no need to delineate comments with a semicolon (;). If a comment ends with a semicolon (;), the semicolon is treated as part of the comment.
Rules for generating common Statements
The two types of in-file statements are statements for the definition information header and statements for block control.
The following table lists and describes the in-file statements.
Statement name |
Description |
Type |
---|---|---|
@file |
Declares the definition version. |
For the definition information header |
@product |
Declares program product information in the definition. |
For the definition information header |
@define-block |
Declares the beginning of a block. |
For block control |
@define-block-end |
Declares the end of a block. |
For block control |
In these statements, a statement for the definition information header defines attributes that are common to the entire definition file. The available statements for the definition information header depend on the definition file. The parameters for the statements for the definition information header also depend on the definition file.
A statement for block control is used to declare a block unit that is defined in the definition file. The rules for generating statements for block control are common to all definition files. These rules are described below.
For the rules for generating statements for the definition information header, see the descriptions of the individual definition files.
- @define-block statement
-
- Syntax
-
@define-block type="block-type";
- Function
-
Declares the beginning of a block. Statements from this statement to the @define-block-end statement are treated as a single definition block.
- Parameter
-
type="block-type"
Specifies the type of definition block. The following lists the block types that can be specified.
Table 2‒5: List of block types Block name
Value in the parameter
Event attribute definition block
"event-attr-def"
Event attribute group definition block
"event-attr-group-def"
Event display sequence definition block
"event-attr-order-def"
Application execution definition block
"application-execution-def"
Menu tree definition block
"function-tree-def"
If an invalid block type is specified, the entire block is ignored and a warning is displayed, but file analysis processing continues.
- Note:
-
Nested definition blocks are not allowed.
- Example definition
-
See the description of the @define-block-end statement.
- @define-block-endstatement
-
- Syntax
-
@define-block-end;
- Function
-
Declares the end of a definition block that begins with @define-block.
- Note:
-
If there is no corresponding @define-block statement, file analysis processing is canceled.
- Example definition
-
This example includes @define-block and @define-block-end statements:
@define-block type="event-attr-def"; block lang="English", platform="base", extended="false"; attr name="E.SEVERITY", title="Severity"; attr name="B.TIME", title="Registered time"; attr name="B.SOURCESERVER", title="Registration host"; attr name="E.USER_NAME", title="User name"; @define-block-end;