In the Customer Portal, you can edit your customer information and configure one or more Systems / IFS Applications installations.
To edit Customer Information, press Edit, do the desired changes and press Update.
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.
Note 1: If multiple Systems are registered within the IFS Touch Apps Server the IFS Application Installations that they connect to must all be at the same Update version. The IFS Touch Apps Server is shipped with IFS Application Updates and is not backward compatible. It is recommended that one IFS Touch Apps Server is used for one IFS Application Installation
To edit information for a system, press Edit in the list.
Figure 1: Service instance details - edit screen
The IFS User and Password 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.
If the IFS Applications installation is configured to use an OpenID Connect Provider, the set of Redirect URIs for IFS Applications within the provider configuration must be extended.
For more details, see OpenID Connect Provider Configuration.
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.
Once the applications have been installed they need to be enabled before end users can access them. Please see System Configuration and App Configuration for information about how this is done.
If you are installing an FNDMOB application, additional restrictions apply. See FNDMOB App Configuration.
Device Approval is only shown if there is at least one system setup that uses device approval and that there is at least one device awaiting approval.
Figure 2: Device Approval
Click on the System to get to the App Device Approval page.
For enhanced offline security it is possible to specify that a PIN is required to logon to the App. Once checked, any user connecting via the App for the first time will be prompted to enter a PIN that will subsequently be used to logon to the App.
Note 1: This feature is only available in certain Apps that have been designed to use this feature.
Note 2: This is a global feature for the system and will affect all Apps that are designed to use this feature.
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
If you are upgrading an FNDMOB application, additional restrictions apply. See FNDMOB App 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:
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.
To change App Configuration for a system, press Configure.
Figure 3: 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).
The different Touch Apps have different configuration. In order to configure a Touch App, see Touch Apps Business Components.
For Apps built on the IFS Mobile Framework (FNDMOB) there are some extra configuration functionality. These Apps rely on metadata deployed to IFS Applications and require separate granting in Solution Manager. The steps to enable an app like this are:
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.
Note 1: 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 permission set 'TOUCHAPPS_ADMIN' for IFS Mobile Admin privilege. You cannot use the Local Admin mode with FNDMOB apps.
Security Info displays a list of Mandatory and Optional Views, Methods and Activities a user needs to have granted to run the app.
Generates a SQL script that creates a Functional Role and assigns the included grants to that Role. If there are optional grants, edit the script to suit the intended use of the app. The name of the Role is a parameter &TOUCHAPP_APP_NAME that can be changed to suit any naming standard in use. The script can be deployed using sqlplus or any other sql-tool of your choice. The Functional Role should then be granted to an End User Role that can be granted to users.
Figure 4: Example of how to set up a End User Role granting a TouchApps Functional Role.
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 5: 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.
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 6: 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 7: App Device Register - all
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.
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.
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.