Applies to version: 2023 R3 and above; author: Łukasz Maciaszkiewicz
Introduction
With the WEBCON BPS mobile application, users gain the ability to access the WEBCON BPS platform from anywhere using their mobile devices. This article delves into the core assumptions regarding the architecture of the mobile application mentioned above.
Assumptions
The fundamental architectural assumptions for the WEBCON BPS mobile application:
The application designed for mobile devices equipped with a given operating system can be downloaded from the app store dedicated to a particular operating system.
Hybrid application
The WEBCON BPS mobile application is a hybrid application. This means that some functionalities are available within the native mobile application, whereas other ones can be accessed through WebView, i.e. a browser window embedded in the application that displays websites. What is important, as the WEBCON BPS Portal view is embedded in WebView, most functionalities available in the mobile application are supported in a manner similar to how they are supported in regular desktop browsers.
It is important to mention that authentication is a special case in this scenario. This is the only functionality associated with the mobile application which requires access to an internet browser.
Below are the functionalities listed based on how they are supported:
Mobile application architecture diagram
The diagram below presents relationships between mobile application and individual WEBCON BPS platform components.
Authentication
Authentication in the mobile application is facilitated by access mechanism and refresh tokens.
The WEBCON BPS Portal view presented in an internet browser is used for logging into the mobile application. A user can log in after selecting one of the available directory service provides (Active Directory, Entra, OpenID). The available providers are configured in Designer Studio.
After selecting a provider, the user is redirected to the login page to enter valid credentials. Once this information is entered, the user returns to WEBCON BPS Portal, providing generated access token to the mobile application.
The access token is utilized in all REST API invocation methods. After moving to the WEBCON BPS main page (the token is added to the request header):
Mobile application
The WEBCON BPS mobile application works online only. This means that all data displayed to the user and entered by them is constantly exchanged with the connected installed WEBCON BPS system instance.
The native part of the application is responsible for the communication. It invokes REST API that facilitates connection with the installed WEBCON BPS instance. The data is transmitted in the JSON format and this applies both to data retrieved from the WEBCON BPS instance and responses from the mobile application.
REST API for mobile application
The communication between the mobile application and the installed WEBCON BPS instance occurs through the embedded WEBCON BPS Portal and by invoking the REST API.
Since most communication is facilitated by the Portal, the WebView service embedded in the mobile application needs access to the same HTML websites and REST API services that are available in Portal displayed in an internet browser. Additionally, the mobile application utilizes the REST API interface to deliver the following functionalities:
Configuration in WEBCON BPS Designer Studio
The WEBCON BPS mobile application requires configuration of the following elements in Designer Studio:
- The settings of the compact form are by default inherited from the configuration of the main form. However, it is possible to break the inheritance and configure the compact form independently.
- You can control the behavior of the compact form through form rules. By default, the configuration of such rules is inherited from the settings of the main form, but, similar to the first case, it is also possible to break the settings inheritance;
This setting is common for all WEBCON BPS applications and processes. It requires the user to enter the PIN code whenever they open the mobile application, regardless of the security level selected by the user. (Alternatively, it is also possible to use biometric protection, e.g. checking fingerprints or face geometry). When the user enters an incorrect login, they are required to enter the PIN code defined in the mobile application configuration.