The AR System data dictionary

The AR System data dictionary is composed of tables that contain the structural definitions of all the forms, filters, escalations, active links, character menus, and containers that are entered into the system (see the following diagrams).

Together, these tables contain the complete definition of the structures and workflow in your implementation of AR System. As you add or alter structures in your system, appropriate updates are made to these tables to reflect the changes.

AR System Data Dictionary: Forms, Fields, VUIs, and Sample Forms

1-1-DataDictionary-FormsEtc-updated.png

 AR System Data Dictionary: Active Links, Filters, and Escalations

1-2-DataDictionary-ActiveLinksEtc-updated.png

 AR System Data Dictionary: Container
DataDictionary-Container.gif

The initial table of the BMC Helix Innovation Suite data dictionary

The first table is named control, and it contains one row. The columns contain information about the version of the database, dbVersion, and a set of numbers identifying the next available ID for the various structure items that can be created.

The process table in the BMC Helix Innovation Suite data dictionary

Process tables are used to store the process definitions and internal elements such as process variables, sequence elements, and timer events. The primary key used for identification for this table is processid. The following set of tables holds the information associated with the process form definition:

  • process_element
  • process_element_call
  • process_element_errorevent
  • process_element_receive
  • process_element_sequence
  • process_element_servicetask
  • process_element_timerevent
  • process_element_usertask
  • process_multi_instance
  • process_permissions
  • process_variable
  • process_variable_enum_value
  • process_variable_ref_mapping

The view table in the BMC Helix Innovation Suite data dictionary

The view table stores metadata about the BMC Helix Innovation Studio views. The primary key for identifying the view table is viewmetadataid.

It helps identify the bundle to which the definition belongs. The following set of tables holds the information associated with the views form definition:

  • view_permissions
  • viewcomponent
  • viewcomponent_permissions

The identification key bundlescope is a common column for most of the metadata tables.

The document table in the BMC Helix Innovation Suite data dictionary

The document table with the schema name ardocument stores the document definitions in the database. 

The schema table in the BMC Helix Innovation Suite data dictionary

A set of tables is used to define the form known as schema in the database tables. The arschema table contains information about the form definitions. The four main fields in the arschema table are:

  • schemaId—The unique internal ID for the form (which does not change, regardless of changes to the form).
  • name—The administrator name for the form.
  • schemaType—The type of form (regular, join, view, or vendor).
  • nextId—The next available ID for a new entry for that form.

The following set of tables holds information associated with the form definition:

  • schema_group_ids—Defines which groups have access to the form.
  • subadmin_group—Defines which groups have subadministrator access potential for this form.
  • schema_list_fields—Defines which fields are returned in response to the ARGetListEntry and ARGetListEntryWithFields API calls.
  • schema_vendor—Defines how the form is attached to an ARDBC data source.
  • schema_view—Defines how the form is attached to a database table.
  • schema_join—Defines how the form is joined, if applicable.
  • schema_index—Defines the indexes for the form.
  • schema_sort—Defines the default sort order for the form.
  • schema_archive—Defines the archive information for the form.

Every form contains at least one view user interface (VUI) that represents the various layouts and fields that hold the data for the form. The vui table contains information about each VUI in each form. Every VUI is identified by the combination of the schemaId that connects the VUI to a form, and the vuiId that identifies that VUI within the form.

The field table in the BMC Helix Innovation Suite data dictionary

The field table contains all the information (except for the display information) about each field in each form. Every field is identified by the combination of the schemaId that connects the field to a form and the fieldId that identifies the field within the form. 

The vuiId and fieldId are unique within the form, so a single ID identifies either a VUI or a field. The field_dispprop table contains information used to define how the field is displayed in the form. The objProp column in the field_dispprop table holds a list of fields whose display properties have changed in the view overlay form. The field_permissions table contains information about the permissions of various groups to the individual fields. The following series of additional tables holds information that is specific to each data type: field_int, field_real, field_char, field_diary, field_dec, field_curr, field_date, field_enum, field_attach, field_table, field_column, field_view, field_display, and field_enum_values (there is no additional data for timestamp, trim, or control fields).

If a field is located in a join form, there is an additional entry in the join_mapping table. This entry contains the definition of how this field is connected to the field in the base forms that make up the join form.

If a field is located in a view form, there is an additional entry in the view_mapping table. This entry contains the definition of how this field is connected to the field in the base forms that make up the view form.

If a field is located in a vendor form, there is an additional entry in the vendor_mapping table. This entry contains the definition of how this field is connected to the field in the base forms that make up the vendor form.

The menu table in the BMC Helix Innovation Suite  data dictionary

The char_menu table contains an entry for each menu, and tags each with a charMenuId. A set of tables associated with the char_menu table (linked by charMenuId ) provides the details about the various types of character menus:

  • char_menu_list
  • char_menu_query
  • char_menu_file
  • char_menu_sql
  • char_menu_dd

The image table in the AR System BMC Helix Innovation Suite data dictionary

The image table contains an entry for each image object stored in BMC Remedy AR System.

All images used in form views and fields were stored ("embedded") in the display properties of the views and fields as a byte string using the ARByteList data type. If the same image was used in multiple views or fields, a separate copy of the image was embedded in each view and field.

The images can be stored in the image table as shared objects in binary format. This enables multiple views and fields to share a single image object simply by storing a reference to the image object in their display properties. The reference uses the charVal data type.

The image table includes unique indexes on the following fields:

  • imageID—AR System assigns a unique image ID to each stored image.
  • name—You assign a unique name to an image object when you create it.

For backward compatibility with pre-7.5.00 AR System clients, the AR System server converts the charVal reference to a data string before transferring it to the client.

