menu:build:relations:relation_edit
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | |||
menu:build:relations:relation_edit [2022/04/29 11:11] – yspeerte | menu:build:relations:relation_edit [2024/07/03 12:31] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | {{indexmenu_n> | ||
+ | |||
+ | ====== Relations ====== | ||
+ | |||
+ | Relations can be used in templates and command jobs, and they enable you to extract information from the database. An extensive set of built-in relations are provided with the NetYCE installation, | ||
+ | |||
+ | Relations are primarily used within Templates but can be used with great effect in Scenarios and Stored jobs too. Access to relations is NOT restricted by Client-type as are the Templates. | ||
+ | |||
+ | Relations are in essence MySQL queries that allows the builder to create temporary datasets based on NetYCE database | ||
+ | tables and conditions. These datasets are generated on the fly during Template execution where their data can be used as variables. | ||
+ | |||
+ | The **Relations** form allows you to create, import, export, modify and delete your own Relations. The built-in Relations cannot be modified (unless you are a System level user) but adaptations are possible using a ' | ||
+ | |||
+ | The [[menu: | ||
+ | |||
+ | How the relations are used within templates is described on the [[guides: | ||
+ | |||
+ | {{menu: | ||
+ | |||
+ | |||
+ | ===== Import/ | ||
+ | |||
+ | Since Templates, Scenarios and Stored jobs will have dependencies on your Relations, the option to export and import created relations to other NetYCE (production) systems is as relevant as exporting templates. | ||
+ | |||
+ | Click an existing relation and then press the {{general: | ||
+ | |||
+ | To import a relation, Click on the {{general: | ||
+ | |||
+ | {{ menu: | ||
+ | |||
+ | If the relation already exists, NetYCE will warn the user, and the '' | ||
+ | |||
+ | |||
+ | ===== Dependencies ===== | ||
+ | |||
+ | Relations can be used used in Templates, Scenarios and Stored jobs. To prevent deleting a Relation that is in use in any of these applications, | ||
+ | |||
+ | The results of the dependency check is a detailed report on which templates, scenarios and jobs include a reference to the Relation and on which line number. The line with the reference is incorporated. | ||
+ | |||
+ | {{ menu: | ||
+ | |||
+ | Depending on user permission level, the dependencies that prevent deletion can be overridden. If permitted, the dependencies report concluded with the message "Do you want to delete anyway?" | ||
+ | |||
+ | The permissions are defined in the YCE.Auth_permissions table and can be changed using the ' | ||
+ | |||
+ | As NetYCE uses some pre-defined Relations that have system dependencies, | ||
+ | |||
+ | |||
+ | ===== Variables ===== | ||
+ | |||
+ | Variables within the Relations' | ||
+ | |||
+ | <code sql> | ||
+ | SELECT Port_map.* | ||
+ | FROM Port_map | ||
+ | WHERE Port_map.Hostname = '< | ||
+ | ORDER BY Slot_id, Port_name | ||
+ | </ | ||
+ | |||
+ | Any variable known at the moment of execution can be used within the Relation. This includes all of the variables of the node, service, site, client, domain, region, etc that make up the normal ' | ||
+ | |||
+ | This is especially useful in command jobs, where variables can be set as parameters. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Transformed columns ===== | ||
+ | |||
+ | When creating a named context (relation) the SQL definition of the relation can be modified to automatically create additional columns based on the values found in the SQL results. | ||
+ | |||
+ | This extension of columns is the result of transforming a field value from a selected column into a column name. The value(s) in that column then points to another selected value from the record. In that way, a result table in which every line describes a parameter, can be changed to a table in which this parameter-name becomes a field-name. That field name then receives one of the field values that belong to that parameter. | ||
+ | |||
+ | To extend the existing context to a Transformed context, a '' | ||
+ | |||
+ | Also see the [[guides: | ||
+ | |||
+ | |||
+ | ===== Coded relation functions ===== | ||
+ | |||
+ | Some relations are using a subroutine, which is written in code to perform more complicated actions. These are usually created for specific cases per customer request. The format is like this: | ||
+ | |||
+ | < | ||
+ | name_of_subroutine(< | ||
+ | </ | ||
+ | |||
+ | These subroutines can be added as a plug-in into ''/ | ||
+ | Examples are '' | ||
+ | |||
+ | These subroutine calls replace the " | ||
+ | |||
+ | The custom reports cannot use the subroutines defined in context_functions.pl. | ||