Create a data workbench

  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 matching the naming conventions for configuration objects.
    • 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: If data workbench configured report groups have been defined for the data workbench, open the editor and select the relevant data workbench configured report groups. You can also define the order of data workbench configured report groups in the drop-down menu for opening them. Click here for information about creating data workbench configured report groups.
    • 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 under 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.