Report configuration - HxGN SDx - Update 64 - Administration & Configuration

Administration and Configuration of HxGN SDx

Language
English
Product
HxGN SDx
Search by Category
Administration & Configuration
SmartPlant Foundation / SDx Version
10

Reports provide a quick way to view project information, perform complex queries, and view information across a structure of data.

The content and format of each report is customizable using report definitions to create ad hoc reports. These report definitions can be saved to create custom reports that can be reused or edited to create other reports later.

  • View definitions form the basis of reports, providing the definition of the structure to be queried and the data to be displayed.

  • Access groups, owning groups, and security rules provide access control to the reports.

  • Different formatting options control the output of the data. This can be in Word, list views, Excel, or xml format. You can employ style sheets to achieve almost any output required.

  • A number of report templates are delivered with the core model and additional templates can be configured.

Ad hoc reports

Reports can be run on an ad hoc basis where the user has to enter the search criteria each time.

Ad hoc Reports are based on view definitions which are in turn based on graph definitions. The graph definition is a collection of edge definitions that represent a path through the data model.

The view definition sits on top of the graph definition and acts as a filter. Otherwise the user would be overwhelmed with too many details when they requested an ad hoc report. When a user requests a report, the view definition picks the required properties that the user wishes to see from the objects found. (Basically, ad hoc reporting is simply a process of putting user-defined criteria into a graph definition via the view definition at the point of executing the report.)

The following diagram shows default layout for the Method Access View report.

Edit Report Definition form

The report criteria are configured for new or existing reports using the Edit Report Definition form. This form is used to define the report output format by selecting the report template to use, applying any specific report options, and saving the report configuration for future use.

The following image shows the Edit Report Definition window for the Details of Methods report and its options.

In the Edit Report Definition window, you have the following report options:

  • Display latest values only - This option only displays the most recently published values when you run this report on a shared object. The report highlights values that are inconsistent with values published from other tools. If you do not select this option, the report shows the different values as a comma-separated list.

  • Context object required - This option indicates that the report can be run only from a contextual object, such as a method configured on the Actions menu. If you set this option, the report will not appear in the Reports feature set in the Web Client.

  • Include intermediate nodes - This option includes all intermediate nodes in an expansion from the top down. This includes the parent nodes even when any child items are missing or are excluded from the report criteria.

  • Terminated workflows report - This option allows you to run a report that extracts information on terminated workflows for a set of objects. Selecting this option displays the Starting Objects Criteria for Terminated Workflows Reports column in the Report details section of the form. You must select the Related Items for which you want the terminated workflows report and set the criteria accordingly.

    • The underlying graph definition for the Terminated Workflows Report must consider the workflow object as the starting object, as all the workflows related to the selected set of objects (for example, Class Def UID) are considered as starting objects.

    • Select the Run in background option in the Background Adhoc Report section if you want to run the report in the background. For more information, see Configure a report to run as a scheduled task.

  • Ignore Config - This option allows you to run a report that extracts information for one or more selected objects from multiple configurations (plants or projects) and displays the result in a single file.

    • Be aware that when you select this option, the report extracts information from the multiple configurations, irrespective of access permissions.

    • You must select the CSV or CSV Repeated report output style to enable this option.

Ad hoc reports process

The server side of the ad hoc report process is responsible for parsing the report details passed up from the desktop client, placing the specified criteria on the appropriate graph definition edges.

The process dissects the report details passed from the desktop client and overlays them onto the view definition that the report is derived from. This is a way to substitute criteria from the report onto the view definition and subsequently the graph definition.

The server also has the responsibility of packaging the report results up into the output style specified by the user.

Saved reports

Report definitions can be saved with pre-configured criteria and output formats to create custom reports that can be rerun or edited later.

Graphic reports

Graphic reports are similar to ad hoc reports in that they are based on view definitions. However, there are two important differences between graphic reports and ad hoc reports. First, graphic reports are run against a single drawing or model. Second, graphic report results are not displayed in a tabular view. Instead, user-specified symbology is used to indicate the plant items in the drawing or model that satisfy the graphic report's criteria.

  • Reports run with the Include Intermediate Nodes option enabled typically perform better. Where the additional rows in the report output are not wanted, it may be possible in some cases to post-process the output to remove them.

  • When creating a graph definition, consider if an edge definition expansion would be more efficient than a relationship definition expansion. Discrimination criteria added to an edge definition (in the form of an appropriate property comparison or valid end interface) may yield a smaller result set and create more efficient queries that do not query unnecessary database tables.

    If a graph definition is used for a document report, which has an expansion from Files to its attached object, an edge definition expansion is more efficient than a SPFFileComposition relationship expansion. This is because the edge definition expansion only considers documents and automatically excludes other object types, such as technical queries or submittals, and so on. For example:

    <EdgeDef>
      <IObject UID="EDG_TestVersion" Name="TestVersion" />
      <IPositionCriteria />
      <IEdgeDef StartInterfaceName="ISPFBusinessFile" PathDefn="+SPFFileComposition" ValidEndInterfaceDefUIDs="IFDWDocumentVersion" />
      <ISimpleCriteria PropComparisons="" />
      <ISPFEdgeDefExt />
      <IEdgeDef2 />
      <ISchemaObj />
    </EdgeDef>