View
10
Download
0
Category
Preview:
Citation preview
1
Mobile & Scheduling Solutions
IFS TOUCH APPS SERVER™ ADMINISTRATION
GUIDE
VERSION 1.14.0
2019-03-18
2
IFS TOUCH APPS SERVER ADMINISTRATION GUIDE
1 ABSTRACT
This document describes how to administrate the IFS Touch Apps Server.
Contents
1 Abstract ................................................................................................................................. 2
2 Login ...................................................................................................................................... 4
3 Customer Portal .................................................................................................................... 6
3.1 Customer Information ................................................................................................... 6
3.2 IFS Application Installations .......................................................................................... 6
3.3 Registering the IFS Touch Apps Server with the IFS Cloud............................................ 6
3.4 Installing Apps ............................................................................................................... 7
3.5 Device Approval ............................................................................................................ 8
3.6 Upgrading Apps ............................................................................................................. 8
3.7 System Configuration .................................................................................................... 9
3.8 App Configuration ......................................................................................................... 9
3.8.1 Mandatory Two Factor Authentication ............................................................... 10
3.8.2 FNDMOB App Configuration ............................................................................... 10
3.9 System Configuration: App Device Approval .............................................................. 11
3.10 System Configuration: App Device Register ................................................................ 12
3.11 System Configuration: Authentication Block .............................................................. 13
3.11.1 Authentication Block Configuration .................................................................... 13
3.11.2 Authentication Block in action ............................................................................ 14
3.12 Configuration parameters ........................................................................................... 16
3.12.1 Maximum Message size ...................................................................................... 16
3.12.2 Maximum number of calls................................................................................... 16
4 Usage Log ............................................................................................................................ 17
5 System Log .......................................................................................................................... 18
5.1 Category ...................................................................................................................... 18
5.2 Source .......................................................................................................................... 18
5.3 Actions ......................................................................................................................... 18
6 Downloads ........................................................................................................................... 19
3
7 Appendix ............................................................................................................................. 20
7.1 App Device Approval flow ........................................................................................... 20
7.1.1 Initial client requests ........................................................................................... 20
7.1.2 Reviewing requests ............................................................................................. 21
4
2 LOGIN
Open the IFS Touch Apps Server portal on the port specified during the installation (port 8080 by default). You should be presented with a screen that looks something like this:
Figure 1: IFS Touch Apps Server - landing page
Press “Sign in to IFS Touch Apps Server” and you will be taken to the sign in screen:
5
Figure 2: IFS Touch Apps Server - Sign In page
Log in by entering your System ID (as specified during the installation) and the credentials of an IFS Applications user with admin privileges. If you can log in successfully, the installation and configuration has been successfully validated and you can proceed to configure your installation. If you entered an incorrect application server URL during the installation, you can run the installation again and correct it or login as a Local Admin. When you select Local Admin, you log in using the Windows ID and Password for a user that is a member of the Local Administrators group. When logged in you are redirected to the Customer Portal. Note that if you want to manage an FNDMOB app, you should not use the “Local Admin”
mode. See FNDMOB App Configuration.
6
3 CUSTOMER PORTAL
In the Customer Portal, you can edit your customer information and configure one or more
Systems / IFS Applications installations.
3.1 CUSTOMER INFORMATION
To edit Customer Information, press Edit, do the desired changes and press Update.
3.2 IFS APPLICATION INSTALLATIONS
Each IFS Touch Apps Server installation can handle one or more systems identified by a System
ID that is known to the clients. Each system is connected to an IFS Applications Installation. The
installer creates and updates the first system in the list.
To edit information for a system, press Edit in the list.
Figure 3: Service instance details - edit screen
For an Apps9 system you get two extra fields for an IFS User and Password. These are only
used when using apps based on FNDMOB. See FNDMOB App Configuration.
Change desired parameters and press Save.
To add a new system, press Add System and fill in information in the same detail window as
above.
To remove a system, press Remove.
3.3 REGISTERING THE IFS TOUCH APPS SERVER WITH THE IFS CLOUD
The IFS Touch Apps Server can be registered with the IFS Cloud. This will allow application
DLL’s to be synchronized from the IFS Cloud (see Installing Apps below for more information).
Registration is optional. To be able to register, the server must be allowed to connect to
https://cloud.ifsworld.com:8080.
7
Figure 4: Cloud Connection Status
To register the Touch Apps Server with the IFS Cloud, click the Registration link in the Cloud
Connection Status section as shown in Figure 4. A system ID is used to uniquely identify the
Touch Apps Server with the IFS Cloud. The system ID should have the format <id>.<domain>
(e.g. the system id for a Touch Apps Server belonging to IFS might be called tas1.ifsworld.com).
You can select any of your existing system ID’s for the connection or you can add a new service
instance, not connected to an IFS Application installation, dedicated to the IFS Cloud
connection.
3.4 INSTALLING APPS
Applications are distributed as DLL files. Deployment to the IFS Touch Apps Server is done by
copying the DLL to the Apps folder in the Touch Apps Server file structure in IIS.
The default location of the deployment directory is “c:\inetpub\IFS Touch Apps Server\Apps”,
where “c:\inetpub” is the IIS install directory and “IFS Touch Apps Server” is the name of the IIS
Application name as specified when installing the Touch Apps Server. If you are unsure about
the location you can view it in the IIS Manager. The physical path to the site can be found
under Basic Settings for the IFS Touch Apps Server site.
If the Touch Apps Server has been registered with the IFS Cloud, application DLL’s can be
downloaded and installed through the Customer Portal eliminating the manual file copying
step of the app installation. The “Download and install App Resources” link (see Figure 5) leads
to a download page where new and updated DLL’s can be downloaded and installed. This page
will only list new and updated applications. Already installed software will not show up.
Figure 5: App Resource Download
Once the applications have been installed they need to be enabled before end users can access
them. Please refer to the App Configuration section for information about how this is done.
If you are installing an FNDMOB application, additional restrictions apply. See FNDMOB App
Configuration.
8
3.5 DEVICE APPROVAL
This section is only shown if there is at least one system setup to use device approval and
there is at least one device awaiting approval.
Figure 6: Device Approval
Click on the system to get to the App Device Approval page.
3.6 UPGRADING APPS
When a new version of an application is released the new DLL should be copied to the Apps
folder as described in the Installing Apps section above.
If the new DLL has the same name as an existing file, the old file should be overwritten and the
new code will be used automatically for any subsequent calls to the app.
The normal upgrade scenario is that the new DLL represents a different version of the
application and has a new name. When the new DLL is copied to the Apps folder there will be
two versions available in the App Configuration page for your systems. To start using the new
version it must be enabled for the relevant systems. If upgrading within the same major
version (as indicated by the first digit in the version number) the old version will be
automatically disabled. Running two releases of an app with the same major revision is not
supported. If the new version of the app is a new major version then the old version should
remain active until all clients have upgraded to the latest version of the client app.
Example: Upgrading from version 2.1.0 to 3.0.0
1. Enable version 3.0.0
2. Wait for all clients to upgrade to new client apps
3. Disable version 2.1.0
If you are upgrading an FNDMOB application, additional restrictions apply. See FNDMOB App
Configuration.
9
3.7 SYSTEM CONFIGURATION
When pressing ’Configure’ for a system ID in the list of IFS Applications installations in the
Customer Portal, then you come to the configuration page for that system.
Three system level configuration options are available here:
1. Enabling and disabling App Device Approval – see App Device Approval
2. Viewing devices already approved or rejected – see App Device Register
3. Preventing account lockout due to authentication failures – see Authentication Block
In addition, this page also lists all the available apps, and some of them provide additional
configuration support. Clicking the Configure link for an app takes you to the App
Configuration page, detailed below.
3.8 APP CONFIGURATION
To change App Configuration for a system, press Configure.
Figure 7: App Configuration
Select which applications should be enabled for the system. For each application, there can
only be one revision enabled within the same major version (e.g. 2.1.0 and 3.0.0 can both be
enabled, but 2.1.0 and 2.2.0 cannot be enabled concurrently).
10
3.8.1 MANDATORY TWO FACTOR AUTHENTICATION
Some applications support Two Factor Authentication. An additional “Mandatory Two Factor
Authentication” column may be displayed in the above list containing a check box. If none of
the applications in the list support Two Factor Authentication, the column is not displayed: this
is the case in the screenshot above. The check box is disabled if the application does not
support Two Factor Authentication. If the check box is ticked, users must register for Two
Factor Authentication to use the application. If the check box is not ticked, Two Factor
Authentication is optional.
3.8.2 FNDMOB APP CONFIGURATION
For Apps built on the FNDMOB framework in APPS9 there is some extra configuration
functionality. These apps rely on metadata deployed to IFS Applications and require separate
granting in IFS Solution Manager. The steps to enable an app like this are:
1. In the portal validate metadata to ensure that the required components are installed
in IFS Applications.
NOTE: you might see some messages resulting from this operation.
INFO messages mean there are no issues in the system. These might appear if the
optional components / DB objects are not installed in the IFS Applications instance.
ERROR messages mean that mandatory components / DB objects are not installed in
the IFS Applications instance. App functionality will not work as expected.
2. In the portal, click the relevant Deploy Meta link. This will deploy metadata about the
app to IFS Applications.
3. In IFS Enterprise Explorer (Solution Manager) configure the app and grant access as
required.
4. In the portal Enable the app. This will also activate the app in IFS Applications.
NOTE: to deploy metadata and enable or disable an FNDMOB app, you must be logged in as a
user of the system that you are deploying metadata to, and your user must have the IFS
Mobile Admin privilege. You cannot use the “Local Admin” mode with FNDMOB apps.
For more details, please refer to IFS Applications Technical Documentation.
11
3.9 SYSTEM CONFIGURATION: APP DEVICE APPROVAL
IFS recommend that customers use EMM (Enterprise Mobile Management) or MDM (Mobile
Device Management) software to secure mobile devices. The IFS Touch Apps App Device
Approval functionality is meant to be used as a compliment to this type of software, where it
can be used to ensure that users cannot run IFS Touch Apps from devices that are not under
EMM/MDM control.
Ticking the “Enable App Device Approval” check box will show a list of supported apps. Please
note that not all IFS Touch Apps currently support App Device Approval, and only supported
apps will be listed here.
Figure 8: App Device Approval - enabling device approval for individual apps
It is possible to switch on App Device Approval before enabling the app for the system. This
feature can be used to ensure that access is not possible for unapproved devices.
For more details about this functionality, see App Device Approval flow.
12
3.10 SYSTEM CONFIGURATION: APP DEVICE REGISTER
This page lists the devices connected to the system. By default, “Only Pending Approval” is set,
to show only those devices that have not been approved or rejected yet.
Press Approve to allow the user on the device to use the app.
Press Reject to prevent the user on the device to use the app.
Figure 9: App Device Register - Only Pending Approvals
To reject a device that has previously been approved:
Uncheck “Only Pending Approvals” to show all devices.
Press Reject for the desired device.
Figure 10: App Device Register - all
13
3.11 SYSTEM CONFIGURATION: AUTHENTICATION BLOCK
3.11.1 AUTHENTICATION BLOCK CONFIGURATION
Touch Apps Server 1.6.0 and later supports the Authentication Block functionality, which
introduced a configurable limit of authentication failures per user and system. This works by
tracking each authentication failure for a configurable duration, and then blocking
authentication attempts if a threshold number of authentication failures are currently being
tracked. This prevents authentication failures from locking the user at either the Database
level or at the corporate network level in Single Sign-On (SSO) environments.
Authentication Block is Disabled by default, and can be enabled and configured on each
System ID as required.
Figure 11: Authentication Block in Disabled state
Tick the Checkbox to Enable the Authentication Block functionality. This will then make the
two input boxes editable with the default values. Modify the values if required, and then press
the Update button to save and apply the changes. Untick again and press the Update button
to disable Authentication Block.
Note: Authentication Block settings are not automatically saved and applied, and must be
applied with the Update button.
Figure 12: Enable and configure Authentication Block
1
2
3
4
14
The default value for Threshold and Duration are explained below.
Configuration Setting Definition Default value
Authentication Block
Threshold
The number of authentication failures
that will trigger blocking of further
authentication attempts.
2 authentication failures
Authentication Block
Duration
Each authentication failure will be
tracked for this time duration.
Authentication attempts will be blocked
if the currently tracked authentication
failure count matches the Threshold.
300 seconds (5 minutes)
3.11.2 AUTHENTICATION BLOCK IN ACTION
Let’s assume on a certain system, you enabled Authentication Block with the default values of
blocking on 2 authentication failures within a tracking duration of 5 minutes.
You can now try to authenticate on any app running on that Touch Apps Server against that
System ID. On the first failed authentication attempt, let’s say at 09:02, you will see the
standard error message, and the TAS will record this authentication failure for the System ID +
User ID combination along with the timestamp.
On the second failed authentication attempt, let’s say at 09:04, you will again see the standard
error message. The TAS will record this failure as well along with the timestamp. Refreshing
the TAS page will list the User ID’s currently blocked, and your user will also be listed there
since two failures are being tracked. This authentication block applies from 09:04 until tracking
of the first failed attempt expires (i.e.: 09:02 expires at 09:07, a block of 3 minutes).
Let’s say you make another failed login attempt at 09:08. The TAS will not block this attempt,
since only one failure (from 09:04) is currently being tracked, but will note the failure. The
threshold exceeds again, so Authentication Block applies once again and will last until 09:09 (a
block of 1 minute) until tracking of the 09:04 failure stops.
15
Figure 13: List of Blocked Users
The user will be unblocked when
• The time since the last recorded authentication failure is greater than the Duration
parameter,
• Or you press the “Unblock” link against the user you want to unblock (in which case
only the chosen user will be unblocked),
• Or you press the “Unblock All” link (in which case all currently blocked users are
unblocked).
Any authentication attempts, whether valid or invalid, while the user is blocked, will result in
the “Authentication Blocked” message. This means that the database will not see the invalid
authentication attempt, thus reducing the likelihood of the Oracle or SSO user being locked.
Figure 14: “Authentication Blocked” message
Note: Unblocking a blocked user clears the TAS’s list of failed authentication attempts, but
does not clear the number of failed authentication attempts tracked for that Oracle / SSO user.
16
3.12 CONFIGURATION PARAMETERS
The file web.config (default location c:\inetpub\IFS Touch Apps Server\web.config) contains
parameters that can be adjusted to fit the customer installation.
3.12.1 MAXIMUM MESSAGE SIZE
The default settings for inbound messages are set to 8MB with individual values restricted to
4MB. In a system where the end users might send larger files (e.g. high-resolution photos or
videos) these values should be adjusted accordingly.
The settings in question are maxReceivedMessageSize and maxStringContentLength, both
found in the <system.servicemodel><bindings> section of the configuration file. The values are
given in number of bytes.
The maximum size for strings in outbound messages is controlled by MaxJsonLength in
<appSettings>. The default value is 4MB. In some installations, this might have to be increased.
This setting does not affect binary downloads such as document attachments.
3.12.2 MAXIMUM NUMBER OF CALLS
The default settings allow for 500 concurrent calls to be processed by the Touch Apps Server.
This setting does not correlate directly with the maximum number of users and 500 concurrent
calls would normally be sufficient even in very large installations. The more concurrent calls an
installation allows the higher the potential load on the database. In large installations with
1000’s of users initializing their devices concurrently this setting might have to be changed to
achieve maximum throughput. However, it’s vital in these situations to monitor the load on
the database since this will typically be the bottle neck. Over loading the database might also
result in lowered throughput so sometimes it’s better to throttle end user requests in the
Touch Apps Server.
The relevant parameters are maxConcurrentCalls, maxConcurrentSessions and
maxConcurrentInstances, found in the <system.serviceModel><behaviors><serviceBehaviors>
section of the configuration file. These parameters control the maximum number of incoming
requests that can be processed by the Touch Apps Server. There is also maxconnection under
<system.net><connectionManagement>. This setting controls the maximum number of
outgoing connections (i.e. calls to the IFS Applications installation) and can also be used as an
optimization setting.
The typical scenario would be to set maxconnection, maxConcurrentCalls and
maxConcurrentSessions to the same value, with maxConcurrentInstances set to double this
value. Sometimes though, a system might perform better with a lower maxconnection setting.
If the load on the IFS Applications database is too high, lowering maxconnection might not only
reduce the load on the database, it might increase throughput.
17
4 USAGE LOG
Figure 15: Usage Log page
The Usage Log allows users to monitor application usage. The user will enter the desired From
and to dates and press “View” or “Export to Excel”. The summary option will list app usage by
customer (as shown in the screenshot above). The export to excel option will export an excel
file with more detailed usage information.
18
5 SYSTEM LOG
Figure 16: System Log page
Here you can view entries from the System Log. You can use criteria to the limit the result set.
The functionality is shared between the Cloud and TAS so some criteria are valid for both and
some only for one of them.
5.1 CATEGORY
• App Management
Entries about uploading and publishing of app resources.
• Configuration Update
Entries about changes of Admin Portal data.
• Failed Authentication
Entries for users that couldn’t authenticate, can be wrong password, backend not
reachable etc.
• Failed Authorization
Entries for users that could authenticate but lack a needed privilege. E.g. Lacking
privilege: "System Privilege: ADMINISTRATOR".
5.2 SOURCE
• Client
Entries originating from clients.
• Customer Portal
Entries originating from the Customer Portal
5.3 ACTIONS
• View
Shows data in the page
• Export to Excel
Exports the data directly.
19
6 DOWNLOADS
Apart from the store distribution method, Mobile app clients can be distributed using the
downloads page in Touch Apps Server. Once you place the installation file in the following
directory, “c:\inetpub\IFS Touch Apps Server\{{SYSTEM ID}}\” it will be shown in the
downloads page. (Figure 17)
Supported File types.
Android IOS Windows
.apk .ipa .exe
Figure 17: Downloads Page
20
7 APPENDIX
7.1 APP DEVICE APPROVAL FLOW
Once App Device Approval has been enabled for an app, as described in System Configuration:
App Device Approval, the functionality is active and will disallow app usage on a device until an
administrator has reviewed and approved the request. This section will describe how this
appears to end users and administrators both.
7.1.1 INITIAL CLIENT REQUESTS
The first step is for a user to install and try to run the app on their device. The user will then
see a message like that shown in Figure 18.
Figure 18: App Device Approval - initial client message
Subsequent attempts to use the app before usage has been approved will result in a similar
error message stating “Usage of this app is pending approval by your system administrator”.
21
7.1.2 REVIEWING REQUESTS
To view pending device app usage approval requests the administrator must log in to the
Customer Portal, where a new section “Device Approval” will show up at the top of the page
(see Figure 19).
Figure 19: Device Approval - requests pending
Clicking the System ID will take the administrator to a detail page listing all approval requests,
both historical and active. Historical (approved/rejected) request are hidden by default, but
can be shown by unchecking the “Only Pending Approvals” checkbox.
Figure 20: Device Approval - detail page
Usage requests can be approved or rejected by clicking the corresponding Action link in the
rightmost column of the table.
Once the request has been approved the user can start using the app. If app usage is rejected,
any future attempts to use the app on the rejected device will result in an error message:
“Usage of this app is not allowed on this device”.
22
To reject a device that has previously been approved, clear the “Only Pending Approvals”
checkbox to show all devices and press “Reject” for the desired device.
Figure 21: Device Approval - reject previously approved request
Recommended