Two XML ENUM data types for exporting images (AR_STRUCT_ITEM_IMAGE and AR_STRUCT_ITEM_XML_IMAGE ) and an export format (image ) are added. For more information about image objects, see Adding-icons-and-images-to-Progressive-Web-Applications.

The filter table in the BMC Helix Innovation Suite data dictionary

The filter table contains an entry for each filter, and tags each with a filterId. Tables associated with the filter table (linked by filterId ) provide the details about the various actions defined for each filter:

  • filter_call
  • filter_notify_ids
  • filter_exit
  • filter_process
  • filter_goto
  • filter_push
  • filter_gotoaction
  • filter_serviceaction
  • filter_log
  • filter_set
  • filter_message
  • filter_sql
  • filter_notify

The escalation table in the BMC Helix Innovation Suite data dictionary

The escalation table contains an entry for each escalation, and tags each with an escalationId. Because escalations and filters are so tightly linked, the information about actions for escalations is stored in the same tables as the filter actions. The escalationId and the filterId are unique within the table, so a single ID identifies either a filter or an escalation.

The active link table in the BMC Helix Innovation Suite data dictionary

The actlink table contains an entry for each active link, and tags each with an actlinkId. Tables associated with the actlink table (linked by actlinkId ) provide the details about the various actions that are defined for each active link:

The support_file table stores report definitions. Finally, the table actlink_group_ids contains the list of groups that can execute the active link.

The workflow mapping tables in the BMC Helix Innovation Suite data dictionary

A set of mapping tables associates each filter, escalation, or active link with all its forms, allowing administrators to create shared workflow. The filter_mapping table contains the filterId and schemaId for each entry, creating a link between each filter and form. The escal_mapping table associates escalations with forms by storing the escalationId and schemaId for each entry. In a similar way, the actlink_mapping table associates active links with forms by storing the actlinkId and schemaId for each entry.

The container table in the BMC Helix Innovation Suite data dictionary

The arcontainer table contains an entry for each container, and tags each with a containerId. Containers are used to define guides, applications, packing lists, workspaces, and web services. The three main fields in the table are:

  • containerId—The unique internal ID for the container.
  • name—The administrator name for the container.
  • containerType—The type of container.

The following set of tables holds information associated with the container definition:

  • arctr_group_ids—Defines which groups have access to the container.
  • arctr_subadmin—Defines which groups have subadministrator access to the container for containers that are not owned.
  • arreference—Defines the references for each container.
  • arref_group_ids—Defines group access permissions for external references.
  • cntnr_ownr_obj—Lists the owners for the container.

A list of references defines the components that belong to each container. For example, a container might reference forms, workflow objects, and other internal and external objects that make up an application or guide. Each container can have zero, one, or multiple references. Each reference is identified by the containerId of the container to which it belongs, and by the referenceId that identifies the object itself.

All references are described by reference type, data type, reference order number, label, and description. Internal references store the referenceObjId. External references store a short value or long value that describes the external reference. The arref_group_ids table can have zero, one, or multiple group entries that define group access permissions for each external reference. Each entry describes a groupId permitted to access an external reference.

For more information about using containers to create guides and about the data structures used to define containers, see Containers-and-structures.

The overlay and custom object columns in the BMC Helix Innovation Suite data dictionary

The following columns are added to the actlink, arcontainer, arschema, char_menu, escalation, field, filter, image, and vui tables in the AR System database to support the overlays and custom objects:

  • overlayProp(int)—Holds a bitmask value that specifies the overlay state of an object. The values are:
    • 0 (unmodified)
    • 1 (overlaid)
    • 2 (overlay)
    • 4 (custom)
      By default, this column is blank, which is the same as 0 (unmodified). When an overlay is created, the create overlay operation sets this column to 1 in the overlaid object and to 2 in the overlay object.
  • overlayGroup(nvarchar(254))—Identifies the overlay group to which an object belongs. The values are:
    • 0 (does not belong to an overlay group)
    • 1 (belongs to the overlay group)
      An object can belong to only one overlay group.
      All overlay and custom objects have 1 in this column. Unmodified and overlaid objects always have 0 in this column.
  • resolvedName (nvarchar(254))—Holds the name of the overlaid object.
  • overlayExtended(int) - Defines whether an object is extended. The values are:
    • 0 (not extended)

    • 1(extended)

      When you use the get function of the AR System driver utility for an object, it displays the overlayProp and overlayGroup values for all objects, except the unmodified ones.

      The following table shows the values for the overlay* columns by object customization type:
      Database overlay column values by object customization type

      Object type

      Database overlay column values

      overlayProp

      overlayGroup

      Unmodified origin

      0

      0

      Overlaid

      1

      0

      Overlay

      2

      1

      Custom

      4

      1

      In addition to the preceding columns, the following columns were added to the arschema and vui tables:

      • resolvedSchemaId int (arschema)
      • objProp nvarchar(254) (vui)


      For each overlay, an entry is added to the baseline object table. Nonetheless, field and form overlays are not treated as individual objects in the database. Instead, they are treated as subsets of the overlaid object properties because they share data with the overlaid object. All other types of overlays are treated as individual objects, although they remain dependent on their overlaid objects and are tightly coupled with them.

For more information about overlay and custom objects, see Customizing-applications-using-overlays-and-custom-objects.

The association table in the BMC Helix Innovation Suite data dictionary

The association table contains an entry for each association, and tags each with a associationId. Tables associated with the association table (linked by associationId ) provide the details about the various actions defined for each association:

  • association_indirect
  • association_pkfk_mapping

For more information about associations, see Associations-overview.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*