Components

Companies

UDEP by design is multi-tenant. The deployment of UDEP could be public cloud (AWS, Azure, Google etc) or Private Cloud, Bare Metal servers within your data centre or Virtual Machines in your landscape. Irrespective of the deployment, the UDEP deployed is the same secure, multi-tenant architecture.

Companies in UDEP are a logical grouping of an organization. For e.g. in the public cloud, each customer will be a Company or domain in UDEP. Companies could also mean subsidiaries or departments as required.

Companies own the set of users, applications, systems, frontends, data etc. Companies can be Partner Companies (for e.g. in a public multi-tenant cloud run by Unvired and managed by an Unvired partner), Customer Companies (for e.g. in a public, shared multi-tenant cloud) or Departments / Group Companies / Subsidiaries (for e.g. in a private dedicated cloud).

The company that is created during installation “owns” the UDEP landscape and is referred to as ROOT company. The other types are PARTNER (typically an Unvired partner managing the infrastructure) or CUSTOMER (could be end customer or department or group company). Companies can only be created by the Super Admin or SA user of the Root company.

Plans

Every company needs to have an activated plan. A plan decides how many applications, backend systems, frontends or devices, users (admin/device/developer) are allowed to be created.

Note: Data limits are planned and currently not available. Standard plans are preconfigured such as Trial, Unlimited etc. and can be used or custom plans can be created. A plan has to be assigned to a company and then activated so that the company can deploy applications and provision users.

Backend Systems

Systems

Backend Systems or Logical Systems are the list of systems that the Unvired Process Agents will be communicating with. Backend systems include SAP, Salesforce, Oracle, Web Servers (REST/SOAP), Databases and other generic functional systems. Each backend system is created as a Logical System in the UDEP landscape. This allows the process agents to refer to these systems using their logical name and not the physical properties like IP address or hostname. This abstraction ensures that even if systems are replaced or migrated, only their properties need to be changed and all applications will continue to work unaffected. Backend system properties provide all the details that enable UDEP to connect to these systems.

For any functionality or process that UDEP needs to enable, a Backend system needs to be created. For example to access ABAP function modules an SAP ABAP system needs to be created, to access a REST service a Web Server needs to be created.

Technically Backend System properties consist of the type of System, IP address etc. Systems that support additional authentication mechanisms such as OAuth are also to be maintained here,

Ports

Backend Systems are made up of “Ports”. Ports are synonymous with network ports and provide all the information for UDEP to determine how to connect to a Backend System. While Backend Systems detail which system to connect to (for example SAP ERP), Ports detail how to connect to these systems (for example RFC, Web Services etc).

Technically Backend Port properties consist of the type of Port, network port number etc.

Functions

Backend Functions are associated with a Backend Port. Web and Mobile Applications and other systems can invoke these functions that are defined in UDEP. The functions are a logical abstraction and act as the “glue” between the application in the browser or device and the backend system. For e.g. CREATE_USER can be a function to create a user in a particular backend port/system that it is attached to.

Technically Backend Functions detail out all the function properties such as the logical name of the function, the Java class or the ABAP BAPI name etc. Functions can be of type Application or System. System is reserved for use by the UDEP platform and customers should add and use only Application type of functions.

Frontends

Frontends (Device Types and Connectors)

Frontends are the list of device connectors that that the Unvired Process Agents can accept calls from and will be able to push messages to. Frontends know how to push messages to the mobile devices / applications. Frontends include Android Phones and Tablets, iPhone & iPad, Windows Tablet, Browser and other external servers (machine to machine communication for integration scenarios).

Similar to backend systems, Frontends are a logical abstraction of the different device types that UDEP can accept calls from and natively push data. Process Agents only need to indicate that the message is for a particular user(s) and UDEP ensures that the message is pushed to the user’s mobile / web application in near real time.

UDEP supports true push all devices. For iOS devices Apple Push Notification Service or APNS is supported, Android devices are reached via the Google Firebase Messaging Service (FCM), Windows tablets are supported via the Windows Notification Service and Browsers are supported via asynchronous push notifications that are browser independent.

Note: Push notifications are usually not guaranteed to be delivered to the device by the underlying provider. Applications should therefore not make any assumptions regarding push message delivery and in high latency or poor networks build alternate mechanisms for delivery of data.

Users

Users

The user management in UDEP is handled via the Users module. Unvired Users are more commonly referred to as Unvired IDs and can be of multiple roles / types.

Role	Notes
SUPER ADMIN	Only one Super Admin is available for each company with User ID “SA”. The “SA” user is created during the post installation phase for a root company and also when a child company is created. The “SA” user has wide ranging access rights on the system (you can think of “SA” as similar to “root” on Linux Systems or a Domain Admin in Windows Systems) and the password needs to be complex and secured safely. The “SA” user also has access to sensitive operations such as viewing of Message Data on production systems. . Store the “SA” password in a safe manner and do not share with others.
ADMIN	Admin users will be able to perform most operations in the UAC except for certain sensitive operations. Normal day to day administration needs to be performed by Admin users. Create an Admin user for each administrator as this helps audit the system later (administrator user actions are captured in the system Audit Log). Create Admin users for your L2 support team.
SUPPORT_ADMIN	Support Admin users have access to restricted functionality. They can manage users but cannot configure any systems or other configurations. Create Support Admin users typically for your L1 support team.
APPLICATION	Application users are the users who will be using the applications on their respective devices and/or browsers. See the section on User Management to get more details on Application Users (also referred to as Unvired ID) and their administration.
DEVELOPER	Developer users have the same rights as Admin users and in addition can debug the process agents directly on the server. Developer User Authentication tokens are used for debugging process agents from the Unvired Eclipse Developer Plugin. More on this is explained in the Unvired Developer documentation.