Extension Points

As described on the Extending Ignition with Extension Points page, extension points are hooks that allow modules to implement new versions of abstract ideas. Extension points are a sub-type of named resources, and need to be defined and constructed a bit differently. Because the core configuration resource and type meta are owned by the Ignition platform extension point itself, you cannot provide the same level of control as a typical named resource. However, some modules such as OPC UA do define their own extension points.

Instead, you must provide an intermediate class that bridges your custom “settings” config object with the base extension point’s “profile”. Ultimately this will extend the core ExtensionPoint interface, as described in Define Your Extension Point Implementation. By convention, Ignition’s extension points provide an abstract class for you to extend, such as AbstractJournalExtensionPoint or ScheduleExtensionPoint. These abstract extensions are generic on some type that represents your “settings” object. At minimum, your extension point implementation needs to tell the core extension point manager how to construct your object. Typically, this is exposed as one or more abstract create methods, such as createJournal from AbstractJournalExtensionPoint:

protected abstract AlarmJournal createJournal(
  GatewayContext context,
  DecodedResource<ExtensionPointConfig<AlarmJournalConfig, ?>> alarmJournalConfig,
  S journalInfo
);

It is possible to customize further than simply defining a create method. The next few examples demonstrate how to implement additional behavior.

Adding a Reference Property

For this example, the Database Alarm Journal adds a reference property in its constructor using a protected method:

addReferenceProperty(
  "database-connection",
  ref -> ref
    .targetType(DatabaseConnectionResource.RESOURCE_TYPE)
    .value(DatabaseAlarmJournalConfig::datasource)
    .caseSensitive(true)
    .onUpdate(DatabaseAlarmJournalConfig::withNewDatabase)
);

Providing a Default Value for Your Settings Type

You can also provide a default value of your settings type, which will be exposed by the REST API:

@Override
public Optional<DatabaseAlarmJournalConfig> defaultSettings() {
  return Optional.of(DatabaseAlarmJournalConfig.DEFAULT);
}

Opting In Settings Validation

Opt in validation of your settings object by overriding validate:

@Override
protected void validate(@Nullable DatabaseAlarmJournalConfig settings, ValidationErrors.Builder errors) {
  if (settings == null) {
    errors.addMessage("Settings cannot be null");
    return;
  }

  errors.requireNotEmpty(settings.datasource(), "Datasource name cannot be empty");
}

Opting Out New Instance Creation of Your Extension Point

To opt out of allowing new instances of your extension point to be created, see canCreate:

/**
 * @return true if this extension point is eligible for new instances to be created. Returning
 *     false here is a common way to soft-deprecate extension point types.
 */
default boolean canCreate() {
  return true;
}

Adding Custom Frontend Components

Your custom extension point extension will also be an entrypoint for adding custom front-end components to the Gateway Webpage UI:

/**
 * @return the React component to use for adding or editing settings for this extension point.
 */
default Optional<WebUiComponent> getWebUiComponent(ComponentType type) {
  return Optional.empty();
}

/**
 * @return any custom menu actions to add to the data grid's hamburger menu for resources of this
 *     extension point.
 */
default List<MenuAction> getMenuActions() {
  return Collections.emptyList();
}