The dashboard interface
In order for a definition defined by another backend module to be discovered by mod-service-interaction, first that module will need to implement the dashboard interface.
That involves an entry in the ModuleDescriptor for that module of the shape:
{ "id": "dashboard", "interfaceType": "multiple", "version": "1.0", "handlers": [ { "methods": [ "GET" ], "pathPattern": "/dashboard/definitions", "permissionsRequired": [] } ] }
When mod-service-interaction is queried for widgetDefinitions via the endpoint /servint/widgets/definitions/global
, it will make a call through Okapi to fetch all of the widgetDefinitions provided by any apps implementing this interface.
The expected shape from the endpoint /dashboard/definitions
is either a single JSON object or an array of JSON objects. Should the provided definitions be invalid, error messages will be logged to mod-service-interaction (See what went wrong). Mod-service interaction will then collate these definitions, and resolve them to a list of the latest valid Definition for each major version of each Definition name.
Each new WidgetDefinition must have a name unique to the module implementing it. Should mod-foo and mod-bar both expose definitions named "baz", then whichever of these modules is called second by Okapi will have all Definitions named "baz" rejected. Underneath is a table of existing WidgetDefinition names, and which module is implementing them. This should be appended to whenever a new WidgetDefinition is created by a module.
WidgetDefinition Name | Implementing Module | WidgetType |
---|---|---|
ERM Agreements | mod-agreements | SimpleSearch |
ERM Licenses | mod-licenses | SimpleSearch |