Please give details of the problem



Web Interfaces

A web interface is a user front end of an application. It is designed in a device-independent way. DigitalSuite provides for the appropriate processing and rendering so that users can interact with the application from desktop, tablet, or mobile devices.

A web interface may define a web page to launch a process and/or web pages for end users to carry out manual tasks specified as process activities. In DigitalSuite, a web page of a web interface is called a screen. A web interface can contain as many screens as required.

Instances of web interfaces and their screens are created and opened when users start the application or access manual tasks in their personalized environment in web browsers or RunMyApp.

The design and configuration of a web interface comprises the following settings and items, which are described in detail in the sections below:

Web Interface Identification

The following settings identify a web interface in DigitalSuite:

  • Name: The name of the web interface. It is used as the title when the web interface is launched.
  • ID: A generated number used to uniquely identify the web interface.
  • Description: A short description of the web interface and its purpose.

By default, each screen of a web interface has the interface's name as its title. However, it is possible to define dynamic names to give each screen its own specific title. Dynamic names can be composed of static text and variables, for example, Order for ${client_name}. The title is determined at runtime for each screen that is launched. Any variable available in the web interface launch screen can be used.


A web interface can have several screens, which are used for different groups of users and steps of a process. For example, an employee may use the first screen to submit a request which launches a process. A manager uses the second screen to approve or reject the request.

The assignment of web interface screens to process steps is made in the process design. The screen which launches a process is referred to as the launch screen.

Each new screen added to a web interface is a copy of the previous one and includes the same design elements. New design elements, so-called widgets, are added to all screens. While the design of each screen is therefore the same, visibility properties determine which widgets are presented to the users at runtime in different situations and for the different process steps. Managing screens in this way makes it possible to share elements and variables without having to re-create the items multiple times.

The screens of a web interface can be rearranged at any time to reflect the order of the steps in the related process.


A widget is a design element or component of a screen, for example, an input field, button, or image. Developers use widgets to quickly design user interfaces by drag-and-drop.

The widget settings determine on which screens of a web interface a widget is available and visible, and whether user input is possible or required. For example, a field containing JavaScript may be available, but not visible, a text field may be read-only, or selection of a value from a list may be mandatory.

A general setting for all widgets determines the direction in which text is output: left to right or right to left.

For details on the available widgets, refer to Widget Types

Custom Widgets

A custom widget is a reusable web interface. Designers can create such web interfaces with elements that are often used together, for example, a number of input fields to describe a customer. These web interfaces can then be utilized in the same way as standard widgets in other web interfaces.

Web Interface Availability

Access to a web interface can be set to public or private. Public web interfaces can be opened without any authentication while users need to log in successfully to DigitalSuite and have the required permissions to open private web interfaces.

For each web interface, customers can:

  • Decide whether it is available on the individual homepages they have configured for desktop and mobile devices. Only web interfaces of application versions running in the Live execution mode can be made available on the homepages.
  • Set a favicon and thumbnail image for quick identification.
  • Provide tags which can be used for different purposes. For example, the Homepage portal application, which customers can use for their own homepage, retrieves the accessible web interfaces and displays them ordered by their tags.
  • Add a tracker for Google Analytics with a given ID and URL.
  • Allow users with read access by a role with Observer rights to add comments.


DigitalSuite comes with predefined cascading stylesheets (CSS) that can be used to determine the appearance of a web interface. By means of a general option, the designer can determine whether to display the web interface with borders at the left and right or to spread it across the full screen width without borders.

In addition, customers can add their own stylesheets. Their style definitions take preference over the predefined ones with the same name.

JavaScript in Headers and Footers

Customers can add JavaScript files to the header and footer of a web interface:

  • Header: The JavaScript is executed before the web interface is loaded.
  • Footer: The JavaScript is executed after the web interface has been loaded. Therefore, loading is faster as when adding a script to the header.

The files containing the JavaScript to be executed need to be uploaded to DigitalSuite. They can then be referenced by their generated URL.


Web interfaces can make use of one or more collections as their data bases. Collections can store any kind of data, for example, on customers, products, or assets.

A collection can be made available to one or several screens of a web interface, where it can be accessed by means of JavaScript functions.


Web interfaces can be configured with listeners that trigger actions when certain events arise. For example, a listener may retrieve data from an external system based on variable values entered in the web interface. A listener can be configured for all screens of a web interface or a selection thereof.

The actions that can be triggered are:

  • Launch a composite API
  • Launch a process
  • Call a connector

The events that can trigger an action are:

  • Screen Initialized: The action is triggered when the web interface screen is launched.
  • Listened Variable Changed: The action is triggered when the value of a given variable changes.
  • Screen Closed: The action is triggered when the web interface screen is closed, i.e. a user clicks a respective button.
  • Manually via JavaScript: The action is triggered manually by a JavaScript. This is possible only for listeners launching composite APIs or connectors.

Designers need to ensure that all parameters required by the listener are defined appropriately as variables of the calling web interface. All web interface variables are sent to the launched listener.

At various points of listener execution, like upon completion or failure, or for a specific process state, scripts can be executed. These can be used, for example, to fill in the fields of a web interface screen according to the listener's return values.

For optimum results, it is worth considering the execution of listeners:

  • Connectors and composite APIs are executed synchronously, i.e. the web interface waits for their results. Their execution paths are not persisted, which makes them quite efficient.
  • Processes are executed asynchronously. Their execution path is persisted, and their result is polled regularly from the web interface.

Consequently, composite APIs or connectors always yield better performance results than processes.

However, working with process listeners may be useful in specific situations, for example, to work with more than one process from a single web interface. In this case, it may be worth considering to trigger only one "screen initialized" process listener with subprocesses.

Web Interface Engine

A web interface is created based on the current version of the DigitalSuite Web Interface Engine. The Web Interface Engine version used by a web interface is never changed automatically, because this may have side effects, for example, on the rendering.

DigitalSuite provides periodic updates for its Web Interface Engine. While it is possible to use a specific Web Interface Engine version for a long time, customers may want to upgrade to a newer version to take advantage of new features or performance improvements. They can do so explicitly for each individual web interface, after carefully checking the changes and possible side effects.

Alias Web Interfaces

There is a special type of web interface called alias web interface. Alias web interfaces are part of the standard portal applications. The screens and widgets of alias web interfaces cannot be modified.