Cross-module communication

Modules that provide contributions such as links, data, or views are called contributors. Contributions are provided by the modules during the registration process with Web Portal. Refer to the section about the registration for more information.

On the other side, modules that request contributions from Web Portal at runtime, in order to navigate the user to a specific view or embed a view from another module, are called consumers. All use cases from the consumer side are implemented via the UI API.

As the modules are part of one system and are connected to the same Master Data Management module, chances are high that some modules process the same common entities, such as devices. Context linking allows users to jump from one module to another module that provides additional information related to the current context. For example, when a user is working with a specific device in one module, they might want to jump to another module that can provide more information about that device.

When a consumer requests to display links for a context, Web Portal renders a context menu with all registered links for that context. The user can select from the list and will be navigated to the respective view including parameters (deep-linking). Context linking is designed to be extensible by the contributors. When a module registers a link for a given context, it will automatically show up in the context menu without requiring any code changes in the consumer module.

The context refers to the data point or entity displayed and selected by the user in the UI. For example, in the above example, the context would be 'device'. Web Portal doesn’t limit the semantics of contexts, but it is advised to document the available contexts and the required information (parameters) for them to work.

To show the context menu in a module UI, the showContextMenu() function of the UI API is used. The requestBrowseToLink() function can be used to link to a specific linked contribution.

Modules can provide contributions of type LINK via the Module Registry API.

The following code snippet shows an example for a LINK contribution.

The data contribution function of Web Portal is useful when there is a need to transfer small amounts of data between modules in the UI. Due to security restrictions, especially the single audience and CORS policies, modules cannot fetch data from another module’s API without prior configuration on the contributor side. With the data contribution concept, contributors can provide data in the front-end that can be used by other modules without altering the security mechanisms in the back-end.

Similar to context linking, modules can provide contributions for a certain context, and consumer modules can retrieve this data in their UI using the getDataForContextContribution() function of the UI API.

Due to the aforementioned security restrictions, contributor modules need to implement a small HTML page that fetches the respective data from their API and pushes it to Web Portal using the getDataForContextContributionResponseFromIframe() function of the UI API. Web Portal opens this HTML page in an iframe when a consuming module wants to fetch the data.

Modules can provide contributions of type DATA via the Module Registry API. For a good user experience as a contributor, also refer to the how-to on UI performance.

The following code snippet shows an example for a DATA contribution.

Embedded views are used to integrate UI parts of another module in order to provide additional information or perform actions in the current context without leaving the current module.

For example, in the "Shiftbook" module, users can create downtimes and want to see the related tasks stored in the "Maintenance Management" module. Instead of navigating to the "Maintenance Management" module and searching for the correct tasks, "Shiftbook" embeds the maintenance task overview directly in its downtime detail view. Users can immediately track all tasks created for this downtime or even create new ones.

Like other contribution types, embedded views are based on a context. This allows contributors to add views without requiring any code changes in the consumer module. For example, each embedded view contribution could be put in a new tab in a tab control, allowing the user to switch between different information relevant to the current context. However, this depends on the use case implemented by the consumer.

Consumers can embed views using the embedView() function of the UI API. The functions informHostView(), sendEventToEmbeddedView(), and listenToEmbeddedView() enable communication between the embedded view and its host. It is recommended to specify this communication contract publicly so that the embedded view can be used by other modules in the same way.

Modules can provide contributions of type EMBEDDED_VIEW via the Module Registry API. For a good user experience as a contributor, also refer to the how-to on UI performance.

The following code snippet shows an example for a EMBEDDED_VIEW contribution.

Dialog views allow modules to display UI parts of another module in a separate dialog without navigating away from the current context. In contrast to embedded views and as the name implies, dialog views are opened in a separate dialog and not inside the consumer’s UI. When requested by the consumer, Web Portal opens the dialog and embeds the dialog view in a separate iframe. Dialog views are useful when the consumer’s view does not have space for another UI or when displaying forms.

Consumers can open dialogs using the showViewInDialog() function of the UI API. Both the contributor (dialog) and the consumer (host) can close the dialog using closeDialog(). Only one dialog can be opened at a time.

Modules can provide contributions of type DIALOG_VIEW via the Module Registry API. For a good user experience as a contributor, also refer to the how-to on UI performance.

The following code snippet shows an example for a DIALOG_VIEW contribution.