AppSuite:Mobile API Facade

Mobile API Facade

General Information

The Mobile API Facade is a server component that brings the new native mobile mail apps together with the OX App Suite. We’ve built the façade based on the technology used and proven in the OX App Suite middleware. The facade is developed in Java, utilizing the OSGI Framework.

The Facade provides offline friendly HTTP interface by doing the work, the connections through the HTTP API, to the OX App Suite and providing only the data the offline capable clients need. In some cases multiple requests to the OX App Suite are combined into one for its clients.The facade also offers a method to tell the clients that information on the server haven’t changed since the last time the client asked for it. This reduces the amount of data to transmit to the clients under certain circumstances, especially important in mobile networks were bandwidth (and overall traffic) is limited. Thanks to facade some functionality can be shared among all clients and need only get implemented once. One example for this is the teaser text extraction, and HTML mail handling in general.The facade also provides a pluggable authentication system. In the default case, login request are just forwarded to the middleware. In more advanced use-cases, the login request is forwarded to IDM of the customer and an OX session is created from the access token from the IDM. For clients this is pretty straightforward.

License information

Used 3rd party licenses

In addition to the 3rd party software used by AppSuite, the Mobile API Facade uses to following libraries:

• Project Lombok (The MIT License
• Semver4J (The MIT License)

Requirements

The Mobile API Facade has to be installed alongside an OX App Suite installation. It requires at least OX App Suite v7.10.3.

Version Matrix

OX App Suite Core Version	Mobile API Facade Version	Version-Stream
v7.10.5	v1.12.x	stable-1.12
v7.10.6	v1.14.x	stable

Mobile API Facade API

Further information about the Mobile API Facade API can be found at: https://documentation.open-xchange.com/components/facade/1.12/

OX Mail Server-side Installation and Configuration

This chapter describes how the backend components of OX Mail are installed and configured on the server.

Available packages

Mobile API Facade is available with the following backend packages:

• open-xchange-mobile-api-facade

Installation on the server varies depending on the underlying distribution, details are available in the following chapters.

Redhat Enterprise Linux 7 or CentOS 7

Add the following repositories to your Open-Xchange yum configuration:

 [open-xchange-mobile-api-facade]
name=Open-Xchange-mobile-api-facade
baseurl=https://software.open-xchange.com/products/mobile-api-facade/stable/mobile-api-facade/RHEL7/
gpgkey=https://software.open-xchange.com/oxbuildkey.pub
enabled=1
gpgcheck=1
metadata_expire=0m

$ yum install open-xchange-mobile-api-facade

Debian GNU/Linux 9.0

Add the following repositories to your Open-Xchange apt configuration:

deb https://software.open-xchange.com/products/mobile-api-facade/stable/mobile-api-facade/DebianStretch /

$ apt-get update
$ apt-get install open-xchange-mobile-api-facade

Debian GNU/Linux 10.0

Add the following repositories to your Open-Xchange apt configuration:

deb https://software.open-xchange.com/products/mobile-api-facade/stable/mobile-api-facade/DebianBuster /

$ apt-get update
$ apt-get install open-xchange-mobile-api-facade

Debian GNU/Linux 11.0

Add the following repositories to your Open-Xchange apt configuration:

deb https://software.open-xchange.com/products/mobile-api-facade/stable/mobile-api-facade/DebianBullseye /

$ apt-get update
$ apt-get install open-xchange-mobile-api-facade

Configuration Mobile API Facade

Introduction

To be able to use the native mail apps the Mobile API Facade needs to be installed in front of the OX App Suite middleware. This document describes how to configure the Mobile API Facade.

The Mobile API Facade stores its configuration in the files /opt/open-xchange/mobile-api-facade/etc/facade.properties (the global configuration) and in /opt/open-xchange/mobile-api-facade/etc/mobile-api-facade-config.yml (hostname specific configuration). Both files support the same configuration properties as can be seen on https://documentation.open-xchange.com/components/mobile-api-facade/config/1.8/.

Connection to the OX App Suite Middleware

After installation of the facade package ("open-xchange-mobile-api-facade") the property com.openexchange.mobile.api.facade.MiddlewareBaseUrl needs to get set to the correct URL. This property needs to be explicitly configured by the administrator. It has no default value. Its possible to connect the Mobile API Facade directly to a middleware process, but this is highly discouraged. The Mobile API Facade should always connect to a middleware process through a load balancer.

An example:

com.openexchange.mobile.api.facade.MiddlewareBaseUrl=https://appsuite.example.com/appsuite/api

After this configuration the open-xchange-mobile-api-facade needs to get restarted.

Proxy configuration

<Proxy balancer://oxcluster_facade>
        Order Allow,Deny
        Allow from all
        BalancerMember http://appsuite-middleware1.example.com:8007 timeout=100 smax=0 ttl=60 retry=60 loadfactor=50 keepalive=On route=FOX1
        BalancerMember http://appsuite-middleware2.example.com:8007 timeout=100 smax=0 ttl=60 retry=60 loadfactor=50 keepalive=On route=FOX2

        ProxySet stickysession=JSESSIONID|jsessionidscolonpathdelim=On
        SetEnv proxy-initial-not-pooled
        SetEnv proxy-sendchunked
</Proxy>

ProxyPass /services/api-facade balancer://oxcluster_facade/services/api-facade

Traffic compression

The clients need to exchange a lot of data with the facade to accomplish the task of a mail client. This traffic can be compressed. Clients add the header "Accept-Encoding: gzip,deflate" by default. For this to work the Apache web server in front of the facade needs to handle this as the facade itself is not returning compressed response bodies.

For Apache HTTPD {mod_deflate} needs to be enabled and the following line needs to be added to your virtual host:

AddOutputFilterByType DEFLATE text/html text/plain text/javascript application/javascript text/css 
text/xml application/xml text/x-js application/x-javascript application/json

Starting/Stopping the Facade Service

The facade runs as its own service independent of the normal OX App Suite middleware. For this on Debian-based system it can be started with

service open-xchange-mobile-api-facade start

It can be stopped with

service open-xchange-mobile-api-facade stop

Re-reading configuration from disk

All configuration properties which are marked as reloadable can be configured without restarting the Mobile API Facade by using the reloadconfiguration utility. As the Mobile API Facade runs in its own process you need to tell reloadconfiguration to connect it instead of the Middleware. This can be done by:

reloadconfiguration -p 1100

Ports

As the Mobile API Facade is its own process it also has its own JMX port and its own RMI port. The default JMX port is 9995 and the default RMI port is 1100. These ports needs to be explicitly specified to the command line tools using either JMX or RMI.

Configuration of Mobile API Facade behavior

This can be configured in facade.properties and mobile-api-facade-config.yml.

Multiple host names

The Mobile API Facade supports multiple host names on one instance, that are configured differently. These can be configured in mobile-api-facade-config.yml. This file in YAML format. Beware that indentation is really important in YAML.

[ host name ]:
	[ properties, you want to configure ]

[ host name ]:
	[ properties, you want to configure ]

...

The allowed properties are the same as allowed in facade.properties. You can find a complete list at https://documentation.open-xchange.com/components/mobile-api-facade/config/1.8/.

Custom properties

It's possible to configure custom properties to be returned to clients. This is usefull to return special configurations to your clients. Custom properties are key/attribute values under the "customProperties" key.

Example:

appsuite.example.com:
    customProperties:
        custom.specific.property: true
        custom.specific.property.2: "value"

Client specific configuration

By implementing the client specific feature the above configuration possibilities got extended. We now have to use YAML lists for each host name. This allows to add multiple different configurations to one host configuration. You can add a list of matchers in the "matches" key to a host configuration. The first "matches" entry for a given host name that matches to the given User-Agent header sent by the client will be used. Further evaluation is not done at runtime. Configuration properties need to be on the same indentation level as the "matches" key. These host configurations inherit a default configuration from the configuration in facade.properties. Otherwise they need to be complete. They don't inherit configuration properties from other places.

[ host name ]:
	- matches:
		  [ matchers, you want to match against ]
		  [ properties, you want to configure ]
	- matches:
		  [ matchers, you want to match against ]
		  [ properties, you want to configure ]
	...

Example:

The iOS version supported in the beginning was iOS 9 and up. At some point in time due to technical reasons support for iOS 9 and 10 was dropped and the application supported iOS 11 and up. When you now want to update all installations on iOS 11 and up to the latest app version but leave old installations in intact you can use the force upgrade feature of the apps. Keep in mind that the matching process stops when the first match is found. If no match was found the default configuration is used.

appsuite.example.com:
	- matches:
		  platform: 'iOS'
		  osVersion: '11.0-'
          brand: 'OpenXchange'
	  com.openexchange.mobile.api.facade.minimumClientVersion.ios: '11.2'
	  com.openexchange.mobile.api.facade.returnNonPrimaryAccounts: false
	- matches:
		  platform: 'iOS'
		  osVersion: '-10.99'
		  brand: 'OpenXchange'
	  com.openexchange.mobile.api.facade.returnNonPrimaryAccounts: false

Matchers

Several matchers are possible. All match against values in the User-Agent header.

- platform: This matcher allows it to match only for "Android" or "iOS" - version: This matcher checks against the application version. This is not the marketing version displayed in the About screen of the application. - osVersion: The version of the operating system on the client device - device: This matches against the exact device model.

   brand: This matches against the brand name of the app. By default this is "OpenXchange". Versions specifically branded for customers have a unique brand name.

Version matching

For the matchers 'version' and 'osVersion' we allow to match concrete versions or version ranges. When adding a matcher with a concrete version, just put the version number as string attribute after the matcher name.

appsuite.example.com:
	- matches:
		  platform: 'iOS'
		  osVersion: '11.0'
	  com.openexchange.mobile.api.facade.returnNonPrimaryAccounts: false

When matching a range we are always matching inclusive. You can either use a closed range, a range with a given start value and an end value, or an open range with either a start value or an end value. Keep in mind that to match all versions lower then '11.0' you need use a probably non-existing version number like '10.99'.

appsuite.example.com:
	- matches:
		  platform: 'iOS'
		  osVersion: '11.0-'
	  com.openexchange.mobile.api.facade.returnNonPrimaryAccounts: true
	- matches:
		  platform: 'iOS'
		  osVersion: '-10.99'
	  com.openexchange.mobile.api.facade.returnNonPrimaryAccounts: false

Debugging

In order to check whether installation went successful you may want to run

  $ curl -v http://localhost:8007/services/api-facade/v1/version

That should return a JSON string like this:

{"version":"1.12.0","commitHash":"2473d87bbda63cabb4fda2f00287108e9644b5b5","middlewareVersion":"7.10.5-Rev5"}