Create a hierarchical data workbench

Hierarchical data workbenches are currently published in a beta version. The following restrictions apply:

  • Visualization capabilities have not been added yet. Users cannot create reports and you cannot add reports via configured report groups.
  • Multi-edit of objects is not supported.
  • Hierarchical data workbenches show objects related to each other on up to four levels. On each level, objects of only one object class can be displayed. It is not possible to show for example child application groups and applications both as subordinate to an application group.
  1. Go to the Data Workbenches tab in Alfabet Expand.
  2. Right-click the Data Workbenches explorer node and select Create New Data Workbench.
  3. Click the node of the new data workbench and define the attributes:
    • Name: Change the name of the new data workbench to a meaningful name.
    • Caption: Define the caption of the data workbench in the user interface.
    • Class Name: Select the object class for that objects are listed and editable in the data workbench.
    • Data Workbench Configured Report Groups: Leave this attribute empty. The feature is currently not supported for hierarchical data workbenches.
    • Data Workbench Group: You can structure data workbenches in folders. Type the name of a new folder to add the data workbench to a new folder or select the name of an existing folder from the drop-down list.
    • Description: You can enter a description that explains the purpose of the data workbench for other solution designers working with Alfabet Expand. The description is currently not displayed on the user interface.
    • Enable Class Operations: Select True to enable all operations defined for the object class in the data workbench.
    • Max. Records: Do not change this number. The value "0" is the default and indicates that all records shall be displayed in the data workbench. If you define an integer, the number of records fetched from the database for the data workbench will be limited to the defined maximum number of records. Filters set by users will only will only be applied to the visible dataset. Objects excluded because the maximum number of records is exceeded will not be available in the data workbench. If the number of objects for an object class is very high and you encounter performance issues when rendering the data workbench, you should not limit the number of records but define the query for the data workbench to pre-filter available objects and return only a sub-set of the available objects. You can filter the objects for example to show only objects editable by the current user or required to answer a business question.
    • Query Type: Select AQL to define the content of the data workbench with an Alfabet query or SQL to define it with a native SQL query.
    • AQL Query / SQL Query: Define a query that returns the objects which shall be listed and editable in the data workbench. Ensure that the following rules are met:
      • The query must return objects of the object class/object class stereotype defined in the Class Name attribute of the data workbench. In an Alfabet query, the object class must be the FIND class. In a native SQL query, the first argument of the SELECT statement must return the REFSTR value of objects of the object class.
      • WHERE conditions can be used to limit the number of objects.
      • Alfabet parameters can be used in the query to refer to the current environment (for example, the object the user currently works with, the current user or current user profile). The Alfabet parameter @BASE must be used if the data workbench shall be assigned to a class based content area. It must not be used in other data workbenches.
      • Show properties and sort properties defined in an Alfabet query will be ignored and only the first argument in the SELECT statement of a native SQL query will be considered. The properties will be displayed in the data workbench based on the configuration of permissions that are defined on the level of the object class properties. All permissible object class property values, indicators, and roles for an object will be displayed in a data workbench by default and the user can sort and filter the columns of the data workbench at runtime. xxx

        For performance reasons, the SELECT statement of native SQL queries must not be defined to return all data for the FIND class. Instead, it should be defined to only return the REFSTR of the objects found.

      • Click here for use case related requirements that may apply and example queries for use cases.
    • Right-click the data workbench node in the explorer and select Add Hierarchical Sub-Element.
    • Select the new element in the explorer and define the attributes in the given order:
      • Type of Relational Connection: Select FromUpToDown if the object class property storing the relation belongs to the object class on the upper level. Select FromDownToUp if the object class property storing the relation belongs to the object class on this level.
      • Class / Stereotype Name: Select the object class or object class stereotype which shall be displayed on this level of the hierarchical data workbench.
      • Property: Select the object class property establishing the relation between the objects on the two levels.
      • Visualize: For intermediate levels in a hierarchical data workbench, you can change the setting to False if you want to hide this level from the data workbench. For example if you want to show applications and persons having a role for the application, you will have three levels for the object classes Application , Role , and Person. You can hide the role to show the user data of all contact persons directly under the application data.
    • Repeat the last two steps for each further level of the data workbench. You can define three sub-ordinate levels for a data workbench.