4.3 Inspectable

Owned by Jenni Wallin
Last updated: May 12, 2023 by Former user (Deleted)

The DRAgentInspectable class is used both by the Workflow Editor and by the workflow engine to obtain information about the agent and its configuration status.

Inspectable classes must extend DRAgentInspectable. The Workflow Editor queries the code server for such instances in order to determine which agents are available.

Inspectable

Agent Details

To obtain the user interface configuration panel, the agent name and its representing icon, the Workflow Template uses the methods:

  • getUIClassName
  • getConfigClassName
  • getCommandUIClassName
  • getName
  • getIconName

The workflow engine uses the getExecClassName method to obtain the executable class.

The class names and icon name must contain the full package name.

If the agent publishes any MIM resources, these will be returned by the getMIMEntries method. If so, the Workflow Template will publish them for use by other agents.

If the agent supports update of configurations, the method supportsUpdate must be implemented and return true.

Incoming and Outgoing Data Types

The Workflow Template automatically compares and validates output types from one agent with the input types on a target agent by querying the methods getInputTypes and getOutputTypes. For some agents these types may be static, while for others they depend on the configuration. Since different output types may be distributed on different outgoing routes, the name of each outgoing route is sent along as a parameter.

Collection agents never have any input types. If a processing agent has no output types, it is classified as a forwarding agent in the Workflow Template.

Validation

A user interface dialog validates according to the validation rules specified in the configuration contract. However, some items referred to, such as route names, might have changed since the dialog was confirmed. The Inspectable class also has methods for validation. The purpose of the validate method, is to catch things that may have changed after the dialog was confirmed. For a workflow configuration with multiple workflows, each workflow might need to be validated against the template, then the validateFields method is used.

If the agent has any configuration data, the validate and validateFields methods are called every time a workflow is saved and every time the Validate... option is selected from the Edit menu of the Workflow Template.

A workflow configuration is considered valid if it contains at least one valid workflow and at least one input agent, if all the agents are properly connected, if all the agents have a valid configuration, if there are no data type compatibility problems between connections and if all the agents return null from their validate and validateFields methods.

Note!

The Workflow Template handles validation of the incoming and outgoing data type compatibility, meaning this does not have to be done using the validate or validateFields methods.

The default implementation of the validate method calls:

  • getExpectedMIMNamedEntries
  • getExpectedRouteNames
  • getExpectedExecutionContextName
  • getInputTypes
  • getOutputTypes

and checks that the expected MIMs and routes really exist, and that input and output types match the workflow configuration.

If used in standalone workflows, agents that depend on storage can override the getExpectedExecutionContextName method to return the location where their storage is configured. This allows the validate method to ensure that the location of the storage matches the scheduling of the workflow, thus preserving the workflow's standalone integrity.

Best Practices

Help the user to configure your agent:

  • Try to make faulty configurations impossible in the GUI.
  • Display information about problems as soon as possible.

When designing your agent:

  • Using the right GUI components, such as check boxes with valid options instead of a text box input, makes it impossible to enter invalid input.
  • If the validateInput callback in the UI returns a string that is not null, this text will be displayed as a validation error to the user. If your checks are correct, return the value from the superclass' validateInput method.
  • The configuration will be validated against the configuration contract's validation rules for each field.
  • The validationErrorFound callback allows you to configure the GUI to display invalid fields directly to the user, which is useful if multiple tabs or other complex GUI elements have been included.
  • The validate callback in the Inspectable class is intended for checking agent external dependencies, such as availability of MIMs published by other agents, or that selected profiles exist. Ensure that the superclass' validation method is used.
  • The validateFields callback is given an actual workflow, i e the merge of the workflow configuration with values from the workflow table. This callback can be used to validate field values against each other. For example if you have a min and max range, the validateFields callback can be used for checking that max value is larger than or equal to the min value.

Tooltip

When the mouse pointer rests on a agent, the Workflow Template displays a tooltip text, aiming to contain a subset of the most important configuration values and, optionally, the current transaction data of the agent. The latter is only necessary if it is useful to the user.

The involved method is getConfigTooltip. This must be implemented either in the Inspectable class, or be defined in the configuration contract file. Otherwise the tooltip displays Not Configured in the tooltip, although it may be configured. The Java class generated from the contract file will also contain a getConfigTooltip method. Both methods return an array list containing string pairs as label, value, label, value, etc.