Record definition concepts
This topic provides information about the concepts related to a record definition and a record field, and types of record definitions.
Record definition concepts
The following table lists the concepts in a record definition:
| Term | Description | Example |
|---|---|---|
| Record or record definition | A record definition is a collection of the data required for building the application for your business process. A record definition is made up of specific record fields. | A task can be stored as a record definition. |
| Record field | A unit of information that collectively forms a record definition. A single record definition consists of multiple fields, and each field has one or multiple attributes. | The task record definition can consist of the following fields:
|
| Record instance | The data created by the application for which the structure of the data is specified by the record definition. | The task fields can consist of the following record instances:
|
| Index | In a record definition, an index is a list of record fields that are frequently searched. Indexes reduce the database search time and optimize the performance of your Digital Service application by returning search results faster. | A record definition for a task can consist of the following index entries:
|
| Customization | As is the case with most kinds of Definitions, a developer can control whether the record definition is customizable after it is deployed to a production environment. This is controlled at the level of the entire record definition, or if desired, for individual fields. Also the developer can permit only permissions to be customized but nothing else. | The developer only allows Status and Description to be customized. Permissions can be customized for all fields. |
| Permissions | Access to the record definition itself, or individual fields, can be restricted to a list of Roles (these are created in the Administration tab of BMC Helix Innovation Studio). There is also a special group called Public that be assigned if the field is open to anyone. Administrators map these Roles into actual Groups of real users after deployment. | The developer restricts access to a Salary field to users whose group is mapped to the HR role. |
| Security Labels | This is another kind of permission control, but works on individual record instances so they are dynamically assigned at runtime. The Security Label implies a relationship with one or more Groups or Roles. Only users who have that relationship will be able to view or modify the record instances. Specifying the Security Label in the record definition is not enough to give access. Rules must be created to set or remove the labels from specific record instances at runtime. | There is a Cost field. It is given a Security Label called AccountingSensitive. At runtime, this Security Label is applied only if this particular record meets guidelines that make it significant to the Accounting Department. At runtime, only such records are visible to members of the Accounting Department. |
| Inherit from a Record Definition | If desired, the record definition can automatically inherit all the fields from another record definition. You can then choose whether to also inherit core fields, Rule bindings, Field Permissions, and Associations. | Request inherits from Ticket. All the fields from Ticket are implicitly there as part of Request. If a new field is later added to Ticket, it automatically shows up as part of Request. |
| Share Data with Inheritors | If selected, this option means that any other record definitions that inherit from this one will store their data in the same database table as this one. This means that a query for these Records will return the inheriting records also (though not their particular fields, just the common ones). If this is not set, then the fields are inherited but the data is stored in a separate database table and there is no way to query them together. | Location is set to "share data with inheritors". Site, inherits from Location but adds the field SiteID. Therefore if you query Location you will see all the Locations including all the Sites, but you will not see any site-specific data such as SiteID. |
| Abstract | This means that the record definition only exists for purposes of inheritance. Actual record instances should never be created. | Ticket is an abstraction to define the shared fields of Incident, Problem, and Change. We don't want actual Ticket record instances created so we make it Abstract. |
| Final | This means that new record definitions cannot inherit from this one. | The extended business logic requires that there be no further extension of the Change record definition, so we lock out further inheritance here. |
| Exporting Data | This means that when a developer exports the bundle definitions in order to create a Deployment Package, all record instances of this definition are exported along with it. When it is deployed to a production environment, the records are imported and replicated for all tenants currently existing on the production environment. Typically this is NOT used for operational data, such as Incidents or Tasks. It is generally used for data which is used for configuration purposes, such as data used for Named Lists. | We create a record definition to store the names of processes to be invoked from a Named List. Since we ship these processes with the application, we should specify that the data be included with the Deployment Package as well. |
| Allowing Users to Delete | Typically, only administrators should actually delete data. This setting enforces this globally for all records of this definition. | There is some frequently generated data that users can completely clean up if they choose to, so we set this option to be True. |
Record field concepts
| Term | Description |
|---|---|
| Type | Fields come in different types, and some of the properties of the types vary. For example, number fields have a min and max value. Character fields can have a Named List assigned to them, and can be encrypted. Selection fields have a list of enumerated values. The Record designer UI indicates which properties are appropriate for each type. |
| Customization | If the record definition itself is customizable (see above), then the developer can further specify which fields are. Also the developer can permit only permissions to be customized but nothing else. |
Types of record definitions
A record definition can be of two types: regular record and join record.
Regular record
A regular record is a record definition that is not a combination of multiple record definitions.
Join record
A join record definition is a combination of data that is retrieved from multiple record definitions. Join record definitions are similar to database joins.
With join records, you can perform the following operations:
- Retrieve data from multiple record definitions.
- Specify the criteria for retrieving data from multiple record definitions.
- View or edit record fields of multiple record definitions at the same time.
Join records are further divided into inner join records and outer join records.
Inner join record
This type of join record combines only the matching data from multiple record definitions. An inner join searches for fields that have corresponding values in the multiple records and then combines the matching data to form a join record. If a field does not have a corresponding value in any of the records, that field is omitted from the join record.
Example of an inner join:
The following image illustrates the concept of an inner join. In the example, the Library Catalog form is the primary record, and the Customer Checkout form is the secondary record. The join criteria is the International Standard Book Number (ISBN).
An inner join creates a record that contains only the entries in which the join criteria exists in both the primary and secondary records. The join record produces a report that shows only the titles that are checked out.
Outer join record
This type of join record combines all the fields from a record definition that is marked as primary, even if the fields do not have a corresponding value in a record definition that is marked as secondary. To see all submitted help requests, including those that have no specific employee information connected with them, you can create an outer join.
Example of an outer join:
The following image illustrates the concept of an outer join. In the example, the Library Catalog form is the primary record, and the Customer Checkout form is the secondary record. The join criteria is the International Standard Book Number (ISBN).
An outer join creates a record that includes a comprehensive listing of all the catalog items from the primary record even if there is no corresponding data in the secondary record.
External record
An external record definition is a record definition that binds the external data (AR System forms) such that the external data appears in the BMC Helix Platform as a local record instance. The external record definitions can be used as regular record definitions, so that the objects such as View Components, Process, Rule, Named List can be bound to them just like regular Record Definitions.
Comments
Log in or register to comment.