Administration Overview

5/12/2023
Administrator
Generated on: 2023-05-12 00:22:51 GMT+0000
SAP Mobile Platform Server 3.1 | 3.1
PUBLIC
Original content: https://help.sap.com/docs/SAP_MOBILE_PLATFORM_SERVER_31/313e7789125149b3b5bb6f1c7e1ea322?locale=en-

US&state=PRODUCTION&version=3.1.0
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation.
The information included in custom documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be missing
important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/docs/disclaimer.
This is custom documentation. For more information, please visit the SAP Help Portal 1
5/12/2023
Administration Overview
Administrators interact with SAP Mobile Platform to ensure the mobile application production environment works efficiently.
Administrator tasks fall into three main categories:
Server administration for con guring the server, enabling optional server features, and troubleshooting server issues.
Application administration for de ning application types for deploying to users and monitoring applications in the user community.
Security administration for setting up secure communications and protecting data.
There are separate administration tasks for Mobiliser applications.
SMS applications are administered through a separate server.
SAP Mobile Platform Server Overview

SAP Mobile Platform Server is an OSGi based application server that provides both application services and core services.
Application services are specialized for a speci c application type. Core services can be accessed and used by any application type.
Offline Applications Overview
Offline support enables client applications to access back end data without requiring a connection to the back end.
Logging and Tracing Overview
SAP Mobile Platform provides supportability through logs and traces that enable administrators, developers, and support
professionals to troubleshoot application issues. All logs have a common format and are stored in the SAP Mobile Platform Server
database. All log entries for a particular business or application ow (such as an OData request or a registration) are correlated
across the client and server stack. This enables you to visualize and understand the end-to-end ow, which helps in identifying the
source of an application problem. In addition to logs and traces, you can activate end to end tracing on a per user/device basis to
enable support to perform end-to-end diagnostics to identify performance or functional application problems.
Hybrid App Feature Restriction Overview
You can set feature restriction policies for hybrid apps in Management Cockpit. This gives you additional control over the SAP Fiori
Client application features that are allowed and restricted.
Push Overview
Use the push feature to push updates from the back-end data source to applications that are running on mobile devices.
Client Database Upload Overview
End users can securely upload local database les from a supported device to the server for analysis.
Exceptions When Working in a Clustered Server Environment
Keep a few things in mind when working in an clustered server environment.
Related Information
Application Administration
Server Administration
Security Administration
Application Services (Mobiliser) Administration
SMS Administration
SAP Mobile Platform Server Overview

SAP Mobile Platform Server is an OSGi based application server that provides both application services and core services. Application
services are specialized for a speci c application type. Core services can be accessed and used by any application type.
5/12/2023
Application services consist of services for Mobiliser and Agentry applications.
Core services consist of the following:
Application Analytics – usage statistics that can be displayed graphically in Management Cockpit.
App Resources – containers of dynamic con gurations, styles, or content that can be downloaded by Native applications.
Data Integration – standards-based integration to both SAP and non-SAP back-end systems.
HTTP(s) Con guration – open standards for client communications.
Lifecycle Management – managing and deploying multiple versions of a hybrid application.
Management Cockpit – deploying, managing and monitoring native, hybrid, Agentry, and Mobile BI applications.
Offline OData Service – optimizes the transport of data between the backend and the client offline store.
Push Noti cations – native noti cations sent from back-end systems to the server, which forwards them on to the clients.
Security Pro le – authentication services based on third party identity management systems.
Supportability – logs for monitoring system health and troubleshooting.
SAP Mobile Platform Server as an OData Proxy

SAP Mobile Platform Server provides an OData proxy service through HTTP/HTTPS, which proxies back-end servers to clients.
5/12/2023
SAP Mobile Platform Server as an OData Proxy

SAP Mobile Platform Server provides an OData proxy service through HTTP/HTTPS, which proxies back-end servers to clients.
HTTP compression is used to reduce network traffic and improve server response times. SAP Mobile Platform Server returns GZIP-
compressed responses only, but also supports zlib-compressed responses from back ends. SAP Mobile Platform Server decompresses all
zlib-compressed back-end responses. Clients indicate whether they support compression, and if they do, the compression techniques
they support.
The OData proxy service can rewrite the content that is exchanged between clients and back-end systems, updating absolute URLs so
they refer to the external URL of SAP Mobile Platform Server. The proxy service also supports the use of one or more single sign-on
(SSO) mechanisms; and manages cookies for clients.
URL Rewrite Modes

The SAP Mobile Platform Server OData proxy can rewrite the content that is exchanged between clients and back-end systems. This is
mainly used for OData requests and responses that contain entity references as absolute URLs. These absolute URLs must be changed
to refer to the external URL of SAP Mobile Platform Server.
SAP Mobile Platform Server supports these URL rewrite modes:
URL Rewrite in SMP
URL Rewrite in Backend
No URL Rewrite
You set the URL rewrite mode for an application when you con gure its back-end connection.
If an application requires data from a back end that uses relative URLs, that is, URLs that do not have a schema or host, but have a path
relative to the current document, con gure the relative URL patterns in Management Cockpit; on the application's back-end connection
page, set the value of Relative Path. See De ning Back-End Connections.
URL Rewrite in SMP or No URL Rewrite

In a typical setup, one application connects to one back end.
The client is registered with the application ID myapp and calls the OData proxy, providing the application ID as the rst segment of the
path. The OData proxy replaces the application ID with the con gured back-end path /odata/service1 and forwards the request to
the back end.
When an application has access to more than one back end, the name of the back end is used, instead of the Application ID.
 Note
5/12/2023
The SAP Mobile Platform Server does not provide the functionality to use No Rewriting mode to support external back ends for offline
usage.
URL Rewrite in SMP

When URL Rewrite in SMP is selected, the server rewrites the HTTP request/response headers and most content. Binary data such as
images and PDF documents are not changed.
SAP Mobile Platform Server replaces all instances of the back-end URL in HTTP request and response message bodies with its server
URL. For example, the server rewrites both instances of the back-end URL http://services.odata.org/V2/Northwind in this
HTTP request:
<entry xml:base="http://services.odata.org/V2/Northwind/Northwind.svc/"
xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<id>http://services.odata.org/V2/Northwind/Northwind.svc/Regions(1)</id>
<title type="text"/>
<updated>2015-12-04T15:17:04Z</updated>
<author><name/></author>
<link rel="edit" title="Region" href="Regions(1)"/>
<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Territories"
type="application/atom+xml;type=feed" title="Territories" href="Regions(1)/Territories"/>
<category term="NorthwindModel.Region" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/sche
<content type="application/xml">
<m:properties>
<d:RegionID m:type="Edm.Int32">1</d:RegionID>
<d:RegionDescription xml:space="preserve">Eastern</d:RegionDescription>
</m:properties>
</content>
</entry>
The same request after the server replaces the back-end URL with https//mysmp.sap.corp/myapp:
<entry xml:base="https://mysmp.sap.corp/myapp/Northwind.svc/"
xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<id>https://mysmp.sap.corp/myapp/Northwind.svc/Regions(1)</id>
<title type="text"/>
<updated>2015-12-04T15:17:04Z</updated>
<author><name/></author>
<link rel="edit" title="Region" href="Regions(1)"/>
<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Territories"
type="application/atom+xml;type=feed" title="Territories" href="Regions(1)/Territories"/>
<category term="NorthwindModel.Region" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/sche
<content type="application/xml">
<m:properties>
<d:RegionID m:type="Edm.Int32">1</d:RegionID>
<d:RegionDescription xml:space="preserve">Eastern</d:RegionDescription>
</m:properties>
</content>
5/12/2023
</entry>
Using Additional Paths
You can use additional paths to map and rewrite a URL that has neither a host nor additional endpoint de nitions. For example, if the
previous example references a second service on the same host with the URL
http://services.odata.org/V4/Northwind/Northwind.svc, simply add the path /V4/Northwind.
URL Rewrite in Backend

Some back ends can send and receive URLs that contain a host-name header, instead of their own server host name. Most servers such
as SAP Gateway use the Host header. SAP Mobile Platform HTML5 and other applications use the x-forwarded-for header if you
enable the Via HCP App property when you con gure their back-end connections.
This rewrite option allows the back end to change the host name and TCP port of a URL to match the incoming request to SAP Mobile
Platform Server; the path to the back end is not changed. This differs from the other rewrite options, in which the back-end connection
name (often the same as the application ID) is the rst segment of the path in the URL. The server adds its external name to the HTTP
Host header, which is sent to the back end.
The Application ID is selected based on the Application Connection ID (which the client sends as a header or cookie). In the above
example, the application maps to two back ends. The primary back end is available for requests that begin with
<filepath>/odata/<filepath>; the secondary back end is available for requests that begin with
<filepath>/service2/<filepath>.
 Note
To proxy a complete back end that can rewrite URLs, specify a single back-end URL with the path /, for example,
http://services.odata.org/ . This limits the application to a single back end, because the routing would be ambiguous
otherwise.
Considerations
Keep the following limitations and considerations in mind when working with the OData proxy service.
To enable applications using an external back end to run offline, you must select one of the rewrite options.
If you switch the rewrite mode to or from URL Rewrite in Backend, notify the application developer of the change. The developer
must change the application's base URL to accommodate online and offline mobile applications.
5/12/2023
If you select URL Rewrite in Backend, the base path of the URL must correspond to the path of the back-end URL. For example:
http://ldcigm3.wdf.sap.corp:50057/sap/opu/odata/sap/FINCUSTFACTSHEET/
For other rewrite modes, the base path must contain the application ID. For example: https://<server
host:port>/<back-end path>?X-SMP-APPID=<Application ID>
SAP recommends that if you change the rewrite mode, you should also update the mobile-application con guration.
Do not use these patterns in either application IDs (URL Rewrite in SMP) or mapped back-end paths (URL Rewrite in Backend),
because SAP Mobile Platform Server publishes services on the same path.
Admin
btx
bundles
clientlogs
clientusage
hmadmin
log les
mobileservices
MobiLink
Noti cation
odata
public
resources
restnoti cation
SAMLAuthLauncher
system
tenantadmin
xsutils
When using URL rewriting in the OData proxy, the following content types are rewritten.
application/atom+xml
application/atomsvc+xml
application/css
application/html
application/js
application/json
application/opensearchdescription+xml
application/rss+xml
application/x-www-form-urlencoded
application/xml
application/xhtml+xml
javascript
text/html
text/plain
text/xml
Mixed content contains multiple parts. Each part is based on its own content type and can be rewritten independently.
If you select URL Rewrite in Backend, you cannot use the following endpoint paths:
/Admin/
5/12/2023
/btx/
/bundles/
/clientlogs/
/clientusage/
/hmadmin/
/log les/
/mobileservices/
/MobiLink/
/Noti cation/
/odata/applications/
/odata/lcm/
/public/bundles/
/public/odata/applications/
/resources/lcm/
/restnoti cation/
/SAMLAuthLauncher/
/system/
/tenantadmin/
/xsutils/
If you select URL Rewrite in SMP, the server replaces:
Occurrences of the back-end host and path with <smphost>/<appID>. For example,
Backend URL = https://anybackend.sap.com/oData/sample

SMP URL = https://smp.sap.com/
Application ID = demo
Response: <a href=”https://anybackend.sap.com/oData/sample/Customers(‘4711’)” />
is translated into:
<a href=”https://smp.sap.com/demo/Customers(‘4711’)” />
Paths without a host and schema (relative URLs). For example, this sample response:
<a href=”/oData/sample/Customers(‘4711’)” /><a href=”/demo/Customers(‘4711’)” />
is translated into this:
<a href=”/demo/Customers(‘4711’)” />
Escaped URLs such as "\/odata", "\\/odata", " /odata", or "%2Fodata" with a similarly escaped URL.
The OData proxy can either rewrite GZIP les or de ate compressed responses. If a client supports GZIP compression, responses
are compressed.
Related Information
De ning a Back-End Connection
De ning Back-End Connections
Single Sign-On Mechanisms

5/12/2023
The SAP Mobile Platform Server OData proxy service supports the use of one or more single sign-on (SSO) mechanisms.
In single sign-on implementations, clients log in to SAP Mobile Platform Server, and then the server uses the authentication providers
that you con gure in the security pro le to authenticate the clients to back-end systems.
SSO Mechanism Description
Basic Connects to the back end with the end user's user name and password. The provider that is con gured in the security pro le
must authenticate the end user with a user name and password, for example, HTTP/HTTPS Authentication, Directory Service
(LDAP/AD), or System Login (Admin Only).
SSO2 Authenticates the user to the back end with a MYSAPSSO2 token.
To use this mechanism, all of the following must be true:
The security pro le includes either the HTTP/HTTPS Authentication (to authenticate end users against a Web server
that returns a MYSAPSSO2 token) or the SAPSSO2 Generator provider.
The back-end server is con gured to trust the signer of the MYSAPSSO2 token.
X.509 Connects to the back end using the con gured technical user's X.509 certi cate. The end-user certi cate is passed in the HTTP
ssl_client_certificate header.
Con gure the back end:
Allow a technical user to impersonate an end user by passing the end user's certi cate in the
ssl_client_certificate header and executing the request in the context of the end user. The end-user certi cate
may be generated by the Principal Propagation provider that is con gured in the security pro le, or it may be supplied
by the end user when he or she authenticates to the server over a mutually authenticated HTTPS connection. You can use
this mechanism with either the X.509 User Certi cate authentication provider or the Principal Propagation provider that
is con gured in the security pro le.
Map the user certi cate presented in the HTTP header to a user who is con gured in the user store.
Verify that the back-end service can be accessed using SSL certi cates.
Refer to your back-end system documentation for more information.
Kerberos Enter the Kerberos realm and the service name. Connects to the back end by setting the Kerberos token value in the
Authorization: Negotiate <Kerberos token> header. Con gure the back end to authenticate users with Kerberos.
You can use this mechanism only if the Kerberos provider is con gured in the security pro le. The server obtains a Kerberos
access token for the speci ed realm and service name. The realm contains the back-end resources to which you want to
provide SSO access.
 Note
The service user who is con gured in the security pro le must also be con gured in Active Directory with permission to
delegate to the application-endpoint service.
Technical User Enter the user name and password for the technical user. Connects to the back end using these credentials.
(Basic) You can use this SSO mechanism with any authentication-provider con guration in the security pro le.
Technical User Connects to the back end using the con gured technical-user X.509 certi cate.
(X.509) If selected, also choose a Certi cate Alias. The list contains the alias values for certi cates in the shared server keystore
(smp_keystore.jks).
You can use this mechanism with any authentication-provider con guration in the security pro le.
5/12/2023
SSO Mechanism Description
Headers/Cookies Sends con gured headers/cookies with values derived from a regular expression. This is a generic mechanism to pass SSO
details that are not covered by other explicit mechanisms. Select Custom, and enter:
Name – name of the header or cookie.
Pattern – header or cookie value.
Type – header or cookie.
When the user authentication was done using the OAuth Authentication Provider, the original OAuth2 token can be sent along to a
back end. Use the following settings:
Type header
Name Authorization
Pattern ${OAuth2Token}
No Back ends require no credentials for authentication. Your destination is granted direct access to relevant on-premise services.
Authentication
Related Information
How SAP Mobile Platform Server Handles Cookies

When calling endpoints or back ends via SAP Mobile Platform Server, which acts as an OData proxy (ODP), the server manages the
cookies it receives on behalf of the client.
In a typical setup, the client connects through a load balancer or reverse proxy, rather than directly to SAP Mobile Platform Server. The
load balancer or reverse proxy forwards the request to an SAP Mobile Platform Server instance and the SAP Mobile Platform Server
OData proxy calls the back end.
The following steps outline how SAP Mobile Platform Server handles cookies after the client has issued a call to either the server or a
con gured endpoint.
1. The client sends the application registration, also known as APPCID, either as a header or cookie value. The request also contains
a session cookie from SAP Mobile Platform Server and probably from the load balancer or reverse proxy and back end.
2. The load balancer or reverse proxy handles the session cookies that the client sends to provide session stickiness. In most cases,
these cookies are forwarded to SAP Mobile Platform Server.
3. SAP Mobile Platform Server uses the APPCID and session cookie to identify a client session. It also may add single sign-on cookies
to the back-end request. SAP Mobile Platform Server lters out existing platform-speci c cookies (created by the server) that
must not be forwarded to the back end. The following cookies are ltered (ignoring case):
Host
X-SupDeviceID
User-Agent
Connection
X-SUP-APPCID
X-SMP-APPCID
X-SMP-SESSID
ias-rs-sessionid
X-SMP-SESSIDSSO
jtenantsessionid...
5/12/2023
In addition, you can con gure the following cookies by setting the
com.sap.mobile.platform.server.proxy.core.handler.DirectProxy.ignoreCookieList system property (for
example, by adding it to the props.ini le in the SAP Mobile Platform Server home directory). Cookie names must be
separated by commas. You can use a trailing asterisk to indicate that all cookies starting with the given name should be ignored. If
you do not provide this property, the following cookies are removed (default con guration):
BIGip...
JSESSIONID
4. SAP Mobile Platform Server stores all the cookies that are returned by back ends in a cookie store, which mimics standard
browser behavior. The cookie store is serialized into a string, gzipped, and Base64 encoded.
5. The cookie-store string is split into fragments of 4000 characters and sent back to the client as a cookie with the pre x
SMP_COOKIE_STORE_<appcid>_<num>, where <num> is a running number starting with zero (0), and <appcid> is replaced by
the Application Connection ID of the client. These cookies are always marked as http-only. When an incoming connection to SAP
Mobile Platform Server is using HTTPS, the cookies are marked as secure.
6. When an incoming request from the client contains cookies matching the SMP_COOKIE_STORE_<appcid>_0-99 pre x, the cookie
store is reassembled, concatenating the various parts, Base64 decoded, un-gzipped, and then used for communicating with the
back end. Additional cookies that the client sends and are not part of the list are always ltered and forwarded to the back end as-
is.
7. The load balancer or reverse proxy may add another session cookie if the cookie has changed or was not present in the original
client request. These additional cookies are added to the response after it has been handled by SAP Mobile Platform Server.

Offline support enables client applications to access back end data without requiring a connection to the back end.
 Note
Does not apply to Agentry applications.
You might want to run applications offline to:
Improve performance by accessing offline data instead of sending data requests to SAP Mobile Platform Server.
Enable users to continue to use applications when there is intermittent network coverage.
Support business processes that must be executed by a user while the application is offline.
To work offline, an application must initialize an offline store, which stores data that the application can access when it is offline. SAP
Mobile Platform Server provides an Offline OData Service that moves data between the back end and the client offline store.
5/12/2023
The server retrieves data from an OData producer that is running in a back end and creates the inital database on the client. If the back
end does not have an OData producer, the server uses Integration Gateway to convert other types of datasources to OData. The server
updates the client database based on deltas with the back end. Deltas between the back-end data and the client data are computed by
the back end or by the server.
You can con gure offline applications to optimize offline performance by de ning:
Column indexes for the client database
Common user data to cache on the server to reduce the amount of data that needs to be synchronized with the back end.
When an application is offline, it accesses data from the offline store. Any updates that are made while the client is offline are stored
locally and become pending updates for the back end. When the client comes back online, SAP Mobile Platform Server updates the back
end by processing the pending updates.
Related Information
De ning Offline Application Settings
Server Con guration: Offline

SAP Mobile Platform provides supportability through logs and traces that enable administrators, developers, and support professionals
to troubleshoot application issues. All logs have a common format and are stored in the SAP Mobile Platform Server database. All log
entries for a particular business or application ow (such as an OData request or a registration) are correlated across the client and
server stack. This enables you to visualize and understand the end-to-end ow, which helps in identifying the source of an application
problem. In addition to logs and traces, you can activate end to end tracing on a per user/device basis to enable support to perform end-
to-end diagnostics to identify performance or functional application problems.
System logs collect log messages that allow administrators and support professionals to identify problem areas. Developers can identify
code problems by capturing debug level log messages. Set the log level for individual logging components to specify the amount of
information captured.
Application tracing captures additional business data for a request (such as message data, payloads, HTTP headers, and URIs), which you
can use to troubleshoot application problems. The business data captured in application traces is determined by the application
developer. Enable tracing for individual logging components on an as-needed basis.
5/12/2023
E2E tracing sessions are conducted by administrators and device users. E2E trace information is recorded in a Business Transaction XML
(BTX) le on the client, which is uploaded to the server, and then uploaded to SAP Solution Manager for analysis.
Related Information
Setting Log Levels
Viewing Logs and Traces
Viewing Server Log Files
Enabling Application Traces
De ning Client Log and Trace Policies
Using End-to-End Tracing to Troubleshoot and Diagnose Device Problems
Viewing Client Tracing
Hybrid App Feature Restriction Overview

You can set feature restriction policies for hybrid apps in Management Cockpit. This gives you additional control over the SAP Fiori Client
application features that are allowed and restricted.
When you edit a hybrid app in Management Cockpit, available feature plugins are listed on the Client Policies screen. You can indicate
features that should be restricted from the user. Feature plugins are typically JavaScript APIs that provide access to the native APIs of
the mobile device (implemented as Apache Cordova plugins). Plugins include:
Cordova Camera
Barcode Scanner (plugin for different types of barcode scanners, using the device's camera)
Cordova Contacts
Cordova File
Cordova Geolocation
Cordova Calendar
Print
SAP Push Plugin
You can also manage a list of feature restriction policies for all applications from a central location. Each of the centrally maintained
feature restriction policies work as a template. An updated template is automatically applied to new hybrid applications, and can be
manually applied to existing ones. Override the template for individual hybrid apps.
Push Overview
Use the push feature to push updates from the back-end data source to applications that are running on mobile devices.
You can use SAP Mobile Platform to manage push for individual applications that use native noti cations.
5/12/2023
Developers enable native push noti cation in the application code, and link the certi cate with the mobile application at build time. Users
download the application from a market place, such as Apple App Store, Google Play, or similar service, and, when a change occurs in the
back end, it sends a push noti cation to mobile applications on devices with push enabled.
Push Noti cation

For native mobile applications, the platform manages the certi cates, tokens, and push noti cations for individual applications. When
changes occur, the back end sends push noti cations to mobile applications on devices that are push enabled.
Custom Push Provider

The custom push provider enables you to con gure applications to receive push noti cations via a private push vendor. For example, for
an application running on Android, you may want to replace the GCM push service for a local vendor service. Con gure the custom push
provider for speci c device types.
Push Statistics
View push noti cation statistics for push-enabled apps from Push Statistics. You can see noti cation details, noti cations by applications,
and noti cations by operating system.
Capabilities-based Push Support

Capabilities-based push enables a back-end to trigger a push to applications that provide a certain capability. Developers con gure
application connections to handle capabilities using the REST API (see REST API Application Development Overview). Devices send
capability type information during registration or update. SAP Mobile Platform maintains the mapping between capabilities and
applications.
Device-type (form factor) Support

Devices send device type information to the server during registration. Device types are categorized into groups using the form factor
property. The client can use any non-empty string for the device type (case insensitive), such as SmartPhone, phone, Watch, desktop, and
so forth.
 Note
Hybrid apps do not support device-type (form factor), with the exception of Fiori Clients downloaded from the App Store, and custom
Fiori Clients.
Con guration of Capabilities

Application capabilities are part of the central application connection con guration. Similar to how the administrator controls some
device capabilities from the server through feature policies, users control some application capabilities from the device. Device
capabilities are controlled by the application and sent to the server. The capabilities are exchanged between the mobile app as part of
the registration and settings exchange.
Through that mechanism, the mobile app can also override default capabilities. This gives users more control, enabling them to turn off
certain capabilities for a mobile app instance, which translates into turning off native push noti cations for a certain action into a
particular application. Push can still be offered, but at the capability level, rather than individual application level.
Actionable Push
Starting with iOS 8, Apple supports actionable push noti cations. The push API offered with SAP Mobile Platform has been enhanced to
support this feature. Using the API, the back end provides the capability for back ends to send the push 'category' through the platform
to the device. This change applies to iOS only; for Android actionable push is fully controlled on the device by the app.
5/12/2023
 Note
Hybrid apps do not support actionable Push.
Client Database Upload Overview

End users can securely upload local database les from a supported device to the server for analysis.
The administrator creates a database upload policy for a speci c application via the cockpit. The developer uses an API to enable client
upload capability in speci c applications, enabling later access to the uploaded database les to troubleshoot problems. The server
checks for offline store les upon start up, and every hour, and automatically deletes expired les.
Developers (Application Development)

The developer uses the Database Upload API to enable client upload capability in a speci c application. Typically a prompt is provided for
the application user to upload a le for analysis. By default the maximum le size is 32 MB.
Administrators
The administrator enables the database upload policy for a speci c application via the cockpit. The policy identi es how much time
elapses before the uploaded database les are deleted automatically, and the maximum database le size that can be uploaded
(required only if greater than the default of 32 MB). Allow ample time for the developer to review the uploaded les.
Device Users
When prompted, an application user uploads a le from the device for analysis.
Developers (Troubleshoot)
The developer analyzes the database le to solve a problem encountered by the user. The le is deleted from the server when the policy
time limit has expired.
Exceptions When Working in a Clustered Server Environment

Keep a few things in mind when working in an clustered server environment.
In an SAP Mobile Platform Server cluster, there is no distinction between master server and secondary server: all nodes are equal and
run independently. All nodes share the database. Updates performed in Management Cockpit on any of the nodes in the cluster are
saved to the database and therefore automatically synchronized to the other nodes in the cluster. However, there are some exceptions
to keep in mind when working in a clustered server environment.
You must perform any tasks that require updating les directly in the le system on each node in the cluster, such as server con guration
changes that update the props.ini le or changes to the keystore password that update the local_smp_keystore.jks le.
Updates to Agentry con guration les that are edited outside Management Cockpit and published to the server are not automatically
synchronized across the cluster. You must restart each server node for these changes to take effect.
Management Cockpit connects to one server node in the cluster. The following Management Cockpit activities apply only to the server
node host to which Management Cockpit is connected. Connect Management Cockpit to another node to perform the activity on that
server.
Managing server features – server features are enabled only for the node to which Management Cockpit is connected.
Viewing server log les – you can view server log les only for the node to which Management Cockpit is connected.
5/12/2023
Viewing Agentry log les – you can view Agentry log les only for the node to which Management Cockpit is connected.
Exporting applications – the exported application ZIP le is created only on the node to which Management Cockpit is connected.
Related Information
Cluster Security
Postinstallation Landscape Setup

After installing SAP Mobile Platform Server you need to perform postinstallation tasks before performing any server or application
administration tasks.
The postinstallation tasks you need to perform depend on the landscape you need to support:
Con gure reverse proxies and load balancers for managing in-bound application requests to SAP Mobile Platform Server.
Con gure communications between the server and your supported back end systems.
Set up communications between the server and the Apple Push Noti cation Service (APNS).
Set up the security landscape for the server.
Adding Reverse Proxies or Relay Servers

Once the installation of SAP Mobile Platform is complete, you can install and con gure a reverse proxy such as SAP Web
Dispatcher, or you can set up and con gure a Relay Server installation to work with it.
Setting Up Back-End Communications
Set up communications between SAP Mobile Platform Server and your back end. Back end refers to your data source, or
enterprise information system (EIS).
Adding a SOCKS Proxy or Load Balancer for APNS Connections
If you have a network-based proxy server between SAP Mobile Platform and your Internet connection to Apple Push Noti cation
Service (APNS), you can enable a path through network obstacles to the APNS servers by using either a SOCKS proxy in the
network proxy server, or a hardware load balancer in the DMZ.
Adding Reverse Proxies or Relay Servers

Once the installation of SAP Mobile Platform is complete, you can install and con gure a reverse proxy such as SAP Web Dispatcher, or
you can set up and con gure a Relay Server installation to work with it.
Prerequisites
Review the relevant planning topics in Landscape Planning and Design > Landscape Component Requirements before proceeding:
Common Requirements for Reverse Proxies
Common Requirements for Load Balancers
The reverse proxy and load balancer options that SAP Mobile Platform supports depend on the application type. For a complete list of
options that have been tested by SAP, see the SAP Product Availability Matrix (PAM) https://apps.support.sap.com/sap/support/pam
. Search for SAP Mobile Platform (search box in the upper-right corner), and select either SAP Mobile Platform 3.1 or SAP Mobile
Platform SDK 3.2.
 Note
Access to the PAM requires an SAP Service Marketplace login: http://service.sap.com/request-user
5/12/2023
Using Relay Server with SAP Mobile Platform
Components necessary to install Relay Server in IIS on a Windows server or Apache on a Linux server are installed automatically
with SAP Mobile Platform Server. You must install those components on Web servers before SAP Mobile Platform can work with
Relay Server .
Using Apache Reverse Proxy for HTTP Clients
For organizations that have HTTP clients that are designed to consume SAP Mobile Platform Server services, you may implement
an Apache reverse proxy in your production environment.
Con guring Apache as a Load Balancer for a Cluster
When you use Apache as a load balancer for an SAP Mobile Platform cluster....
Con guring Apache as a Load Balancer for the EIS Back End
When you use Apache as a load balancer for the EIS back end, the con guration le settings are different from those for Apache
as a load balancer on the front end.
Using Nginx Reverse Proxy for Agentry Clients
For organizations that have Agentry clients that are designed to consume SAP Mobile Platform Server services, you may
implement an Nginx reverse proxy in your production environment.
Using SAP Web Dispatcher with SAP Mobile Platform
SAP Web Dispatcher sits between the Internet and your SAP Mobile Platform system, intercepts client requests, and forwards
each request to SAP Mobile Platform Server.
Using Relay Server with SAP Mobile Platform

Components necessary to install Relay Server in IIS on a Windows server or Apache on a Linux server are installed automatically with
SAP Mobile Platform Server. You must install those components on Web servers before SAP Mobile Platform can work with Relay Server .
Prerequisites
The instructions in this section assume that:
A Relay Server installation is already in place in the same environment where SAP Mobile Platform is installed.
All SAP Mobile Platform Server cluster nodes are installed and running.
5/12/2023
The diagram above illustrates an SAP Mobile Platform cluster with two SAP Mobile Platform Server nodes, using two Relay Servers, with
Apache acting as a load balancer. This document focuses on this con guration, while providing information on what to do differently to
set up different con gurations, for example:
More than two Relay Servers
Hardware load balancer in place of Apache
Deploying Relay Server Components to Microsoft Windows Server

Con gure and deploy Relay Server les to each computer in the Relay Server farm.
Deploying Relay Server Components to Apache on Linux
Con gure and deploy Relay Server les to each computer in the Relay Server farm before running the Relay Server with Apache.
Con guring Relay Servers to Work with SAP Mobile Platform
Create a Relay Server con guration le that de nes the Relay Server farm, each Relay Server instance, and each SAP Mobile
Platform instance. Then copy that con guration le to each Relay Server in the farm.
Con guring Outbound Enablers to Work with SAP Mobile Platform Servers
Set up a Relay Server outbound enabler on each SAP Mobile Platform Server in the cluster.
Checking IIS Client Negotiation Certi cate Status for Mutual Authentication
To use mutual authentication with Relay Servers on IIS, the Negotiate Client Certi cate value for SSL certi cate status must be
enabled. To ensure that the Relay Server outbound enabler starts properly for mutual authentication, you must set this value on
each IIS server.
Con guring Apache Relay Server State Manager as a Service
Set up the State Manager process to run as a service on the Relay Server host.
Installing a Load Balancer in Front of a Relay Server Farm
You can use either a software or a hardware load balancer to get the best performance out of your Relay Servers.
Connecting to Relay Server at Runtime
After your Relay Servers have been installed and con gured, you can con gure an application to allow it to connect directly to the
Relay Server farm at runtime.
Deploying Relay Server Components to Microsoft Windows Server

Con gure and deploy Relay Server les to each computer in the Relay Server farm.
Prerequisites
Choose a deployment platform:
Windows Server 2008 (IIS 7.0 without WebSocket support for Agentry traffic)
Windows Server 2008 R2 (IIS 7.5 without WebSocket support for Agentry traffic)
Windows Server 2012 (IIS 8.0 with WebSocket support for Agentry traffic)
Windows Server 2012 R2 (IIS 8.5 with WebSocket support for Agentry traffic)
The Relay Server components are available in the SAP Mobile Platform Server installation. By default, the Relay Server les are located
in <SMP_HOME>\Server\extras\relayserver in a RelayServer2-IIS-<SMP_version>.zip le. Within that .zip le:
\Bin64 contains DLLs.
relayserver\IIS\bin64 contains rs.dll and the rs.config.sample con guration le.
Context
With the .zip, the \relayserver\IIS\iis7_plus_setup.bat quick setup script performs the following tasks:
1. Installs the supported version of IIS that is available and turns on the required features
5/12/2023
2. Con gures the installed IIS for the Relay Server
3. Creates a demo application
4. Generates a quick reference guide
Web Server administrators can customize the script as necessary.
The Relay Server for Windows consists of the following executables:
rs.dll (in RelayServer2-IIS-<SMP_version>.zip\relayserver\iis\bin64)
dblgen17.dll (in RelayServer2-IIS-<SMP_version>.zip\Bin64)
dbicu17.dll (in RelayServer2-IIS-<SMP_version>.zip\Bin64)
dbicudt17.dll (in RelayServer2-IIS-<SMP_version>.zip\Bin64)
Procedure
1. From any SAP Mobile Platform Server installation, copy the <SMP_HOME>\Server\extras\relayserver\RelayServer2-
IIS-<SMP_version>.zip to a computer where IIS has been set up to support Relay Server in your farm.
2. Extract the contents of the Server\extras\relayserver\RelayServer2-IIS-<SMP_version>.zip le to a folder on

that computer. Ensure the path does not contain any blank characters.
Instructions that follow use RSfiles to refer to this folder.
3. As an administrator, open a command prompt.
4. Set a temporary environment variable SQLANY17 to the RSfiles location.
5. Add RSfiles\bin64 to your SYSTEM path.
6. To enable Afaria applications, edit RSfiles\relayserver\iis\iis7_plus_setup.bat, and uncomment this line:
appcmd set config "%site_name%/%rs_vdir%/client" -section:system.webserver/serverruntime /uploadReadA
7. To con gure IIS, run RSfiles\relayserver\iis\iis7_plus_setup.bat.
8. Run C:\Windows\system32\iisreset.
9. Update the Relay Server con guration for Microsoft IIS on Windows:
a. For each computer that belongs to the Relay Server farm you are updating:
i. Copy the updated rs.config.sample con guration le (from RelayServer2-IIS-

<SMP_version>.zip\relayserver\iis\bin64) to the \RelayServer\IIS\Bin64\Server directory
under the Relay Server web site home directory.
ii. Rename rs.config.sample to rs.config.
iii. Edit rs.config to list your Relay Servers, backend farms, and backend servers.
10. Run net start w3svc to start the IIS Relay Server, net stop w3svc to stop it.
The Relay Server log le is created under RSfiles\\relayserver\iis\bin64\Log.
11. Test if the Relay Server is running and the farm is available.
In a Web browser, check the Relay Server status using the following URL:
http://localhost/rs17/client/rs.dll/<<farmId>>
Next Steps
To perform Relay Server administration, edit rs.config and then restart w3svc.
Deploying Relay Server Components to Apache on Linux

Con gure and deploy Relay Server les to each computer in the Relay Server farm before running the Relay Server with Apache.
5/12/2023
Prerequisites
The SAP Mobile Platform Server installation includes Relay Server components. Relay Server les are installed to
<SMP_HOME>/Server/extras/relayserver in a RelayServer-Linux-<SMP_version>.gz le.
Context
 Note
The interactive quick setup feature con gures the Apache web server for Relay Server and is an alternative to this procedure. Run the
ap-setup.sh script in the /relayserver/quicksetup_apache directory.
Relay Server for Apache consists of the following executables:
mod_rs_ap_client.so
mod_rs_ap_server.so
rshost
dblgen16.res
libdbtasks16.so
libdbtasks16_r.so
libdbicudt16.so
libdbicu16_r.so
mod_rs_ap_admin.so
Procedure
1. Create the Relay Server con guration le rs.config.
2. Copy rs.config into the <install-dir> /relayserver/apache??/bin64 directory. ?? is 22 for Apache 2.2.x and 24 for Apache
2.4.x.
3. Edit the Relay Server con guration le rs.config using the following guidelines.
The le has four sections, and each section starts with a section tag that is enclosed in square brackets:
Relay server section
Backend farm section
Backend server section
Options section
Add the appropriate properties to each section. De ne each property as a keyword=value pair.
The con guration le only supports 7-bit ASCII characters.
4. Add the following directories to the LD_LIBRARY_PATH environment variable:
<install-dir>/lib64
<install-dir>/relayserver/apache??/bin64
Edit the /<<apache-dir>>/bin/envvars le to set and then export LD_LIBRARY_PATH.
5. Source /<<apache-dir>>/bin/envvars before running client- or server-facing Apache instances.
6. Con gure the server-facing Apache instance:
a. Copy the Apache conf/httpd.conf le and name the copy httpd.conf.server.
b. For Apache 2.4, add the lines below to support 200 clients going through the Apache Linux Relay Server, with two outbound
enablers in the back end using default JSL and JSH settings. See Apache documentation for more information on these
settings.
5/12/2023
ThreadsPerChild 150
ThreadLimit 150
MaxRequestWorkers 2400
MinSpareThreads 450
c. Add the following line to conf/httpd.conf.server to load the Relay Server server module:
LoadModule iarelayserver_server_module <install-dir>/relayserver/apache??/bin64/mod_rs_ap_serve
 Note
All modules are invoked using different URLs and all modules explicitly look for the string iarelayserver in the URL
path. That part of the URL need not change.
d. Add the following line to load the Remote Administration support module:
LoadModule iarelayserver_admin_module <install-dir>/relayserver/apache??/bin64/mod_rs_ap_admin.
 Note
The Remote Administration module con guration is optional. It can reside in the server- or client-facing con guration
le.
e. Add the following lines to create a <LocationMatch> section for the server module:
<LocationMatch /srv/iarelayserver/* >

SetHandler iarelayserver-server-handler
"/<install-dir>/relayserver/apache??/bin64/rs.config"
</LocationMatch>
f. Add the following lines to create a <LocationMatch> section for the Remote Administration module:
<LocationMatch /admin/iarelayserver/* >

SetHandler iarelayserver-admin-handler
</LocationMatch>
g. Update the Listen directive and ensure the server instance listens on a different port or adapter than the client instance.
This port must also be accessible to the computer running the Outbound Enabler.
h. Update the ErrorLog directive and change the name of the error log le so that the server-facing instance logs to a
separate le.
i. Update the CustomLog directive and change the name of the access log le so that the server-facing instance logs to a
separate le.
j. Add a PidFile directive so that the client pid le and server pid le cannot overwrite each other. For example:
PidFile "logs/httpd_server.pid"
k. If Apache is set up for HTTPS, make another copy of conf/extra/httpd-ssl.conf (for example httpd-
ssl.conf.server) and change the SSL listening port. If both Apache instances include the same le, a socket bind error
occurs on the Apache instance that is started second.
l. Set the Timeout directive to 60 seconds. The Timeout value must be greater than both the max_junction_idle_sec value
and the value expected in the application's timeout logic.
m. Disable the Apache reqtimeout_module.
7. Con gure the client-facing Apache instance.
a. Edit the Apache conf/httpd.conf le.
b. Add the following line to load the Relay Server client module:
LoadModule iarelayserver_client_module <install-dir>/relayserver/apache??/bin64/mod_rs_ap_clien
c. For Apache 2.4, add the lines below to support 200 client requests. See Apache documentation for more information on
these settings.
ThreadsPerChild 75
ThreadLimit 75
MaxRequestWorkers 1200
5/12/2023
MinSpareThreads 200
d. Add the following lines to create a <LocationMatch> section for the client module:
<LocationMatch /cli/iarelayserver/* >

SetHandler iarelayserver-client-handler
</LocationMatch>
e. Set the Timeout directive to 60 seconds. The Timeout value must be greater than the value expected in the application's
timeout logic.
8. On Linux, if the $TMP, $TMPDIR, or $TEMP environment variable is set globally when Apache spawns a process, then Apache
con guration is complete.
If any of the above environment variables are not set globally, or if you want to place the default Relay Server log le in a speci c
temporary directory, then edit the le /<<apache-dir>>/bin/envvars to set and then export $TMP.
If you start Apache by using the httpd command line directly, then source /<<apache-dir>>/bin/envvars rst.
For example, to edit the location of $TMP in the envvars le, do the following:
set TMP="/tmp"
export TMP
 Note
The Apache user process requires write permissions to the speci ed tmp directory.
This environment variable is set in the shell that Apache creates before it spawns its processes.
9. To update the Relay Server con guration while it is started:
a. Copy the updated con guration le to <install-dir>/relayserver/apache??/bin64.
Where "??" is 22 for Apache 2.2, or "24" for Apache 2.4.
b. From the <install-dir>/relayserver/apache??/bin64 directory, run the following command line to apply the
con guration update:
rshost -u -f rs.config
c. If the Relay Server is set up as a farm with more than one server, repeat the previous steps for each computer in the Relay
Server farm.
10. Test if the Relay Server is running and the farm is available.
In a Web browser, check the Relay Server status using the following URL:
http://localhost/cli/iarelayserver/<<farmId>>
Results
The Relay Server is up and running with Relay Server farms in rs.config connected to all back-end servers. You can check the rs.log
le to verify that Relay Server is started properly and to get other information on its operation.
Next Steps
Perform Relay Server administration using the following URL: http://localhost/admin/iarelayserver .
Concurrent Connections
The Apache Web server controls concurrent connections (simultaneous requests) using the MaxClient directive. To enable an Apache
Web server to handle more than 256 concurrent connections, update the value of MaxClient in the httpd.conf le.
If more than 256 concurrent connections are established with the Apache Web server, connections over the 256 limit are queued,
typically based on the value of the ListenBacklog directive. If you increase the value of MaxClient, you must also increase the value
5/12/2023
of the ServerLimit directive to the number of Apache processes in the Web server. By default, MaxClient is set to 256;
ListenBacklog is set to 511.
 Note
This applies ONLY to Relay Server versions 12.0.x and higher on an Apache Web server.
Relay Server versions 12.0.x and higher incorporate a semaphore manager to manage semaphore use by the Relay Server. If you change
the values of MaxClient and ServerLimit, you need not increase the "semaphore sets" in the system.
To increase the number of concurrent connections, add the following lines to httpd.conf:
ServerLimit 1000
MaxClient 1000
Other Apache directives that you can adjust for busy Web servers include:
MaxSpareServers
MinSpareServers
StartServers
Con guring Relay Servers to Work with SAP Mobile Platform

Create a Relay Server con guration le that de nes the Relay Server farm, each Relay Server instance, and each SAP Mobile Platform
instance. Then copy that con guration le to each Relay Server in the farm.
Context
The Relay Server con guration le provides the information that each Relay Server instance needs to communicate with each SAP
Mobile Platform node. There must be a Relay Server outbound enabler on each SAP Mobile Platform node to receive the
communications.
Procedure
1. On one of the Relay Server nodes., use a text editor to open the Relay Server con guration le.
These instructions use rs.config as the Relay Server con guration le.
 Note
For Windows, the le must be named rs.config. For Apache, the le may have a different name in your Relay Server
installation.
2. Edit rs.config to add sections like those shown in the sample below.
Your rs.config le may already have many of the lines shown below. Create any sections that do not exist. In the sections
indicated, replace the variables with appropriate values for your environment. Comments (lines beginning with "#") provide
guidance for editing your rs.config le; you need not include them.
Notes:
host: Enter the host name or IP address of the Relay Server.
http_port and https_port values are Relay Server defaults; replace them with the port numbers that are actually
used, if different.
max_junction_idle_sec must be set to less than the connection timeout value con gured for the SAP Mobile
Platform Server.
#--------------------
# Relay server peers
5/12/2023
#--------------------
[relay_server]
enable = yes
host = <host1_name_or_IPaddress>
http_port = 80
https_port = 443
description = <unique_descriptive_text>
[relay_server]
enable = yes
host = <host2_name_or_IPaddress>
http_port = 80
https_port = 443
description = <unique_descriptive_text>
#---------------
# Backend farms
#---------------
[backend_farm]
enable = yes
verbosity = 4
id = <backend_RSfarm_ID>
description = <backend_RSfarm_description>
#-----------------
# Backend servers
#-----------------
[backend_server]
enable = yes
farm = <backend_RSfarm_ID>
id = <outbound_enabler1_ID>
token = MBS
max_junction_idle_sec = <15>
[backend_server]
enable = yes
token = MBS
3. Deploy the updated rs.config le to all other Relay Server nodes.
a. (Windows only) Place the new rs.config in the same directory as rs.dll.
b. To update an existing Relay Server with the new con guration:
On Windows, enter these commands to stop and restart IIS:
i. net stop w3svc
ii. net start w3svc
On Linux, run:
rshost –u –f <Path>\rs.config
Relay Server Con guration File Reference

A Relay Server con guration le de nes properties for a Relay Server farm and the backend server farms connecting to that Relay
Server farm.
The Relay Server con guration le is divided into the following sections: Relay Server, backend farm, backend server, and options.
Each section starts with a section tag. A section tag is formed by enclosing a keyword that identi es the section name in square brackets.
For example, [relay_server] denotes the start of the Relay Server section.
The section tag is followed by several lines de ning various properties related to the section being de ned. A property is de ned by
specifying the property name on the left side of an equal sign and its value on the right side of the equal sign. For example, <property
name >= <value>. All section and property names are case insensitive. Comments are marked with a pound sign (#) character at the
beginning of a line.
5/12/2023
The con guration le supports only 7-bit ASCII characters. You can specify the sections in any order.
The File Hiding utility (dbfhide) uses encryption to hide the contents of con guration les and initialization les. The Relay Server and
Outbound Enabler detect that a con guration le has been obfuscated by using dbfhide and process it.
Example Relay Server con guration le

This following Relay Server con guration le de nines a Relay Server farm with two Relay Servers, four backend farms, and ve backend
servers.
# Relay Servers:
# rs1.rs.com
# rs2.rs.com
#
# Assume the load balanced address of the Relay Server farm is www.rs.com.
#
# Backend farms and servers and their corresponding rsoe commandlines:
# Company1.Sales.MLFarm
# MLServer01 rsoe.exe -cr host=www.rs.com -f Company1.Sales.MLFarm -id MLServer01 -t 7b2493b0-d0
# MLServer02 rsoe.exe -cr host=www.rs.com -f Company1.Sales.MLFarm -id MLServer02 -t de1aac83-a6
# Company1.Manufacturing.MLFarm
# MLServer01 rsoe.exe -cr host=www.rs.com -f Company1.Manufacturing.MLFarm -id MLServer01 -t 621
# Company2.AFFarm
# AFServer01 rsoe.exe -cr host=www.rs.com -f Company2.AFFarm -id AFServer01 -t a688728f-1ae7-443
# Company2.SAPFarm
# SAPG1 rsoe.exe -cr host=www.rs.com -f Company2.SAPFarm -id SAPG1 -t de68b75b-ff33-4c81-a9
#
# Note: The two instances of MobiLinkServer01 are different servers.
#
# The Relay Server configuration file contains authentication information.
# Access to this file must be administered.
#
# URL prefix for client applications:
# https://www.rs.com/ias_relay_server/client/rs_client.dll/Company1.Sales.MLFarm
# https://www.rs.com/ias_relay_server/client/rs_client.dll/Company1.Manufacturing.MLFarm
# https://www.rs.com/ias_relay_server/client/rs_client.dll/Company2.AFFarm
# https://www.rs.com/ias_relay_server/client/rs_client.dll/Company2.SAPFarm
#
#-------------------------------------
# Relay Server options
#-------------------------------------
[options]
verbosity = 1
#--------------------
# Relay Server peers
#--------------------
[relay_server]
enable = yes
host = rs1.rs.com
http_port = 80
https_port = 443
description = Machine #1 in RS farm
[relay_server]
enable = yes
host = rs2.rs.com
http_port = 80
https_port = 443
description = Machine #2 in RS farm
#---------------
# Backend farms
#---------------
[backend_farm]
id = Company1.Sales.MLFarm
[backend_farm]
enable = yes
verbosity = 4
id = Company1.Manufacturing.MLFarm
description = Company1's MobiLink farm in their Manufacturing department
[backend_farm]
5/12/2023
enable = yes
id = Company2.AFFarm
description = Company2's Afaria farm
[backend_farm]
enable = yes
id = Company2.SAPFarm
forward_x509_identity= yes
forwarder_certificate_subject= CN = \*.mysap.com, *
forwarder_certificate_issuer= CN = ca??.mysap.com, *
description = Company2's SAP Gateway farm
#-----------------
# Backend servers
#-----------------
[backend_server]
farm = Company1.Sales.MLFarm
id = MLServer01
[backend_server]
farm = Company1.Sales.MLFarm
id = MLServer02
[backend_server]
enable = no
farm = Company1.Manufacturing.MLFarm
verbosity= inherit
mac = 01-23-45-67-89-ad
id = MLServer01
token = 621ece03-9246-4da7-99e3-c07c7599031c
description= ML server number 1
[backend_server]
enable = yes
farm = Company2.AFFarm
id = AFServer01
mac = 01-23-45-67-89-ae
token = a688728f-1ae7-4438-969e-6f5e30a07882
[backend_server]
enable = yes
farm = Company2.SAPFarm
id = SAPG1
mac = 01-23-45-67-89-af
token = de68b75b-ff33-4c81-a920-2333494dfd8a
Relay Server Section

The Relay Server section of the Relay Server con guration le de nes the properties for a single Relay Server.
Include a Relay Server section (relay_server keyword) for each Relay Server in the farm.
Property Description
enable (Optional) Speci es whether this Relay Server is included in the Relay Server farm.
yes
(Default) Indicates that this Relay Server is to be included in the Relay Server farm.
no
Indicates that this Relay Server should not be included in the Relay Server farm.
host Speci es the host name or IP address that the Outbound Enabler uses to make a direct
connection to the Relay Server.
5/12/2023
http_port Speci es the HTTP port that the Outbound Enabler uses to make a direct connection to the Relay
Server. A value of 0 or off disables HTTP connections. By default, this property is enabled and
set to 80.
0 or off
Disable HTTP access from the Outbound Enabler.
1 to 65535
Enable HTTP at the speci ed port.
https_port Speci es the HTTPS port that the Outbound Enabler uses to make a direct connection to the
Relay Server. A value of 0 or off disables HTTPS connections. By default, this property is enabled
and set to 443.
0 or off
Disable HTTPS access from Outbound Enabler.
1 to 65535
Enable HTTPS at the speci ed port.
description (Optional) Speci es a custom description of up to 2048 characters.
Backend Server Section

The backend server section de nes the properties of a backend server connection that the Outbound Enabler uses when it connects to
the Relay Server farm on behalf of a backend server.
There is a backend server section for each Outbound Enabler that connects to the Relay Server farm. Each Backend server section is
identi ed by the backend_server keyword. The backend server section also assigns a backend server to a backend server farm.
The Relay Server supports the following backend servers:
SAP Afaria
Mobile Office
MobiLink
SAP Mobile Platform
SQL Anywhere
enable (Optional) Speci es whether to allow connections from this backend server.
yes
(Default) Allows connections from this backend server.
no
Disallows connections from this backend server.
farm Speci es the name of the backend server farm that this backend server belongs to.
id Speci es the name for that the backend server connection up to 2048 characters.
5/12/2023
MAC (Optional) Speci es the MAC address of the network adapter that the Outbound Enabler uses to
communicate with the Relay Server. Use the IEEE 802 MAC-48 format to specify the address. To
determine the correct format for the MAC address, look in the Relay Server Outbound Enabler
console or log. If the property is not speci ed, then the MAC address is not checked.
max_junction Sets the maximum number of active and idle junctions that are available to the Relay Server. This
setting overrides the -jl option for rsoe2. The default value for this option is 1,000.
max_junction_idle_sec Controls the how long junctions can remain inactive before the Outbound Enabler discards them.
The Outbound Enabler automatically replenishes the idle junction pool if its size falls below the
spare junction low watermark that the -jsl option controls. The default value is 30.
token (Optional) A security token of up to 2048 characters that the Relay Server uses to authenticate
the backend server connection.
verbosity Speci es the verbosity level.

0
Log errors only. Use this logging level for deployment. This is the default.
Request logging. All HTTP requests are written to the Relay Server log le.
Request logging. Provides a more detailed view of HTTP requests.
3 or higher
Detailed logging. Used primarily for Technical Support.
Errors are displayed regardless of the log level speci ed, and warnings are displayed only if the
log level is greater than 0.
Backend Farm Section

The backend farm section speci es the properties of a backend server farm (a group of homogeneous backend servers).
A client making a request through the Relay Server farm must specify the backend server farm it is targeting. There is one backend farm
section for each backend server farm. Each section is identi ed by the backend_farm keyword.
enable (Optional) Speci es whether to allow connections from this backend server farm.
yes
(Default) Allow connections from this backend server farm.
no
Disallow connections from this backend server farm.
forward_x509_identity Controls how the SAP NetWeaver Gateway authenticates clients. One way is through X.509 certi cate forwarding throu
yes, the Relay Server can extract forwarded client identity information from a trusted forwarder and forward it to the S
HTTP headers. The default setting is no.
5/12/2023
forwarder_certi cate_issue Controls how client identity headers are treated. When a chain of SAP intermediaries exists, the client identity headers
all clients may be granted permission to act as forwarders. The default behavior is to replace the existing headers wit
forwarder to forward other client identities, set forwarder_certi cate_issuer=<match-string> and forwarder_certi cat
checked against a serialized form of the corresponding compound name eld in the certi cate. Use ? to match any ch
escape character for ?, *, or \ to match them literally. For example:
forwarder_certificate_issuer = 'CN = quicksigner, OU = security department, O = my org, L
forwarder_certi cate_subject UNDER CONSTRUCTION. In the case where a chain of SAP intermediaries exists, the client identity headers may alrea
may be granted permission to act as forwarders. The default behavior is to replace the existing headers with the ident
to forward other client identities, set forwarder_certi cate_issuer=<match-string> and forwarder_certi cate_subject
against a serialized form of the corresponding compound name eld in the certi cate. Use ? to match any character a
character for ?, *, or \ to match them literally. For example:
forwarder_certificate_subject = 'CN = mySapWD??.my.com, OU = SEC, O = SAP, *'
id Speci es the name up to 2048 characters for the backend server farm.
inject_affinity_query_header (Optional) Provides backward compatibility with the Afaria Open Mobile Alliance Device Management (OM ADM) back
yes
Provides backward compatibility.
no
(Default) Does not provide backward compatibility.
If no value is speci ed, then you can connect by using HTTP or HTTPS.
token (Optional) A security token of up to 2048 characters that the Relay Server uses to authenticate the backend server con
verbosity Sets the verbosity for the backend farm.
(Default) Log errors only. Use this logging level for deployment.
3 or higher
Errors are displayed regardless of the log level speci ed, and warnings are displayed only if the log level is greater tha
Options Section
The Options section of the Relay Server con guration le speci es the properties that apply to each Relay Server in the farm.
The Relay Server con guration le supports only one Options section. It is identi ed by the options keyword.
auto_con g Con gures the Relay Server so that Outbound Enablers can connect by using the token of unseen backend farms and backend servers
log_size_limit Sets the maximum size of the Relay Server log le. The supported units are: k, K, m, M, g, and G. The default value is 0 (no limit).
(Windows
only)
5/12/2023
min_thread Speci es the minimum number of threads to allocate to the thread pool. The default setting is auto: threads are not returned to the id
(Windows
only)
max_thread Speci es the maximum number of threads to allocate to the thread pool. The default setting is auto: the Relay Server does not limit th
(Windows the idle pool, then the Relay Server allocates new threads up to the thread limit of 65,535. max_thread must be greater than min_thre
only)
To exceed 5,000 concurrent requests for IIS7, use the following con guration:
%systemroot%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/serv
For max_thread to work as a soft limit, set <new-limit> higher than max_thread.
shared_mem (Optional) Speci es the maximum amount of shared memory that the Relay Server uses for state tracking. The default value is 10 MB
(Linux only) conditions occurs:
Improved speed in the network between the Relay Server and the Outbound Enabler
Signi cant growth in the number of backend farms
Signi cant growth in the size of the backend farm
Signi cant growth in the number of clients
Signi cant growth in HTTP response size
Addition of slower clients or slower networks
verbosity Speci es the verbosity level:
(Default) Log errors only. Use this logging level for deployment.
3 or higher
Errors are displayed regardless of the log level speci ed, and warnings are displayed only if the log level is greater than 0.
Automatic Con guration of the Relay Server

The auto_con g option sets default property values for the backend server and backend farm. When the auto_con g option is set to on,
the Relay Server runs as a trust on rst use (TOFU) system. Automatic con guration is useful for testing purposes and for
administration-free environments.
Outbound Enablers connect with unseen backend farms and backend servers. Outbound Enablers that belong to the same backend farm
connect by using a farm-wide token. To reserve the farm name before the Relay Server starts, specify it with the token property in the
backend_farm section of the Relay Server con guration le.
When the Relay Server processes the rst Outbound Enabler connection that has an unseen farm name, a new backend farm
con guration is created. The Relay Server updates the original con guration le and stores the supplied token in a new backend farm
property. Other backend farm properties are initialized to default values. The automatically con gured farm settings persist when the
Relay Server is restarted. The backend server con guration also persists per Outbound Enabler, with a unique server token for the
backend farm. All Outbound Enablers that belong to the same automatically con gured farm must supply a token that matches the farm-
wide token; otherwise, access is denied.
5/12/2023
When you use automatic con guration, you can still change backend farm and backend server settings. To make changes, use rshost
locally for Apache or AdminChannel IIS or Apache.
File Hiding Utility (dbfhide)

The File Hiding utility (dbfhide) uses encryption to hide the contents of con guration les and initialization les.
 Syntax
dbfhide <original-configuration-file> <encrypted-configuration-file>
Option Description
<original-con guration- le> Speci es the name of the original le.
<encrypted-con guration- le> Speci es a name for the new obfuscated le.
The Relay Server and Outbound Enabler detect that a con guration le has been obfuscated by using dbfhide and process it.
Example
UNDER CONSTRUCTION
Con guring Relay Server for HTTPs with SAP Mobile Platform
Con gure Relay Server for HTTPS and mutual athentication with SAP Mobile Platform.
Prerequisites
Relay Server components have been deployed to your selected platform.
IIS is installed.
Context
This procedure assumes the use of Relay Server version 17 or later, and SAP Mobile Platform version 3.0 or later.
Procedure
1. Install an SSL Certi cate on IIS and bind the certi cate to a website's HTTPS port and IP address.
2. Con gure the Relay Server website for HTTPS.
a. In IIS, open IIS Manager and navigate to the level you want to manage.
b. Select the Relay Server site, and then in the Features View, double-click SSL Settings.
c. On the SSL Settings page, select Require SSL.
d. On the SSL Settings page, in the Client certi cates area, select Accept.
e. In the Actions pane, click Apply.
3. Check the IIS client negotiation certi cate status.
a. From a command line, run the following command to check the SSL certi cate status:
C:\>netsh http show sslcert
5/12/2023
SSL Certificate bindings:

-------------------------
IP:port : 0.0.0.0:443
Certificate Hash : e3564c44a14c163e0fe7617ab1d54202774b4804
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
b. If Negotiate Client Certi cate is disabled, delete the entry for HTTPs. For example:
C:\>netsh http delete sslcert 0.0.0.0:443
SSL Certificate successfully deleted
c. Manually add it back and change Negotiate Client Certi cate to enabled. Without this step, RSOE cannot start properly for
mutual SSL. For example:
C:\Users\RelayServer\Desktop>netsh http add sslcert 0.0.0.0:443

e3564c44a14c163e0fe7617ab1d54202774b4804 {4dc3e181-e14b-4a21-b022-59fc669b0914}
clientcertnegotiation=enable
SSL Certificate successfully added
d. Check the status again.
C:\>netsh http show sslcert
C:\Users\RelayServer\Desktop>netsh http show sslcert

-------------------------
IP:port : 0.0.0.0:443
Certificate Hash : e3564c44a14c163e0fe7617ab1d54202774b4804
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : (null)
Negotiate Client Certificate : Enabled
Negotiate Client Certi cate should now be enabled.
4. Con gure the Relay Server.
a. Open rs.config from the Relay Server folder, and add your back-end farm and back-end server. For example:
#-------------------------
# Backend farm - backend_RSfarm_ID, for mutual SSL testing
#-------------------------
[backend_farm]
enable = yes
5/12/2023
id = <backend_RSfarm_ID>
forward_x509_identity= yes
#---------------------------
# Backend servers -
#---------------------------
[backend_server]
token = <621ece03-9246-4da7-99e3-c07c7599031c>
b. Save the rs.config le and restart the Relay Server. Check rs.log to ensure the farm and backend are valid.
c. In order to test HTTPS and mutual SSL authentication, you need to import all other trusted certi cates to the proper
certi cate store of the Relay Server machine and restart IIS.
5. Import Relay Server certi cates into SAP Mobile Platform Server. In Management Cockpit, select Settings Certi cates and
import the Shared KeyStore Entries for the correct alias.
6. Create an Application ID with Mutual Auth for mutual authentication testing.
7. Specify the back-end connection.
8. Specify x.509 User Certi cate for authentication.
9. Role mapping is required for mutual authentication.
a. From Management Cockpit, select Settings Security Pro les .
b. Select a security pro le and click Role Mapping.
c. On the Security Pro le page, click Impersonator.
d. Click Browse to import the Relay Server certi cate.
e. Click Add to add it as an available role and then select it and add to Mapped Role.
f. Click Save.
10. In order to connect to Relay Server with mutual SSL authentication, you need to create an rsoe con guration le that is similar to
the following, and then start the RSOE process.
-id outbound_enabler1_ID -f backend_RSfarm_ID -t smp3mutual-1 "host=cnpvglwssc1060.apj.global.corp.sa

-cs "host=cnpvglwssc856.apj.global.corp.sap;https=1;port=8082;skip_certificate_name_check=ON;trusted_
trusted_certi cates A le containing a list of trusted root certi cates. To verify the back-end server, and only the back-end
server, set this property to backend_server_public_cert_ lename. For example,
trusted_certificates=backend_server_public_cert_filename
identity Provides the credentials to establish mutually-authenticated TLS between the Outbound Enabler and the back end
server. Note that mutual authentication is required for the back-end server.
identity_password Provides the credentials to establish mutually-authenticated TLS between the Outbound Enabler and
the back-end server. Note that mutual authentication is required for the back-end server.
skip_certi cate_name_check Controls whether the host name of the database server matches any of the host names in
the root certi cate. Enabling this option may prevent the client from fully authenticating the server, leaving it vulnerable to
attack.
11. Con gure your device client for 2-way HTTPS (Mutual HTTPS) Channel.
Con guring Outbound Enablers to Work with SAP Mobile Platform

Servers
Set up a Relay Server outbound enabler on each SAP Mobile Platform Server in the cluster.
Context
The outbound enabler connects an SAP Mobile Platform Server that is running in the corporate LAN to the Relay Server farm that is
running in the DMZ.
Procedure
5/12/2023
1. In the SAP Mobile Platform Server installation tree, locate the dbsvc utility executable (dbsvc.exe on Windows, dbsvc on Linux).
Windows – <SMP_HOME>\Server\db\sa\smp3\win32\Bin64\dbsvc.exe.
Linux – <SMP_HOME>/Server/extras/rsoe/linux/RSOE2-Linux-16.5.3.1685m.gz; dbsvc is in the /bin64

folder in the .tar le within the .gz le.
2. Set a temporary environment variable SQLANY16 to the rsoe location.
3. Run the Relay Server's Service utility to set up each outbound enabler to start automatically as a service.
To set up an auto-started outbound enabler service named oes on IIS host on Windows using the command line, enter:
dbsvc -as -s auto -w oes "%SQLANY16%\rsoe2.exe" -t rsoe2

-cr "host=<host_name_or_IPaddress>; port=<host_port>;
url_suffix=/rs16.5/server/rs.dll"
-cs "host=localhost;port=80"
-f <farm_name> -id <server_name>
To set up an auto-started outbound enabler service named oes on IIS host on Windows specifying the outbound enabler
parameters in a command le, enter:
dbsvc -as -s auto -w oes "%SQLANY16%\rsoe2.exe" @%SQLANY16%\oe.config
//Sample oe.config file

-v <verbosity>
-t rsoe2
-cr "host=<host_name_or_IPaddress>; port=<host_port>; url_suffix=/rs16.5/server/rs.dll"
-cs "host=localhost;port=80"
-f <farm_name>
-id <server_name>
-o <your path>\rsoe2.log
-os 10MB
To set up an auto-started outbound enabler service named oes on an Apache host on Linux, enter:
dbsvc -y -a <Apache-user-account> -t rsoe2 -w oes @/<full-dir-path>/oe.config
4. On either Windows or Linux, you can enter parameters into an outbound enabler con guration le, using the same syntax as at
the command prompt.
Parameters for Configuration File
rsoe2 Option Description
5/12/2023
-cr " Speci es the Relay Server connection string. The format of the Relay Server connection string is a list of name-value pairs, se
<connection- pairs consist of the following:
string>" host – IP address or host name of the Relay Server.
port – port on which the Relay Server is listening.
url_suffix – (required) URL path to the server extension of the Relay Server. By default, you must specify the url_
http_userid – (optional) user ID for authentication. Consult your Web server (or proxy) documentation to determin
http_password – (optional) password for authentication. Consult your Web server (or proxy) documentation to det
authentication.
http_proxy_userid – (optional) user ID for proxy authentication. Consult your Web server (or proxy) documentati
authentication.
http_proxy_password – (optional) password for proxy authentication. Consult your Web server (or proxy) docum
HTTP authentication.
proxy_host – (optional) host name or IP address of the proxy server.
proxy_port – (optional) port number of the proxy server.
https – 0 - HTTP (default), 1 - HTTPS.
By default, MobiLink starts the TCPIP communication protocol. When starting MobiLink for use with the Relay Server
communication protocol that is required by your outbound enabler con guration. For example, if you specify HTTPS a
MobiLink with HTTPS.
When the https=1 parameter is included in the -cs option, the default port changes to 443.
For https=1, you can also specify the following options:
tls_type – (optional, Relay Server 12 only) RSA or ECC. Relay Server 16 uses RSA only.
certificate_name – (optional) common name eld of the certi cate.
certificate_company – (optional) organization name eld of the certi cate.
certificate_unit – (optional) organization unit eld of the certi cate.
identity – (optional) provides the credentials to establish mutually authenticated TLS between the outbou
Mutual authentication is required for the back-end server.
identity_password – (optional) provides the credentials to establish mutually authenticated TLS betwee
end server. Mutual authentication is required for the back-end server.
fips – (optional) yes or no.
trusted_certificates – (optional) a le containing a list of trusted root certi cates. To verify the back-e
set this property to <backend_server_public_cert_ lename>.
trusted_certificates=<backend_server_public_cert_filename>
For Windows, if trusted_certificate is not set, the operating system certi cate store is used.
5/12/2023
-cs " The SAP Mobile Platform Server (back-end server) connection string. Sets the host and port that is used to connect to the bac
<connection- "host=localhost;port=80;https=0". To enable periodic back-end server status requests, add the status_url par
string>" parameter is speci ed in the format status_url=/<your-status-url>. The following example shows how to specify s
-cs "host=localhost;port=80;status_url=/getstatus/"
Use the -d option to specify the frequency of the back-end server status requests.
host – (optional) IP address or hostname of the SAP Mobile Platform Server (back-end server). Default is localhost.
port – (required) port number on which the back-end server is listening. Default is 0.
https – (optional) 0 = HTTP (default); 1 = HTTPS.
By default, MobiLink starts the TCPIP communication protocol. When starting MobiLink for use with the outbound ena
that is required by your outbound enabler con guration. For example, if you specify HTTPS as the back-end security,
When the https=1 parameter is included in the -cs option, the default port changes to 443.
For https=1, you can also specify the following options:
identity – (optional) path and le name of the identity le that is to be used for server authentication. Prov
mutually authenticated TLS between the outbound enabler and the back-end server. Mutual authentication is r
identity_password – (optional) password for the identity le. When this option is speci ed, the identity o
the credentials to establish mutually authenticated TLS between the outbound enabler and the back-end serv
the back-end server.
trusted_certificates – (optional) a le containing a list of trusted root certi cates. To verify the back-e
set this property to the name of the back-end server public certi cate le:
trusted_certificates=<backend_server_public_cert_filename>
On Windows, if trusted_certi cates is not set, the operating system certi cate store is used.
status_url – (optional) enables back-end status requests. Use the -d option to specify how often to ping the back
accessible. You can set this option in the outbound enabler con guration le, for example:
-cs "host=localhost;port=80;status_url=/getstatus/
If status_url is speci ed, the outbound enabler sends a simple HTTP GET request as follows:
GET /<your-status-url> HTTP/1.1\r\n Host: localhost:80\r\n User-Agent: IAS_OE_BE_Status\
The outbound enabler parses the back-end server's HTTP response and looks for AVAILABLE =<accept-value> in the
<accept-value> is one of: TRUE, FALSE, T, F, YES, NO, Y, N, ON, OFF, 1, or 0. If the outbound enabler receives AVAILAB
that the back-end server cannot accept more client requests, and terminates its channels to the Relay Server. If the ou
AVAILABLE=TRUE|T|YES|Y|ON|1, it reestablishes its channels with the Relay Server and resumes sending client requ
-d <seconds> (Optional) Frequency of the back-end server aliveness ping and back-end server status request. The default is 5 seconds.
-dl (Optional) Displays log messages in the Relay Server Outbound Enabler console. By default, log messages do not appear for
-f <farm> Name of the farm to which the back-end server belongs.
-id <id> Name assigned to the back-end server.
-o < le> (Optional) The le in which to log output messages.
-oq (Optional) Prevents the appearance of the error window when a start-up error occurs.
-os (Optional) Sets the maximum size of the message log les. The minimum size limit is 10 KB.
-ot (Optional) Truncates the log le and logs messages to it.
-q (Optional) Run with a minimized window on start-up.
5/12/2023
-qc (Optional) Shuts down the window on completion.
-s (Optional) Stops the outbound enabler.
-t <token> (Optional) Sets the security token to be passed to the Relay Server.
-uc (Optional) Starts the rsoe2 in shell mode. This is the default. Applies to Linux and Mac OS X. Specify only one of -uc, -ui, -um
the rsoe2 in the same manner as in earlier releases.
-ud (Optional) Runs the rsoe2 as a daemon. Applies to Linux platforms only.
-ui (Optional) Starts the rsoe2 in shell mode if a usable display is not available. This option is for Linux with X window server sup
When -ui is speci ed, the server attempts to nd a usable display. If it cannot nd one, for example because the X window se
shell mode.
-ux (Optional) For Linux, opens the rsoe2 messages window.
When -ux is speci ed, the rsoe2 must be able to nd a usable display. If it cannot nd one, for example because the DISPLAY
because the X window server is not running, the rsoe2 fails to start.
To run the rsoe2 messages window in quiet mode, use -q.
On Windows, the rsoe2 messages window appears automatically.
-v <level> (Optional) Set the verbosity level for logging. The level can be 0, 1, 2, or higher (higher levels are used primarily for technical s
0 – error logging. Use this logging level for deployment.
1 – session level logging. This is a higher level view of a synchronization session.
2 – request level logging. Provides a more detailed view of HTTP requests.
3 or higher – detailed logging. Used primarily for technical support.
Levels 1 and 2 are only written to the log le. To display all log messages, use the -dl switch.
Relay Server Outbound Enabler Command (rsoe2) Reference

The rsoe2 command opens outbound connections from the Relay Server Outbound Enabler (RSOE) to the Relay Server.
rsoe2 [ <option> ]+
rsoe2 @{ <filename> | <environment-variable> } ...
Parameters
Options
The following options can be used with the Outbound Enabler. Options that have defaults are optional. At a minimum, the
Outbound Enabler needs to supply the connection string for the Relay Server (-cr), the farm (-f) and server (-id) names. If a
security token is con gured, it must also be speci ed (-t).
rsoe2 options Description
@ <data> Reads options from the speci ed environment variable or con guration le. To protect
passwords or other information in the con guration le, you can use the File Hiding utility
(dbfhide) to encrypt the contents of the con guration le.
-cr " <connection-string>" Speci es the Relay Server connection string. The format of the Relay Server connection
string is a semicolon separated list of keyword=value pairs. The keyword-value pairs consist
of the following:
host
5/12/2023
IP address or hostname of the Relay Server. The default is localhost.
port
The port that the Relay Server is listening on. This is required.
http_userid
Userid for authentication. Optional. Consult your web server (or proxy)
documentation to determine how to set up HTTP authentication.
http_password
Password for authentication. Optional. Consult your web server (or proxy)
http_proxy_userid
Userid for proxy authentication. Optional. Consult your web server (or proxy)
http_proxy_password
Password for proxy authentication. Optional. Consult your web server (or proxy)
proxy_host
The host name or IP address of the proxy server. Optional.
proxy_port
The port number of the proxy server. Optional.
url_suffix
URL path to the server extension of the Relay Server. Required.
By default, the RSOE requires the url_suffix to be speci ed.
https
0 - HTTP (default)
1 - HTTPS
For https=1, the following options can also be speci ed:
certi cate_name
Common name eld of the certi cate.
certi cate_company
Organization name eld of the certi cate.
certi cate_unit
Organization unit eld of the certi cate.
identity
Provides the credentials to establish mutually authenticated TLS between

the Outbound Enabler and the backend server. Mutual authentication is
required for the backend server.
identity_password
Provides the credentials to establish mutually authenticated TLS between

the Outbound Enabler and the backend server. Mutual authentication is
required for the backend server.
ps
5/12/2023
Choose whether to use FIPS-certi ed encryption implementations for TLS

encryption and end-to-end encryption.
skip_certi cate_name_check Controls whether the client library skips the

check of the server host name against the database server certi cate host
names. Set this boolean option to ON or OFF to control whether the host
name of the backend server matches any of the host names in the root
certi cate. Enabling this option may prevent the client from fully
authenticating the server, leaving it vulnerable to attack. When initiating TLS
or HTTPS connections, the client libraries will check the host name of the
backend server against the certi cate provided by that server using the
procedure described in RFC 2818. This check only happens if none of the
certi cate_name, certi cate_company, or certi cate_unit options are
speci ed, or if the skip_certi cate_name_check option is not enabled. If any
of certi cate_name, certi cate_company, or certi cate_unit are speci ed,
then only those options are veri ed. The skip_certi cate_name_check option
disables the host name check when enabled. The host names or IP
addresses are derived from the subjectAltName (Subject Alternative Name
or SAN) extension and the Common Name (CN) eld. The SAN may contain
multiple host names with wild cards. For example, a Google certi cate might
include *.google.com, *.google.ca, and *.android.com. Thus, www.google.ca is
a valid host name.
trusted_certi cates
A le containing a list of trusted root certi cates.
To verify the backend server, and only the backend server, set this property
to backend_server_public_cert_ lename.
For Windows, if trusted_certi cates is not set, the operating system

certi cate store is used.
-cs " <connection-string>" Speci es the backend server connection string. The format of the connection string is a
semicolon separated list of name-value pairs. The name-value pairs consist of the following:
host
IP address or hostname of the backend server. The default is localhost.
port
The port the backend server is listening on. This is required. The default is 0.
https
0 - HTTP (default)
1 - HTTPS
By default, MobiLink starts up the TCPIP communication protocol. When starting

MobiLink for use with the RSOE, be sure to start the communication protocol
required by your RSOE con guration. For example, if you specify HTTPS as the
backend security, then MobiLink must be started with HTTPS.
When the https=1 parameter is included in the -cs option, the default port changes to
443.
For https=1, the following options can also be speci ed:
identity
The path and le name of the identity le that is to be used for server
authentication. Provides the credentials to establish mutually authenticated
TLS between the Outbound Enabler and the backend server. Mutual
authentication is required for the backend server.
5/12/2023
identity_password
An optional parameter that speci es a password for the identity le. When
this option is speci ed, the identity option must also be speci ed. Provides
the credentials to establish mutually authenticated TLS between the
Outbound Enabler and the backend server. Mutual authentication is required
for the backend server.
skip_certi cate_name_check Controls whether the client library skips the

check of the server host name against the database server certi cate host
names. Set this boolean option to ON or OFF to control whether the host
name of the backend server matches any of the host names in the root
certi cate. Enabling this option may prevent the client from fully
authenticating the server, leaving it vulnerable to attack. When initiating TLS
or HTTPS connections, the client libraries will check the host name of the
backend server against the certi cate provided by that server using the
procedure described in RFC 2818. This check only happens if none of the
certi cate_name, certi cate_company, or certi cate_unit options are
speci ed, or if the skip_certi cate_name_check option is not enabled. If any
of certi cate_name, certi cate_company, or certi cate_unit are speci ed,
then only those options are veri ed. The skip_certi cate_name_check option
disables the host name check when enabled. The host names or IP
addresses are derived from the subjectAltName (Subject Alternative Name
or SAN) extension and the Common Name (CN) eld. The SAN may contain
multiple host names with wild cards. For example, a Google certi cate might
include *.google.com, *.google.ca, and *.android.com. Thus, www.google.ca is
a valid host name.
trusted_certi cates
A le containing a list of trusted root certi cates.
To verify the backend server, and only the backend server, set this property
to backend_server_public_cert_ lename:
For Windows, if trusted_certi cates is not set, the operating system

certi cate store is used.
status_url
Enables backend status requests. This option can be set in the RSOE con guration
le (for example): -cs
"host=localhost;port=80;status_url=/getstatus/". The frequency of
the backend server liveness ping is set using the -d option.
If status_url is speci ed, the RSOE sends a simple HTTP GET request as follows:
GET /<<your-status-url>> HTTP/1.1\r\n Host: localhost:80\r\n
User-Agent: IAS_OE_BE_Status\r\n Connection: close\r\n \r\n.
The RSOE parses the backend server's HTTP response and looks for AVAILABLE =
<accept-value> in the BODY of the HTTP response, where <accept-value> is
one of: TRUE, FALSE, T, F, YES, NO, Y, N, ON, OFF, 1, or 0. If the RSOE receives
AVAILABLE=FALSE|F|NO|N|OFF|0, it assumes that the backend server is not
willing to accept more client requests and terminates its channels to the Relay
Server. If the RSOE receives AVAILABLE=TRUE|T|YES|Y|ON|1, it re-establishes
its channels with the Relay Server and resumes sending client requests to the
backend server.
-d <seconds> Sets the frequency of the backend server liveness ping and backend server status request.
The default is 5 seconds.
-dl Use this option to display log messages in the Relay Server Outbound Enabler console. By
default, log messages are not displayed for verbosity levels 1 and 2.
5/12/2023
-f <farm> Speci es the name of the farm that the backend server belongs to.
-id <id> Speci es the name assigned to the backend server.
-jsh <number> Speci es the maximum number of junctions in the idle junction pool. The total number of
junctions is allocated evenly across the number of Relay Servers in the farm. The default
value is 200.
-jsl <number> Speci es the minimum number of junctions in the idle junction pool. The total number of
junctions is allocated evenly across the number of Relay Servers in the farm. The default
value is 10.
-jl <number> Speci es the maximum number of junctions (the sum of active and idle junctions). The total
number of active and idle junctions is allocated evenly across the number of Relay Servers
in the farm. This setting is overriden by the setting for max_junction in the Backend Server
section of the Relay Server con guration le. The default value is 1000.
-o < le> Speci es the le to log output messages to.
-oq Prevents the appearance of the error window when a startup error occurs.
-os <size> Sets the maximum size of the message log les. The minimum size limit is 10 KB.
-ot < le> Truncates the speci ed log le and logs messages to it.
-q Run with a minimized window on startup.
-qc Shuts down the window on completion.
-s Stops the Outbound Enabler.
-t <token> Sets the security token to be passed to the Relay Server.
-uc Starts rsoe2 in shell mode. This is the default. Applies to Unix and Mac OS X.
Only specify one of -uc, -ui, -um, or -ux. When you specify -uc, this starts the RSOE in the
same manner as previous releases of the software.
-ud Instructs rsoe2 to run as a daemon. This option applies to Unix platforms only.
-ui Starts rsoe2 in shell mode if a usable display is not available. This option is for Linux with X
window server support.
When -ui is speci ed, the server attempts to nd a usable display. If it cannot nd one, for
example because the X window server isn't running, then rsoe2 starts in shell mode.
-ux Opens the RSOE messages window where messages are displayed on Linux.
On Windows, the RSOE messages window appears automatically.
When -ux is speci ed, the RSOE must be able to nd a usable display. If it cannot nd one,
for example because the DISPLAY environment variable is not set or because the X window
server is not running, the RSOE fails to start.
To run the RSOE messages window in quiet mode, use -q.
5/12/2023
-v <level> Sets the verbosity level to use for logging. The <level> can be 0, 1, 2, or higher (higher levels
are used primarily for Technical Support):
Log errors only. Use this logging level for deployment.
Session level logging. This is a higher level view of a synchronization session.
3 or higher
Levels 1 and 2 are only written to the message log le and are not displayed. To have all log
messages displayed, use the -dl option.
Checking IIS Client Negotiation Certi cate Status for Mutual

Authentication
To use mutual authentication with Relay Servers on IIS, the Negotiate Client Certi cate value for SSL certi cate status must be enabled.
To ensure that the Relay Server outbound enabler starts properly for mutual authentication, you must set this value on each IIS server.
Procedure
1. At a command prompt, check the SSL certi cate status:
netsh http show sslcert
The output should look similar to:

-------------------------
IP:port : 0.0.0.0:443
Certificate Hash : <cert_hash>
Application ID : {<app_id>}
Certificate Store Name : My
Negotiate Client Certificate : Disabled
If the Negotiate Client Certificate value in your command output is Disabled, perform the rest of the steps in this
task. Record these values before proceeding:
Certi cate Hash
Application ID
If the Negotiate Client Certificate value in your output is Enabled, there is nothing more that you need to do.
2. Delete the SSL certi cate state:
5/12/2023
netsh http delete sslcert 0.0.0.0:443
The output of this command should be:
SSL Certificate successfully deleted
3. Readd the SSL certi cate, using the values for Certi cate Hash and Application ID that you recorded above, and setting
clientcertnegotiation=enable.
netsh http add sslcert 0.0.0.0:443 <cert_hash> {<app_id>} clientcertnegotiation=enable
The output of this command should be:
SSL Certificate successfully added
4. Verify the new settings:
netsh http show sslcert
In the output of this command, the certi cate hash and application ID should be the same as in the original output, and the last
line should be:
...
Negotiate Client Certificate : Enabled
Con guring Apache Relay Server State Manager as a Service

Set up the State Manager process to run as a service on the Relay Server host.
Context
This task uses the dbsvc utility on the Web server host, which is installed from the Relay Server archive le, supplied on the SAP Mobile
Platform Runtime installation media.
Procedure
1. Open a command shell window, and set the current directory to the location of the dbsvc executable.
2. Enter the following at the prompt.
Apache host (Linux)
dbsvc -y -a <apache_user> -t rshost -w SMPRelayServer -q -qc -f

/<apache_install>/modules/rs.config -os 100K -ot /tmp/rs.log
Substitute parameter values shown here to match your con guration.
This command con gures the State Manager process (rshost) as a service.
3. To start the State Manager service:
From a Linux command shell:
a. Make sure the State Manager service runs under the same user credentials as the Apache service.
b. Change the current directory to:
Apache host (Linux) /<apache_install>/modules/
c. At the command prompt, enter:
dbsvc -u SMPRelayServer
4. To stop the State Manager service, enter the following at a command shell prompt: dbsvc -x SMPRelayServer
5/12/2023
5. To uninstall the State Manager service, enter the following at a command shell prompt: dbsvc -d SMPRelayServer
Installing a Load Balancer in Front of a Relay Server Farm

You can use either a software or a hardware load balancer to get the best performance out of your Relay Servers.
Context
You should be able to use any hardware or software load balancer with the Relay Servers you have installed to support your SAP Mobile
Platform cluster. This document describes how to use Apache, with proxy load balancing.
If you are using a hardware load balancer, see the product documentation for instructions on setting it up.
If you are using a software load balancer other than Apache, see the program documentation for instructions on setting it up.
 Note
The Relay Server provides session persistence (sticky sessions) to back-end servers, regardless of the load balancer you are using.
Con guring Apache as a Load Balancer

To use Apache as a software load balancer, edit the Apache con guration le to enable mod_proxy and mod_proxy_balancer and set up
the load-balancing features.
Prerequisites
Review the relevant reference documentation for mod_proxy and mod_proxy_balancer in your version of Apache at
http://httpd.apache.org/docs-project/ .
Procedure
1. Install Apache on a separate server in your DMZ.
See http://www.apache.org/dyn/closer.cgi
2. Secure the server.
Do not enable proxying until your server is secure.
3. Enable mod_proxy, mod_proxy_balancer.
Uncomment the following lines in the Apache Web Server con guration le (httpd.conf):
# mod_proxy - core module for proxying:

LoadModule proxy_module modules/mod_proxy.so
# mod_proxy_balancer implements clustering and load balancing:
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
4. On Linux, build Apache with these modules enabled.
5. Enable additional modules as needed.
Uncomment the lines for any additional modules for which you need the functionality. See the Apache documentation at
http://httpd.apache.org/docs-project/ .
6. On Windows, use the template below to set up load balancing between your Relay Servers.
Add the lines below to the Apache Web Server con guration le (httpd.conf). Replace terms in italics with actual values in your
environment:
<Apache_port> – Apache server port number.
5/12/2023
<Apache_srvr_name> – Apache server name.
<host_id> – virtual host ID.
<host_port> – virtual host port number.
<RS_farm> – Relay Server farm ID.
<RS#_IP> – IP address or server name for Relay Server #.
<RS#_node> – node name for Relay Server #.
<RS#_port> – port number for Relay Server #.
<webserver_doc_root> – doc root in le system used by Apache Web server.
<VirtualHost <host_id>:<host_port>>
ServerName <Apache_srvr_name>:<Apache_port>
DocumentRoot <webserver_doc_root>
# Enable forward proxy

ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
# Enable reverse proxy

ProxyPass / balancer://<RS_farm>/ stickysession=X-SMP-SESSID
ProxyPassReverse / http://<RS1_IP>:<RS1_port>/
ProxyPassReverse / http://<RS2_IP>:<RS2_port>
<Proxy balancer://<RS_farm>>
BalancerMember http://<RS1_IP>:<RS1_port>/ route=<RS1_node>
BalancerMember http://<RS2_IP>:<RS2_port>/ route=<RS2_node>
# Set counting algorithm to more evenly distribute work:
ProxySet lbmethod=byrequests
</Proxy>
# Enable load balancer management

<Location /balancer-manager>
SetHandler balancer-manager
</Location>
<Directory "htdocs">
AllowOverride AuthConfig
</Directory>
</VirtualHost>
Extend the example above to any number of Relay Servers by adding them to the ProxyPassReverse and BalancerMember
lists.
 Note
The stickysession parameter is required to support client request routing, also referred to as back-end server affinity, so
that the load balancer always sends a device's request to the same server.
7. On Linux, use the template below to set up load balancing between your Relay Servers.
Add the lines below to the Apache Web Server con guration le (httpd.conf). Replace terms in italics with actual values in your
environment:
<RS_farm> – Relay Server farm ID.
<RS#_IP> – IP address or server name for Relay Server #.
<RS#_node> – node name for Relay Server #.
<RS#_port> – port number for Relay Server #.
<RS1#_srvr> – server name for Relay Server #.
5/12/2023
# Enable forward proxy

ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<Proxy balancer://mycluster>
BalancerMember http://<RS1_IP>:<RS1_port>/ route=<RS1_node> loadfactor=5 route=<RS1_srvr>
BalancerMember http://<RS2_IP>:<RS2_port>/ route=<RS2_node> loadfactor=5 route=<RS2_srvr>
# Set counting algorithm to more evenly distribute work:
ProxySet lbmethod=byrequests
</Proxy>
# Enable reverse proxy

ProxyPass / balancer://<RS_farm>/ stickysession=X-SUP-SESSID
# Enable load balancer management

Order Deny,Allow
Allow from all
</Location>
Connecting to Relay Server at Runtime

After your Relay Servers have been installed and con gured, you can con gure an application to allow it to connect directly to the Relay
Server farm at runtime.
Relay Server acting as a reverse proxy or load balancer performs the same role as Apache used in those capacities, but Relay Server
requires additional parameters to be set. You do this by adding code to the application. For applications using Mobile Application
Framework (MAF) login modules, additional application code is not required; you can simply specify the relay server parameters in the
MAF login screen.
Android or iOS OData Applications

Use the sample code below in an Android or iOS OData application to connect with the ClientConnection object:
mSmphost ="<myrelayserver.com>";
mSmpPort= "80";
mSmpURLsuffix = "<path_to_relay_server_dll>";
mSmpFarmId = "<myrelayserver.com>”;
clientConnection.setConnectionProfile(true, mSmpHost, mSmpPort, mSmpURLsuffix, mSmpFarmId);
Android or iOS Kapsel Applications

Use the sample code below in an Android or iOS Kapsel application to connect with the ClientConnection object:
sURL= “<myrelayserver.com>”;
var oHeaders = {};
var request = {
headers : oHeaders,
requestUri : sUrl,
data: connectionData,
method : "POST"
};
OData.request(request, onSuccessForRegister, onError);
With MAF Login Modules
5/12/2023
If your application is using MAF login modules, you do not need to add code to the application. When setting up the MAF login, simply
enter the Relay Server parameters in these elds in the MAF login screen:
Server Address – Relay Server hostname
Company ID – Relay Server farm name
URL Suffix – path to Relay Server .dll on Relay Server hostname
Using Apache Reverse Proxy for HTTP Clients

For organizations that have HTTP clients that are designed to consume SAP Mobile Platform Server services, you may implement an
Apache reverse proxy in your production environment.
Context
For an example of how to implement an Apache Reverse Proxy, see:
1. Installing and Con guring Apache Reverse Proxy

Edit the httpd.conf le to load the modules that are required to prepare the Reverse Proxy for SAP Mobile Platform use.
2. Decrypting Certi cates for HTTPS Connections

The Apache 2.2 Windows version does not support encrypted certi cate key les. If the key le is encrypted, you must rst decrypt
it.
Installing and Con guring Apache Reverse Proxy

Edit the httpd.conf le to load the modules that are required to prepare the Reverse Proxy for SAP Mobile Platform use.
Context
In SAP Mobile Platform, communication can be either:
Unencrypted to port 8080
One-way authenticated and encrypted to port 8081
Two-way authenticated to port 8082
 Note
If clients are authenticating to the reverse proxy with X.509 certi cates, only the port 8082 path can be used to propagate the client
certi cates on the SSL_CLIENT_CERT header in a trusted fashion.
Apache is installed as one or more modules, in addition to mod_proxy: mod_proxy_http, mod_proxy_ftp, mod_proxy_ajp,
mod_proxy_balancer, and mod_proxy_connect. Thus, to use one or more of the particular proxy functions, load mod_proxy and
the appropriate module into the server. For the reverse proxy, load these modules:
headers_module
ssl_module
proxy_module
proxy_connect_module
proxy_http_module
For information about running a reverse proxy in Apache, see http://www.apachetutor.org/admin/reverseproxies . For information
about SSL and proxy modules, see http://httpd.apache.org/docs/2.2/mod/mod_ssl.html and
5/12/2023
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html .
Procedure
1. Download Apache 2.2 from a reliable source, and install the proxy according to package instructions.
2. In a text editor, open Apache2.2\conf\httpd.conf.
3. Uncomment these lines to load headers, and required SSL and proxy modules:
LoadModule headers_module modules/mod_headers.so

LoadModule ssl_module modules/mod_ssl.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
The three proxy_* modules are required by three proxy modes: HTTP, one-way HTTPS, and two-way HTTPS. The ssl_module
is required by both HTTPS proxy modes. The headers_module is required by two-way HTTPS proxy mode.
4. Add these lines to enable port 8080 as an HTTP proxy:
##############################
Listen 8080
<VirtualHost *:8080>
ServerName proxy-server
ErrorLog "C:/Apache2.2/logs/error.log"
TransferLog "C:/Apache2.2/logs/access.log"
<Location />
ProxyPass http://<sup-server>:8080/
ProxyPassReverse http://<sup-server>:8080/
</Location>
</VirtualHost>
##############################
5. Add these lines to enable port 8081 as a one-way HTTPS proxy:
##############################
Listen 8081
# activate HTTPS on the reverse proxy
SSLEngine on
SSLCertificateFile "C:/Apache2.2/conf/proxy-server.crt"
SSLCertificateKeyFile "C:/Apache2.2/conf/proxy-server.key"
SSLCertificateChainFile "C:/Apache2.2/conf/proxy-server-ca.crt"
SSLProxyEngine On
SSLProxyCACertificateFile C:/Apache2.2/conf/sup-server-ca.crt
<Location />
ProxyPass https://<sup-server>:8081/
ProxyPassReverse https://<sup-server>:8081/
</Location>
</VirtualHost>
6. Add these lines to enable port 8082 as a two-way HTTPS proxy:
##############################
Listen 8082
SSLEngine on
SSLCertificateFile "C:/Apache2.2/conf/proxy-server.crt"
SSLCertificateKeyFile "C:/Apache2.2/conf/proxy-server.key"
SSLCertificateChainFile "C:/Apache2.2/conf/proxy-server-ca.crt" # activate th
SSLCACertificateFile "C:/Apache2.2/conf/trusted-client-ca.crt"
SSLVerifyClient require
SSLVerifyDepth 10
SSLProxyEngine On
SSLProxyCACertificateFile C:/Apache2.2/conf/sup-server-ca.crt
SSLProxyMachineCertificateFile C:/Apache2.2/conf/proxy-client.pem
# initialize the special headers to a blank value to avoid http header forgeries
RequestHeader set SSL_CLIENT_CERT ""
5/12/2023
<Location />
# add SSL_CLIENT_CERT header to forward real client certificate
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
ProxyPass https://<sup-server>:8082/
ProxyPassReverse https://<sup-server>:8082/
</Location>
</VirtualHost>
##############################
7. Save the le.
8. Validate the con guration by opening a browser and testing these URLs:
https://proxy-server:8080/debug/app1
Task overview: Using Apache Reverse Proxy for HTTP Clients
Next task: Decrypting Certi cates for HTTPS Connections
Decrypting Certi cates for HTTPS Connections

The Apache 2.2 Windows version does not support encrypted certi cate key les. If the key le is encrypted, you must rst decrypt it.
Procedure
1. To decrypt an encrypted le, from a command prompt, run:
openssl rsa -in <encrypted>.key -out <decrypted>.key
2. Use the decrypted key in the httpd.conf le.
Task overview: Using Apache Reverse Proxy for HTTP Clients
Previous task: Installing and Con guring Apache Reverse Proxy
Con guring Apache as a Load Balancer for a Cluster

When you use Apache as a load balancer for an SAP Mobile Platform cluster....
Procedure
1. Install Apache on a separate server, outside the SAP Mobile Platform cluster.
See http://httpd.apache.org
2. Con gure Apache.
a. Use a text editor to open the <Apache_home>\conf le.
b. Enable the following modules:
mod_proxy
mod_proxy_http
mod_proxy_balancer
slotmem_shm_module
lbmethod_byrequests_module
c. Set up a basic proxy.
The sample below shows:

5/12/2023
The Apache load balancer listening on port 80.
The Apache load balancer cluster identi ed as balancer://my_smpcluster.
Two SAP Mobile Platform Server nodes (my_smpserver1 and my_smpserver2, both listening on port 8080,
making up the Apache load balancer cluster.
Use Apache header and stickysession.
Listen 80
<VirtualHost *:80>
ServerName loadbalancer-server
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://my_smpcluster>
BalancerMember http://my_smpserver1.my_co.com:8080 route=node01
BalancerMember http://my_smpserver2.my_co.com:8080 route=node02
ProxySet stickysession=ROUTEID
</Proxy>
ProxyPass / balancer://my_smpcluster/
ProxyPassReverse / balancer://my_smpcluster/
</VirtualHost>
d. Set up a one-way HTTPS proxy.
In the sample below:
The Apache load balancer listens on port 443.
The Apache load balancer cluster is identi ed as balancer://my_smpclusterhttps.
Two SAP Mobile Platform nodes, my_smpserver1 and my_smpserver2, both listen on port 8081, making up the
Apache load balancer cluster.
Listen 443
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile "C:/Apache24/conf/proxy-server.crt"
SSLCertificateKeyFile "C:/Apache24/conf/proxy-server.key"
SSLCertificateChainFile "C:/Apache24/conf/proxy-server-ca.crt"
SSLProxyEngine On
SSLProxyCACertificateFile C:/Apache24/conf/sup-server-ca.crt
<Proxy balancer://my_smpclusterhttps>
BalancerMember https://my_smpserver1.my_co.com:8081 route=node01
</Proxy>
ProxyPass / balancer://my_smpclusterhttps/
ProxyPassReverse / balancer://my_smpclusterhttps/
</VirtualHost>
e. Set up a two-way HTTPS proxy.
In the sample below:
The Apache load balancer listens on port 8443.
The Apache load balancer cluster is identi ed as balancer://my_smpclusterhttps2.
Two SAP Mobile Platform nodes, my_smpserver1 and my_smpserver2, both listen on port 8082, making up the
Apache load balancer cluster.
Listen 8443
SSLEngine on
SSLCertificateFile "C:/Apache24/conf/proxy-server.crt"
SSLCertificateKeyFile "C:/Apache24/conf/proxy-server.key"
SSLCertificateChainFile "C:/Apache24/conf/proxy-server-ca.crt"
# activate the client certificate authentication
SSLCACertificateFile "C:/Apache24/conf/trusted-client-ca.crt"
5/12/2023
SSLVerifyDepth 10
SSLProxyEngine On
SSLProxyCACertificateFile C:/Apache24/conf/sup-server-ca.crt
SSLProxyMachineCertificateFile C:/Apache24/conf/proxy-client.pem
# initialize the special headers to a blank value to avoid http header forgeries
<Proxy balancer://my_smpclusterhttps2>
</Proxy>
ProxyPass / balancer://my_smpclusterhttps2/
ProxyPassReverse / balancer://my_smpclusterhttps2/
</VirtualHost>
f. Start up Apache:
Windows – use the Windows Services Control Panel.
Linux – enter the following command in a terminal window:
apachectl start
3. Verify that each SAP Mobile Platform Server node is con gured correctly for session stickiness.
Perform an OData proxy request to each SAP Mobile Platform Server node. The request should look something like this:
GET http://my_smpserver1.my_co.com/odataproxy?fileName=my_test.txt
Check the response headers to verify that the cookie is formed correctly:
HTTP/1.1 200 OK
Date: Wed, 29 Jan 2014 22:39:27 GMT
Server: SAP
Content-Encoding: gzip
Content-Type: text/plain
Content-Length: 3714
Set-Cookie: ROUTEIDSSO=<long_hex_number>; Path=/; HttpOnly
Set-Cookie: ROUTESESSID=<long_hex_number>.node01; Path=/; HttpOnly
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
The response above shows .node01 appended to the ROUTEID cookie.
4. Verify that session stickiness is working with the proxy.
a. Use a text editor to open the <Apache_home>\httpd.conf le.
b. Add the following lines to the <VirtualHost *:80> block:
LogFormat "%h %l %u %t \"%r\" %>s %b duration:%T/%D balancer:%{BALANCER_WORKER_NAME}e Changed:%

TransferLog enhancedlog.log
This creates a new enhancedlog.log le in <Apache_home>. You can customize the le name and location.
c. Restart Apache using the Windows Services Control Panel.
d. Run a load test and look at the enhancedlog.log le. You should see something like this:
10.172.218.23 - - [29/Jan/2014:09:40:11 -0800] "GET /odataproxy?fileName=50flights.txt HTTP/1.1

10.172.218.23 - - [29/Jan/2014:09:40:11 -0800] "GET /odataproxy?fileName=50flights.txt HTTP/1.1
The rst request for a user when initial cookies are not set looks like this:
Changed:1 Sticky:-
Subsequent requests look like this:
5/12/2023
Changed:- Sticky:ROUTEID
This veri es that Apache read the X-SMP-SESSID cookie and sent the request to the correct server.
If you see Changed: 1 Sticky:X-SMP-SESSID, session stickiness did not work.
5. (Optional) Con gure Apache admin pages.
If you want to set up additional servlets to monitor Apache HTTPD, add these lines to your httpd.conf le:
ExtendedStatus On
Listen 8080
<Location /server-status>
SetHandler server-status
</Location>
</Location>
</VirtualHost>
 Note
Admin pages should run on a different port from the reverse proxy. In the example above, the proxy runs on port 80 and the
admin pages run on port 8080.
6. (Optional) Increase the number of threads for Apache.
If you downloaded the Windows HTTPD version from Apache Lounge, you are using the mpm_winnt module (statically loaded).
<Apache_home>>httpd.exe -l
Compiled in modules:
core.c
mod_win32.c
mpm_winnt.c
http_core.c
mod_so.c
To increase the number of threads, add the following directive to the httpd.conf le:
# WinNT MPM
# ThreadsPerChild: constant number of worker threads in the server process
# MaxConnectionsPerChild: maximum number of connections a server process serves
<IfModule mpm_winnt_module>
ThreadsPerChild 800
MaxConnectionsPerChild 0
</IfModule>
The ThreadsPerChild directive creates a static number of threads. Set this to the maximum number of concurrent
connections that you expect.
7. Validate the con guration by opening a browser and testing these URLs:
http://<loadbalancer-server>:80
https://<loadbalancer-server>:443
https://<loadbalancer-server>:8443
Each URL should return a page with the product name, version number, and build number.
Next Steps
5/12/2023
More information about using Apache as a load balancer is available from:
http://<apachehost>:8080/server-status, and
http://<apachehost>:8080/balancer-manager
Con guring Apache as a Load Balancer for the EIS Back End
When you use Apache as a load balancer for the EIS back end, the con guration le settings are different from those for Apache as a load
balancer on the front end.
Procedure
Con gure the reverse proxy in the Apache httpd.conf le.
The httpd.conf settings must:
Create a mutual trust between SAP Mobile Platform and the reverse proxy.
Create a mutual trust between the reverse proxy and the ICM of the back-end system.
For incoming requests from SAP Mobile Platform, extract the variable SSL_CLIENT_CERT from the HTTP header and re-inject it
into the header of the proxy pass requests.
 Caution
Do this only for requests from SAP Mobile Platform.
The sample httpd.conf below illustrates the settings required. You must create the two les highlighted in the sample:
gd_bundle.crt – The concatenated PEM-encoded CA certi cate les, in the same sequence in which they appear in the
certi cate chain. To use a coupled RSA+DSA certi cate pair, both certi cates must be in the same certi cate chain.
SDC_REV_PROXY_WDF.pem – The concatenated PEM-encoded certi cate les, in order of preference.
For more information on the structure of these les, go to the Apache Web site, http://httpd.apache.org/ , and search for the le
names.
<VirtualHost XXX.XXX.XXX.XXX:44304>
ServerName odata-XXXXX-XXXXXXX-<server_name>
DocumentRoot <doc_root>/nothing_here
RewriteEngine on
SSLEngine On
SSLProxyEngine On
# server certificate stuff

SSLCertificateFile <Apache_home>/ssl.crt/<server_name>.crt
SSLCertificateKeyFile <Apache_home>/ssl.key/<server_name>.key
SSLCertificateChainFile <Apache_home>/ssl.crt/gd_bundle.crt
# Root certificate(s) of the CA that signed the client certificate on

# SAP Mobile Platform
SSLCACertificateFile <Apache_home>/ssl.crt/odata_bundle.pem
SSLVerifyDepth 2
SSLOptions +StdEnvVars +FakeBasicAuth
# Client certificate used for the mutual trust against the ICM of the back end
5/12/2023
SSLProxyMachineCertificateFile <Apache_home>/ssl.cliencrt/SDC_REV_PROXY_WDF.pem
<Location />
AuthType Basic
AuthName "Restricted Files"
AuthBasicProvider file
# only allow particular client certiifates from the list defined here
AuthUserFile <Apache_home>/client-certificates-odata
Require valid-user
Order Deny,Allow
Allow from all
</Location>
# The remote system SMP is also a reverse proxy and already injects the certificate
# of the initial client request into the HTTP header. The 3 lines below read the
# certificate from the incoming http header in case the peer presents the correct
# client certificate (ODATA_SMP)
RewriteCond %{SSL:SSL_CLIENT_VERIFY} =SUCCESS
RewriteCond %{SSL:SSL_CLIENT_S_DN} =<client_cert_subject>
RewriteRule (.*) $1 [E=HTTP_IF_SSL_CLIENT_CERT:%{HTTP:SSL_CLIENT_CERT},NE]
# Inject extracted certificate into the HTTP header of the reverse proxy request
RequestHeader set SSL_CLIENT_CERT "%{HTTP_IF_SSL_CLIENT_CERT}e"
# Allow only a minimal URL name space to be proxied

RewriteRule ^<SAP_home>/opu/odata/(.*) https://YYY.YYY.YYY.YYY:61017/<SAP_home>/opu/odata/$1 [P,L,N
ProxyPassReverse <SAP_home>/opu/odata/ https://YYY.YYY.YYY.YYY:61017/<SAP_home>/opu/odata/
RewriteRule ^<SAP_home>/opu/sdata/(.*) https://YYY.YYY.YYY.YYY:61017/<SAP_home>/opu/sdata/$1 [P,L,N
ProxyPassReverse <SAP_home>/opu/sdata/ https://YYY.YYY.YYY.YYY:61017/<SAP_home>/opu/sdata/
# Disallow anthying else that does not match the above URI prefix
RewriteRule .* - [F]
ErrorLog <Apache_log_home>/odata-XXXXX-XXXXXXX-<server_name>.error.log
CustomLog <Apache_log_home>/odata-XXXXX-XXXXXXX-<server_name>.custom.log common
</VirtualHost>
Using Nginx Reverse Proxy for Agentry Clients

For organizations that have Agentry clients that are designed to consume SAP Mobile Platform Server services, you may implement an
Nginx reverse proxy in your production environment.
Context
For an example of how to implement an Nginx reverse proxy, see:
1. Installing Nginx Web Server

Download and install the Nginx Web server.
2. Con guring Nginx as a Reverse Proxy

Edit the nginx.conf le to con gure Nginx as a reverse proxy for SAP Mobile Platform and enable SSL.
Related Information
Agentry Security
Installing Nginx Web Server

5/12/2023
Download and install the Nginx Web server.
Context
The steps below are for installing Nginx on Windows. If you are installing Nginx on Linux, refer to documentation on the Nginx Web site:
http://nginx.org/en/docs/ .
Procedure
1. Download the .zip le for the mainline Windows version of Nginx from the Nginx Web site (http://nginx.org ) to a temporary
location.
2. Install Nginx by extracting the contents of the downloaded .zip le to a directory on the host system.
The top-level directory in the .zip le identi es the Nginx version. For example, if you have downloaded version 1.5.9 and you
extract the contents of the .zip le into C:\Program Files, the Nginx home directory under C:\Program Files is named
nginx-1.5.9.
The rest of these instructions refer to this Nginx home directory as <Nginx_Home>.
3. In a text editor, open <Nginx_Home>\conf\nginx.conf.
4. Make the changes indicated below and save the le.
...
server {
listen <Nginx_server_name>:8000;
server_name <Nginx_server_name>;
...
5. In a command prompt window, navigate to the <Nginx_Home> directory and run nginx.exe.
You should see no error messages displayed in the command prompt window.
6. Close the command prompt window, open Task Manager, and look for two nginx.exe processes:
7. As a nal test, enter the URL for the Nginx Web server in a browser window.
The URL is http://<server_name>:8000. The Nginx Web server should display this Welcome page:
Task overview: Using Nginx Reverse Proxy for Agentry Clients
Next task: Con guring Nginx as a Reverse Proxy
5/12/2023
Con guring Nginx as a Reverse Proxy

Edit the nginx.conf le to con gure Nginx as a reverse proxy for SAP Mobile Platform and enable SSL.
Context
The nginx.conf that you just modi ed to test that the Nginx Web server could be started should still be open in a text editor.
Procedure
To use Nginx reverse proxy with SSL, make the changes indicated below in the server{} section of
<Nginx_Home>\conf\nginx.conf.
...
server {
listen <Nginx_server_name>:8000;
server_name <Nginx_server_name>;
## edit the rest of the server{} section to look like this ##

ssl_certificate C:/nginx-1.4.4/cert/NginxServer.crt;
ssl_certificate_key C:/nginx-1.4.4/cert/NginxServer.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_session_timeout 5m;
access_log C:/nginx-1.4.4/logs/access_8001.log;
error_log C:/nginx-1.4.4/logs/error_8001.log;
root html;
index index.html index.htm;
location / {
access_log off;
proxy_pass https://<SMP_server_name>:8081/<application_name>;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# Go to next proxy upstream if first server is down.
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_connect_timeout 5s;
}
}
...
For information on setting up certi cates, see:
For Nginx (NginxServer.crt in the nginx.conf le listing above) – the Nginx Web site: http://nginx.org/en/docs/ and
http://nginx.org/en/docs/http/con guring_https_servers.html .
For SAP Mobile Platform Server – Managing Keystore and Truststore Certi cates in Administrator.
Task overview: Using Nginx Reverse Proxy for Agentry Clients
Previous task: Installing Nginx Web Server
5/12/2023
Using SAP Web Dispatcher with SAP Mobile Platform

SAP Web Dispatcher sits between the Internet and your SAP Mobile Platform system, intercepts client requests, and forwards each
request to SAP Mobile Platform Server.
SAP Web Dispatcher features include:
Multiple application-server support – persistence with stateful applications, load balancing, Advanced Business Application
Programming (ABAP), and Java servers.
Multiple system support – for multiple SAP Mobile Platform systems, maps requests to speci c systems, or performs load
balancing across system boundaries.
SSL – depending on your SSL con guration, forwards, terminates, or encrypts requests.
URL ltering – denies prede ned URLs access to your system.
URL rewriting – manipulates inbound HTTPS requests, based on de ned rules.
Web caching – acts as a Web cache to improve response times and conserve application-server caches.
See SAP Web Dispatcher
Installing SAP Web Dispatcher

Install SAP Web Dispatcher version 7.42 or later to use as a reverse proxy with SAP Mobile Platform.
Con guring SAP Web Dispatcher
Con gure Web Dispatcher as a proxy server for SAP Mobile Platform. Web Dispatcher handles only HTTPS requests;
communication with back ends should also use HTTPS.
Starting and Stopping Web Dispatcher
Start and stop Web Dispatcher on the command line.
Installing SAP Web Dispatcher

Install SAP Web Dispatcher version 7.42 or later to use as a reverse proxy with SAP Mobile Platform.
Context
For information about the latest release, see SAP Note 908097 – SAP Web Dispatcher: Release, Installation, Patches, Documentation
Procedure
1. Navigate to the SAP Software Download Center .
2. Select the product for your operating system, and download.
3. Extract Web Dispatcher to a local folder, for example, C:\WebDisp.
Next Steps
Con gure Web Dispatcher to work with SAP Mobile Platform—seeCon guring SAP Web Dispatcher.
Con guring SAP Web Dispatcher

Con gure Web Dispatcher as a proxy server for SAP Mobile Platform. Web Dispatcher handles only HTTPS requests; communication with
back ends should also use HTTPS.
5/12/2023
Prerequisites
1. Con gure SAP Mobile Platform to support the Secure Sockets Layer (SSL) protocol. See Using SSL to Secure HTTPS Channel
Communications in SAP Mobile Platform.
2. Install SAP cryptographic software.
Procedure
1. Generate Personal Security Environments.
2. Import the SAP Mobile Platform Server certi cate into the list of trusted certi cates for the Web Dispatcher client PSE.
3. Create a profile.txt le, and con gure back-end servers and Web Dispatcher server ports. For example:
wdisp/system_0 = SID=SMP, SSL_ENCRYPT=0, CONFIG_PROTOCOL=http, EXTSRV=http://<SMP Server>:8080;http:/

wdisp/system_1 = SID=SEC, EXTSRV=https://<SMP Server 1>:8081;https://<SMP Server 1>:8081, SRCSRV=*:90
wdisp/system_2 = SID=MUL, EXTSRV=https://<SMP Server 2>:8082;https://<SMP Server 2>:8082, SRCSRV=*:90
icm/server_port_0 = PROT=HTTP,PORT=9080,PROCTIMEOUT=600
icm/server_port_1 = PROT=HTTPS,PORT=9081,PROCTIMEOUT=600
icm/server_port_2 = PROT=HTTPS,PORT=9082,VCLIENT=2
This example con gures Web Dispatcher ports that correspond to the SAP Mobile Platform Server ports; and it de nes the back-
end server IDs, <SMP Server 1> and <SMP Server 2>. By default, Web Dispatcher times out after 60 seconds, which may not be
enough for large synchronizations. Setting PROCTIMEOUT to a higher value allows larger syncs to nish before timing out. When
you start Web Dispatcher, you specify the location of the profile.txt le.
4. If required, con gure other Web Dispatcher pro le parameters.
5. Start Web Dispatcher, and test the connection to SAP Mobile Platform Server.
6. Import the SAP Mobile Platform Server certi cate into the Web Dispatcher truststore.
7. To enable mutual SSL (port 8082), map the Web Dispatcher certi cate to the impersonator role in an application security pro le
role-mapping le. For example, map the user:C=NA, ST=NA, L=NA, O=SAP, OU=Certificates, CN=127.0.0.1
certi cate to the impersonator role.
 Note
Multiple applications can share a single security pro le.
Installing SAP Cryptographic Software

Install SAP cryptographic software so you can create and import Personal Security Environments (PSEs) for Web Dispatcher.
Generating Personal Security Environments
Generate a PKCS #12 certi cate, and use it to generate Personal Security Environments (PSEs) for Web Dispatcher.
Web Dispatcher Pro le Parameters
Determine SAP Web Dispatcher functionality by de ning its parameters in a pro le text- le.
Con guring SAP Web Dispatcher for TLS
To enable applications to use TLS 1.2 to secure both incoming and outgoing connections, you must maintain the SAP Web
Dispatcher pro le sapwebdisp.pfl.
Related Information
Using SSL to Secure HTTPS Channel Communications in SAP Mobile Platform
Installing SAP Cryptographic Software

Install SAP cryptographic software so you can create and import Personal Security Environments (PSEs) for Web Dispatcher.
Procedure
5/12/2023
1. Navigate to SAP Service Marketplace .
2. Select Installations and Upgrades Browse our Download Catalog SAP Cryptographic Software .
3. Select SAPCRYPTOLIB COMMONCRYPTOLIB 8 .
4. Select the support package for your platform, download, and install.
Generating Personal Security Environments

Generate a PKCS #12 certi cate, and use it to generate Personal Security Environments (PSEs) for Web Dispatcher.
Prerequisites
Install SAP Web Dispatcher.
Context
To create a PKCS #12 certi cate and generate PSEs using the Web Dispatcher administration interface, see:
Con guring SAP Web Dispatcher to Support SSL, and
Using the Web Administration Interface.
Alternately, follow the instructions below:
Procedure
1. In SAP Mobile Platform Server, generate a PKCS #12 certi cate, for example, smp_crt.p12.
2. Change to the local Web Dispatcher folder, and generate SAPSSLS.pse and SAPSSLC.pse PSEs by running the following
commands; replace C:\smp_crt.p12 with the name and location of the certi cate you generated:
mkdir sec
set SECUDIR=C:\WebDisp\sec
sapgenpse.exe import_p12 -p SAPSSLS.pse -z changeit C:\smp_crt.p12
sapgenpse.exe import_p12 -p SAPSSLA.pse -z changeit C:\smp_crt.p12
sapgenpse.exe import_p12 -p SAPSSLC.pse -z changeit C:\smp_crt.p12
Web Dispatcher Pro le Parameters

Determine SAP Web Dispatcher functionality by de ning its parameters in a pro le text- le.
The pro le parameters that are described below are a subset of those de ned in SAP Web Dispatcher Parameters – Reference. If
required, you may add properties from this reference manual to the Web Dispatcher pro le.
Parameter Default Value Description
ssl/server_pse SAPSSLS.pse Server SSL Personal Security Environment (PSE) le.
ssl/client_pse SAPSSLC.pse Client SSL Personal Security Environment le.
wdisp/ssl_encrypt 1 Determines how Web Dispatcher handles inbound HTTP/HTTPS requests:

0 – forwards requests unencrypted.
1 – for requests that arrive over HTTPS, encrypts them with SSL, then forwards them.
2 – forwards requests that are encrypted with SSL.
You can con gure Web Dispatcher for end-to-end SSL by specifying PROT=ROUTER when
you de ne the icm/server_port_<x> parameter.
5/12/2023
Parameter Default Value Description
wdisp/ssl_auth 1 Speci es which Web Dispatcher X.509 client certi cate to use with an application server::
0 – no certi cate.
1 – default certi cate.
2 – the certi cate that is speci ed in the wdisp/ssl_cred pro le parameter.
wdisp/ssl_cred none The PSE le that is used for authentication on the server.
This option applies only when wdisp/ssl_cred = 2.
icm/server_port_<xx> none The Web Dispatcher/icm port/service (PORT) to use for the protocol (PROT). For example:
PROT=HTTPS,PORT=443,TIMEOUT=120
Con guring SAP Web Dispatcher for TLS

To enable applications to use TLS 1.2 to secure both incoming and outgoing connections, you must maintain the SAP Web Dispatcher
pro le sapwebdisp.pfl.
Prerequisites
1. Con gure SAP Mobile Platform to support the Transport Layer Security (TLS) protocol.
2. Install SAP cryptographic software.
Procedure
1. Download latest SAP Web Dispatcher, version 7.42.119 or later.
2. Open the SAP Web Dispatcher pro le sapwebdisp.pfl in your favorite text editor.
3. Add the following values in the SAP Web Dispatcher pro le sapwebdisp.pfl:
ssl/ciphersuites = 896:HIGH
ssl/client_ciphersuites= 896:HIGH
4. Restart the SAP Web Dispatcher.
Next Steps
For additional information on securing connections, see SAP Note 510007 - Setting up SSL on Application Server ABAP .
Starting and Stopping Web Dispatcher

Start and stop Web Dispatcher on the command line.
Procedure
1. To start Web Displatcher, run:
sapwebdisp.exe pf=profile.txt
where profile.txt is the name of the Web Dispatcher pro le le.
2. To stop Web Displatcher, run:
sapntkill -INT <pid>
where <pid> is the Web Dispatcher process ID.
5/12/2023
Setting Up Back-End Communications

Set up communications between SAP Mobile Platform Server and your back end. Back end refers to your data source, or enterprise
information system (EIS).
Back-End Communication Setup Tasks
Task Description
Download back end drivers and libraries (Non-SAP back ends) Download and install all required drivers and
libraries for your back-end type.
Download and install Java Connector libraries and utilities (SAP back ends) Download and install the SAPCAR utility and SAP
cryptographic library.
Con gure back-end communications with an HTTP proxy Con gure the proxy host and port. Override for HTTP/HTTPS
Authentication provider if required.
Con gure host systems for Agentry back ends Con gure the host systems that Agentry applications connect to and
synchronize data with.
If you are using a single sign-on system (SSO) to achieve end-to-end integration across client applications and back-end resources,
complete SSO setup as part of your security administration.
Preparing to Connect to SAP using Java Connectors

SAP Mobile Platform Server can use Java Connectors (JCo) to connect to the SAP back end. With the correct security setup, you
can also implement single sign-on (SSO) authentication.
Setting Up Host System Connectivity for Agentry Applications
You must con gure the host system to support the connections that are required by Agentry applications.
Related Information
Single Sign-On Integration Across Client Applications
Preparing to Connect to SAP using Java Connectors

SAP Mobile Platform Server can use Java Connectors (JCo) to connect to the SAP back end. With the correct security setup, you can also
implement single sign-on (SSO) authentication.
Prerequisites
You must have an SAP account to access the SAP Web site and download libraries and utilities.
Installing the SAPCAR Utility

Unzip and install the latest SAPCAR utility on your SAP Mobile Platform Server host. You can use SAPCAR to extract the contents
of compressed SAP les, for example, RFC and cryptographic library les.
Installing the SAP Cryptographic Libraries
Con gure Secure Network Communications (SNC) for SAP Mobile Platform Server SAP JCo connections. SNC may be required by
your SAP back end, if you are using SSO2 tokens or X.509 certi cates for connection authentication.

Unzip and install the latest SAPCAR utility on your SAP Mobile Platform Server host. You can use SAPCAR to extract the contents of
compressed SAP les, for example, RFC and cryptographic library les.
5/12/2023
Context
The installation package is available to authorized customers on the SAP Service Marketplace. There are different distribution packages
for various hardware processors. Select the package that is appropriate for your platform.
Procedure
1. Go to the SAP Web site at http://service.sap.com/swdc (login required).
2. From the SAP Download Center, navigate and log in to Support Packages and Patches Browse our Download Catalog
Additional Components .
3. Select SAPCAR.
4. Select the current version, for example, SAPCAR 7.20, then download the appropriate SAPCAR for your platform.
Task overview: Preparing to Connect to SAP using Java Connectors
Related Information

Con gure Secure Network Communications (SNC) for SAP Mobile Platform Server SAP JCo connections. SNC may be required by your
SAP back end, if you are using SSO2 tokens or X.509 certi cates for connection authentication.
Prerequisites
Download and install the SAPCAR utility, which is required to extract the contents of the cryptographic library.
Context
Unzip and install the contents of the latest SAP cryptographic archive on your SAP Mobile Platform Server host. There are different
distribution packages for various hardware processors.
Make sure you are installing the correct libraries for your environment, and into folders that are based on the architecture of your
machine.
Procedure
1. Go to the SAP Web site at http://service.sap.com/swdc (requires login) and download the latest SAP cryptographic library
suitable for your platform.
a. Navigate to Installations and Upgrades Browse our Download Catalog SAP Cryptographic Software SAPCryptolib
for Installation SAPCRYPTOLIB <version> .
b. Select and download the platform-speci c le.
2. Create a directory into which to unzip the cryptographic le. For example: C:\sapcryptolib.
3. Copy the appropriate Windows cryptographic library for your machine (for example, SAPCRYPTOLIB<version>.SAR) to the
C:\sapcryptolib directory.
4. Open a command prompt and navigate to C:\sapcryptolib.
5. Extract the SAR le. For example:
SAPCAR_4-20002092.EXE -xvf C:\SAPCRYPTOLIB<version>.SAR -R C:\sapcryptolib
6. Copy the following into the C:\sapcryptolib directory:
For Itanium 64-bit processors, copy the ntia64 subdirectory contents.
For Intel 64-bit processors, copy the nt-x86_64 subdirectory contents.
5/12/2023
For Intel 32-bit processors, copy the ntintel subdirectory contents.
7. Delete the corresponding subdirectory when les have been moved.
8. If you have installed SAP Mobile Platform SDK, you must add the SECUDIR variable to the following batch le:
<SMP_HOME>\MobileSDK<version>\Eclipse\MobileWorkSpace.bat.
Task overview: Preparing to Connect to SAP using Java Connectors
Related Information

You must con gure the host system to support the connections that are required by Agentry applications.
Within Agentry, "system connection" refers to the connectivity between the Agentry application and the back-end systems with which it
synchronizes data. The speci cs of the host system con guration in relation to the system connections depends on the types of system
connections in use.
There are multiple system types with which Agentry applications can connect and synchronize data. Any application can contain multiple
system connections of varying types.
SQL Database – connects the server to SQL databases, including Oracle or Microsoft SQL Server, using native drivers; or to other
databases using standard ODBC drivers. The Agentry application synchronizes data with a database system using ANSI SQL
statements.
Java Virtual Machine – connects the server to a system via a Java API. The mobile application contains Java code that calls into
this API for the purposes of synchronizing data.
HTTP-XML – connects the server to a Web server. The Agentry application issues HTTP requests to the Web server. Data returned
based on these requests is expected to be in structured XML format. This return data is parsed and processed based on XPath
statements within the mobile application.
OData – connects the server to an OData back-end service.
File System – connects the server to the host operating system. This type of connection allows the server to execute commands
on the host system for the purposes of data synchronization and le transfer, and to validate users against the host system where
necessary.
Before installing an Agentry application, con gure the host system in relation to the system connection types as they pertain to the
needs of the application. Additional con guration of the Agentry application itself will be needed after it has been installed. All system
connection types support user authentication.
 Note
If any of these resources are already installed on the host system, you do not need to install them again. For example, the SAP Mobile
Platform Server installation includes a Java Virtual Machine (<SMP_HOME>\sapjvm7). This is available for you to use if you do not
want to install a separate JVM for your Agentry application.
Establishing Connectivity: Oracle Net Service Names

Create a net service name for use by an Agentry application.
Establishing Connectivity: SQL Server ODBC (Windows)
Create an ODBC data source name (DSN), which is used for connections to a Microsoft SQL Server database system.
Establishing Connectivity: SQL Server ODBC (Linux)
Con gure the ODBC connection to a SQL Server database from Linux.
Establishing Connectivity: Java Virtual Machine
5/12/2023
When the Agentry application is to synchronize data using a Java Virtual Machine system connection, the requirements of
con guring the server's intended host system depend on the needs of the back-end system, and on the nature of the interface
with which the server is to communicate.
Establishing Connectivity: HTTP-XML
When the Agentry application is to synchronize data with an HTTP server that returns XML data, little con guration is required
prior to installing the Agentry application. The con guration required involves access to the HTTP server. The speci c tasks for
this vary with each implementation and application.
Establishing Connectivity: OData
When the Agentry application is to synchronize data with an OData back-end service via an HTTP server that returns XML data,
little con guration is required prior to installing the Agentry application. The con guration required involves access to the HTTP
server. The speci c tasks for this vary with each implementation and application.
Establishing Connectivity: Host File System
The Agentry application can establish a system connection with the le system of the host computer on which it is installed.
Related Information
De ning Back-end Connections for Agentry
Localizing Agentry Applications
Con guring Agentry Settings
Updating Agentry Con guration Settings
Localization Files
Establishing Connectivity: Oracle Net Service Names

Create a net service name for use by an Agentry application.
Prerequisites
Verify the proper version of the Oracle client software is installed on the intended host system for the Agentry application.
Gather the following information:
Database service name – the service name or global database name of the database to which the Agentry application is to
connect.
Communication protocol – the protocol to use for communication between the Agentry Server and the Oracle database.
May be one of: TCP, TCPS, ICP, or NMP.
Database host network name – the network name of the host system for the Oracle database server. This is needed only if
the communications protocol used is TCP, TCPS, or NMP.
Database port number – the port number used to communicate with the Oracle database server. This value is only needed
if the TCP or TCPS communications protocol is used.
Pipe name – the name of the pipe for the database service. This value is only needed if the NMP communications protocol
is used.
Agentry application login and password – the login and password to the database that used by the Agentry application to
connect with the database server.
Desired net service name – the Net Service Name by which the connection created is identi ed on the Agentry
application’s host system.
Context
This task uses the Net Con guration Assistant that is included in version 9i of the Oracle client software. If you are not familiar with this
tool, review the Oracle documentation for the Net Con guration Assistant and for creating net service names before proceeding.
Procedure
5/12/2023
1. Start the Oracle Net Con guration Assistant, select Local Net Service Name con guration, and click Next.
2. Select Add and click Next.
3. Select the Oracle database version used in your environment, then click Next..
4. Enter the database service name to which the Agentry application will connect, then click Next..
5/12/2023
5. Select the appropriate protocol for your environment, then click Next. Click Help for additional information.
6. Enter protocol-speci c con guration information:
TCP or TCPS – the database host computer name for the database to connect to. You must also enter the database port
number by entering its value or choosing to use the default value provided.
IPC – the IPC key value for the local Oracle database service.
NMP – the database host computer name. You must also enter the database pipe name or choose the default pipe name
provided.
Click Next.
7. Test the new net service name to verify all con guration options are correct and to validate the login and password used by the
Agentry application application. Follow the instructions on the next screen. As an added test, change the login information to use
the login and password intended for use by the Agentry application. When you nish testing, click Next.
8. Enter the Net Service Name by which this connection is identi ed on the system. Make a note of this name, as you will need it to
con gure the Agentry application to connect to the target database.
Click Next.
9. Select Yes to add another service name. Select No to advance the wizard to the nal screen.
5/12/2023
Click Next, then Finish to close the wizard.
Results
An Oracle net service name has now been created on the host system on which the Agentry application will be installed. The server uses
the net service name to connect to the database with which it will synchronize data for the mobile application.
Establishing Connectivity: SQL Server ODBC (Windows)

Create an ODBC data source name (DSN), which is used for connections to a Microsoft SQL Server database system.
Prerequisites
Install or verify the presence of the proper version of the Microsoft SQL Server ODBC drivers matching the version of the SQL
Server database to which the Agentry application will connect.
Gather the following information:
DSN name – determine and record the name for the DSN, which is the name by which the ODBC connection for the SQL
Server database is identi ed on the host system.
Server network name – the network name of the host system for the SQL Server database.
Login authentication method – determine whether a database client’s login and password will be validated using Windows
NT authentication, or SQL Server authentication. Determine the proper method before creating the DSN.
Login and Password – if the login authentication method will be SQL Server authentication, obtain the login and password
of a valid database user.
Default database – determine the proper database instance to which a database client connects when using the DSN
created in this procedure.
Additional options – there are several options available within the Add System DSN wizard that do not usually need to be
modi ed for Agentry. However, if special circumstances in an implementation require changes to these options, make such
determinations prior to creating the new DSN for the Agentry application.
Context
A DSN is created using the Add System DSN wizard provided in the Data Sources (ODBC) utility in Windows. Minimal information is
provided here to assist you in completing this task. If you are not familiar with this procedure or the concepts of ODBC, review the
Microsoft documentation before proceeding.
Procedure
5/12/2023
1. In Windows, select Start Settings Control Panel Administrative Tools Data Sources (ODBC) . Select the System DSN
tab.
2. Click Add.
Select the appropriate SQL Server driver and click Finish.
3. Enter the DSN name and make a note of it, as you will need it during the Agentry application installation. Also enter a description
and network name.
5/12/2023
Enter or select the server to which to connect, then click Next.
4. Select the authentication method for database clients using this DSN and, if SQL authentication is selected, the login and
password for the SQL Server database.
Click Next.
5. Set the default database, and, for most situations, leave to the remaining options set to their defaults. Any changes should be
made only by an expert user who understands the purpose and resulting behavior of each setting and the overall needs of the
implementation environment.
5/12/2023
Click Next.
6. Set the nal options as needed, based on the environment and administrative needs. These settings pertain primarily to locality
and logging, and should be changed only by someone who is familiar with their purposes.
Click Finish.
7. Review the summary of the DSN con guration and click Test Data Source.
5/12/2023
Once the test has completed successfully, click OK to close this wizard and return to the Data Sources (ODBC) utility.
Results
A new ODBC Data Source Name is created. This DSN will be used by the Agentry application to connect with the MS SQL Server
database.
Establishing Connectivity: SQL Server ODBC (Linux)

Con gure the ODBC connection to a SQL Server database from Linux.
Prerequisites
The SQL Server database must be installed on a supported version of Windows.
The ODBC connection must be con gured to Linux.
Download the unixODBC and Freetds open source packages to Linux server, unzip, and install them. Use your favorite operating
system or download source, and tools; or use the following examples. Keep in mind that service pack versions change continually,
so you may need to adjust your search.
 Note
SuSE ‒ obtain TDS and its ODBC driver from

http://download.opensuse.org/repositories/devel:/libraries:/c_c++/SLE_11_SP3/x86_64/;
search for:
libfreetds-0.91-31.2.x86_64.rpm
libtdsodbc0-0.91-31.2.x86_64.rpm
You can use Yast, which is included with Linux, to install and con gure unixODBC.
Red Hat ‒ obtain TDS from http://pkgs.repoforge.org/rpmforge-release/; search for: rpmforge-

release-0.5.3-1.el6.rf.x86_64.rpm. You can use the unixODBC package that is installed in Red Hat by
default, or use the Yum installer.
5/12/2023
You must install unixODBC rst, and then Freetds.
Context
You must edit con guration les to point to the correct SQL Server from Linux.
Procedure
1. Edit the /freetds.conf le:
SuSE ‒ add the following to the end of the le (/etc/freetds/freetds.conf on SuSE Linux):
[<SQL_server_name>]
host = <SQL_server_name>.<domain>
port = 1433
tds version = 8.0
client charset = UTF8
Red Hat ‒ add the following to the end of the le (/etc/freetds.conf on Red Hat Linux):
[<SQL_server_name>]
host = <SQL_server_name>.<domain>.
port = 1433
client charset = UTF8
tds version = 8.0
2. Edit the /odbc.ini le:
 Note
Add an entry for each database, making sure that the entries in the freetds and odbc .INI les match.
SuSE ‒ add the following to the end of the le (/etc/unixODBC/odbc.ini on SuSE Linux):
[<SQL_server_description>]
Description = <SQL_server_description>
Driver = SQLServer
Servername = <SQL_server_name>
Database = <SQL_server_DB_name>
Language = us_english
Red Hat ‒ add the following to the end of the le (/etc/odbc.ini on Red Hat Linux):
[ODBC Data Sources]

<SQL_server_name> = SQLServer
[<SQL_server_description>]
Description = <SQL_server_description>
Driver = SQLServer
Servername = <SQL_server_name>
Database = <SQL_server_DB_name>
Language = us_english
3. Edit /etc/odbcinst.ini (or /etc/unixODBC/odbcinst.ini on SuSE Linux):
SuSE ‒ add the following to the end:
[SQLServer]
Description = ODBC For SQLServer
5/12/2023
Driver = /usr/lib64/libtdsodbc.so.0
Setup = /usr/lib64/libtdsodbc.so.0
UsageCount=1
FileUsage=1
Red Hat ‒ check the following:
In the [ODBCINST] section, make sure there is a line that reads: SQLServer=Installed.
Make sure the following section exists:
[SQLServer]
Description=ODBC For SQLServer
Driver=/usr/lib64/libtdsodbc.so.0
Setup=/usr/lib64/libtdsodbc.so.0
UsageCount=1
FileUsage=1
4. Verify that /freetds.conf con guration works.
[root@CNPVGLLSSC1052 freetds-0.95rc3]# cd /usr/local/freetds

[root@CNPVGLLSSC1052 freetds]# cd bin
[root@CNPVGLLSSC1052 bin]# ./tsql -S <DB_name> -U <<DB Username>> -P <<DB Password>>
locale is "en_US.UTF-8"
Locale charset is "UTF-8"
Using default charset "UTF-8"
1> select top 5 [toolnum] FROM qatool
2> go
toolnum
111111111
111111AAA
111111BBB
111111CCC
111111DDD
(5 rows affected)
1> exit
If the rows appear, it means the SQL Server database can connect via /freetds.
5. Verify that ODBC con guration works.
[root@CNPVGLLSSC1052 freetds]# cd /usr/bin

[root@CNPVGLLSSC1052 bin]# ./isql -v <DB_name> <<DB Username>> <<DB Password>>
+----------------------------------------+
| Connected! |
| sql-statement |
| help [tablename] |
| quit |
| |
+----------------------------------------+
SQL>
The message indicates connection to the SQL Server database.
Establishing Connectivity: Java Virtual Machine

When the Agentry application is to synchronize data using a Java Virtual Machine system connection, the requirements of con guring
the server's intended host system depend on the needs of the back-end system, and on the nature of the interface with which the server
is to communicate.
5/12/2023
The speci c tasks for this vary with each implementation and application.
Establishing Connectivity: HTTP-XML

When the Agentry application is to synchronize data with an HTTP server that returns XML data, little con guration is required prior to
installing the Agentry application. The con guration required involves access to the HTTP server. The speci c tasks for this vary with each
implementation and application.
Most of the tasks involved in connecting the Agentry application to the HTTP server occur during con guration. For details on these post-
installation tasks, see Setting Up the Development Environment for Agentry Toolkit in Agentry App Development and Agentry Security in
Administration.
Establishing Connectivity: OData

When the Agentry application is to synchronize data with an OData back-end service via an HTTP server that returns XML data, little
con guration is required prior to installing the Agentry application. The con guration required involves access to the HTTP server. The
speci c tasks for this vary with each implementation and application.
Most of the tasks involved in connecting the Agentry application to the HTTP server occur during con guration. For details on these post-
installation tasks, see Setting Up the Development Environment for Agentry Toolkit in Agentry App Development and Agentry Security in
Administration.
Establishing Connectivity: Host File System

The Agentry application can establish a system connection with the le system of the host computer on which it is installed.
This connection allows the server to read and write les, and transfer those les between clients and the le system. It also enables the
Agentry application to execute command line processes on the host system. Finally, the Agentry application can use this connection to
read and write text les, using the contents as part of the production data for an application.
To implement a le system connection for the Agentry application, the host system must include a user account under which the Agentry
application runs. This account must have appropriate permissions to perform the tasks required by the application. That is, the account
must have read/write access to the folders or directories on the le system with which it will be working, and the proper permissions to
execute the commands the application has been developed to execute.
Execute all Agentry application operations using this account, including con guring the Windows Service or Linux daemon process to run
the server.
Adding a SOCKS Proxy or Load Balancer for APNS Connections

If you have a network-based proxy server between SAP Mobile Platform and your Internet connection to Apple Push Noti cation Service
(APNS), you can enable a path through network obstacles to the APNS servers by using either a SOCKS proxy in the network proxy
server, or a hardware load balancer in the DMZ.
Enabling a SOCKS Proxy in a Network Proxy Server

Specify the proxy server and port number in Management Cockpit.
Adding a Load Balancer in the DMZ
If the DMZ load balancer meets the prerequisite requirement and the rewalls are con gured properly, enable the load balancer
to support APNS by adding entries in the SAP Mobile Platform Server's host le.
Enabling a SOCKS Proxy in a Network Proxy Server

5/12/2023
Specify the proxy server and port number in Management Cockpit.
Prerequisites
The network proxy server must have SOCKS capability.
Procedure
1. In Management Cockpit, select Settings System .
2. Scroll down to the Other Settings section.
3. Set SOCKS proxy host to <socksproxy.int.company.corp>.
Where <socksproxy.int.company.corp> is the network name of the network proxy server, con rmed with your network
administrator team.
4. Set SOCKS proxy port to <1080>.
Where <1080> is the network proxy server port number, con rmed with your network administrator team.
5. Save your changes.
Adding a Load Balancer in the DMZ

If the DMZ load balancer meets the prerequisite requirement and the rewalls are con gured properly, enable the load balancer to
support APNS by adding entries in the SAP Mobile Platform Server's host le.
Prerequisites
The DMZ load balancer must:
Be able to handle SSL connections and pass the client certi cate through to the APNS server upon challenge.
Have rewall rules that allow connection to the APNS server farm. Because APNS uses a load-balancing scheme that results in
different IP addresses at different times for the same host name, Apple recommends that you specify the entire 17.0.0.0/8
address block in your rewall rules. See
https://developer.apple.com/library/ios/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG41 .
The steps below have been tested with the two load balancers listed below and should work for other load balancers. For more
information on setting up the two load balancers tested, see:
Citrix Netscaler – http://support.citrix.com/proddocs/topic/netscaler-getting-started-map-10/ns-ssloff-intro-con.html
F5 Big IP – http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-1-0/15.html
Procedure
1. Log in with administrative privileges to the SAP Mobile Platform Server host machine.
2. Go to the directory where the hosts le is located:
Windows – C:\Windows\System32\drivers\etc\
Linux – /etc/
3. Back up the hosts le.
4. Use a text editor to open the hosts le.
5. Add these two lines to the end of the le, mapping IP addresses to the APNS:
<XXX.XXX.XXX.XXX> gateway.sandbox.push.apple.com
<YYY.YYY.YYY.YYY> feedback.sandbox.push.apple.com
5/12/2023
where:
<XXX.XXX.XXX.XXX> is the gateway push IP address of the load balancer virtual server (LBVS).
<YYY.YYY.YYY.YYY> is the feedback push IP address of the LBVS.
 Note
Inclusion of ".sandbox" in the domain names is for testing purposes. In a production installation, omit ".sandbox" from each
domain name:
... gateway.push.apple.com
... feedback.push.apple.com
6. Save and close the le.
Results
Now when SAP Mobile Platform Server sends a noti cation to a device via APNS, the underlying network layers resolve the host address
using the hosts le, which references the load balancer.
Getting Started
Get started with SAP Mobile Platform Server by rst performing post installation tasks, then starting the server and logging in to and
using Management Cockpit.
Starting and Stopping SAP Mobile Platform Server

Start SAP Mobile Platform Server to access the services that it provides.
Getting Started with Management Cockpit
Use Management Cockpit to manage server logs and features, and to manage and monitor native, hybrid, Mobile BI, and Agentry
mobile applications.
Activating Sample Data for ESPM
You can use reference data as a test back end for running sample applications. There are sample applications available on SAP
GitHub. The Enterprise Sales and Procurement Model (ESPM) is a simple business model scenario for developing a retail
business. It is based on the Enterprise Procurement Model (EPM). In this scenario, the datasource is a JPA model for ESPM Java.
Starting and Stopping SAP Mobile Platform Server

Start SAP Mobile Platform Server to access the services that it provides.
Starting and Stopping SAP Mobile Platform Server on Windows

You can start and stop SAP Mobile Platform Server on Windows in different ways.
Starting and Stopping SAP Mobile Platform Server on Linux
Start and stop SAP Mobile Platform Server on Linux through a terminal window.
Starting and Stopping SAP Mobile Platform Server on Windows

You can start and stop SAP Mobile Platform Server on Windows in different ways.
 Note
If you are using a custom database with SAP Mobile Platform, starting and stopping SAP Mobile Platform Server has no effect on the
database. Only the default SAP SQL Anywhere database is automatically stopped and started in sync with SAP Mobile Platform
Server.
5/12/2023
Starting SAP Mobile Platform Server

Use any of these methods to start SAP Mobile Platform Server:
Desktop shortcut – double-click the Start SAP Mobile Platform Server icon on the Windows desktop.
Windows Start menu – select Start All Programs/apps SAP Mobile Platform Server 3.0 Start SAP Mobile Platform Server
.
Windows Services Control Panel – start the SAP Mobile Platform Server service.
Server start-up may take several minutes.
Check the server log at <SMP_HOME>\Server\log\<host_name>-smp-server.log. The server has not fully started until this line
appears in the server log:
The SMP server has initialized and is ready.
Stopping SAP Mobile Platform Server

Use any of these methods to stop SAP Mobile Platform Server:
Desktop shortcut – double-click the Stop SAP Mobile Platform Server icon on the Windows desktop.
Windows Start menu – select Start (All) Programs SAP Mobile Platform 3.0 Stop SAP Mobile Platform Server .
Windows Services Control Panel – stop the SAP Mobile Platform Server service.
Starting and Stopping SAP Mobile Platform Server on Linux

Start and stop SAP Mobile Platform Server on Linux through a terminal window.
 Note
If you are using a custom database with SAP Mobile Platform, starting and stopping SAP Mobile Platform Server has no effect on the
database. Only the default SAP SQL Anywhere database is automatically stopped and started in sync with SAP Mobile Platform
Server.
Starting SAP Mobile Platform Server

You must manually start SAP Mobile Platform Server each time you restart the host system.
Open a terminal window, navigate to <SMP_HOME>/Server/, and run go.sh.
To run the server in the background, run go.sh --background.
The server has not fully started until you see the message: The SMP server has initialized and is ready.
When you run go.sh, server log is redirected to the <SMP_HOME>/Server/log/<host_name>.<domain>-smp-

server.log le; stdout is not redirected. For troubleshooting, you can run go.sh -clean to clear the OSGi cache before
starting the server.
Stopping SAP Mobile Platform Server

1. Open a terminal window.
2. Go to <SMP_HOME>/Server/.
5/12/2023
3. Execute stop.sh.
Getting Started with Management Cockpit

Use Management Cockpit to manage server logs and features, and to manage and monitor native, hybrid, Mobile BI, and Agentry mobile
applications.
Starting and Stopping Management Cockpit on Windows

You can start and stop Management Cockpit in different ways.
Starting and Stopping Management Cockpit on Linux
Start and stop Management Cockpit through a browser window.
User Interface
Frequently used icons in Management Cockpit. Icon styles may vary slightly.
Setting Up Browser Certi cates for Management Cockpit Connections
To avoid security exceptions when launching Management Cockpit, set up security certi cates correctly.
Starting and Stopping Management Cockpit on Windows

You can start and stop Management Cockpit in different ways.
 Note
SAP Mobile Platform Server must be started before you can start Management Cockpit.
Starting Management Cockpit from Any Computer on the Network

On any computer on the network, in a supported browser, enter: https://<host_name>:<https_admin_port>/Admin/, then log
in with the administrative user name and password.
Starting Management Cockpit on the Server Host

On the server host, you can also use any of these options to start Management Cockpit, then log in with the administrative user name
and password:
Desktop icon – double-click the SAP Management Cockpit icon on the Windows desktop.
Windows Start menu – select Start (All) Programs SAP Mobile Platform Server <version> Management Cockpit .
Web browser – in a supported browser, enter: https://localhost:<https_admin_port>/Admin/
 Note
In a clustered server environment, some Management Cockpit activities must be performed on each node in the cluster. Connect to
each node through a browser, using the host name and port for the node to which you want to connect.
Stopping Management Cockpit

To stop Management Cockpit, click the Logout icon, in the upper right corner.
Related Information
HTTP/HTTPS Port Number Reference
5/12/2023
Starting and Stopping Management Cockpit on Linux

Start and stop Management Cockpit through a browser window.
 Note
SAP Mobile Platform Server must be started before you can start Management Cockpit.
Starting Management Cockpit

Use either of these methods:
In a browser on any computer on the network, enter:
https://<host_name>.<domain>:<https_admin_port>/Admin/
In a browser on the system where SAP Mobile Platform Server is installed, enter:
https://localhost:<https_admin_port>/Admin/
 Note
In a clustered server environment, you must perform some Management Cockpit activities on each node in the cluster. Connect to
each node through a browser, using the host name and port for the node to which you want to connect.
Stopping Management Cockpit

To stop Management Cockpit, click the Logout icon in the upper-right corner.
Related Information
HTTP/HTTPS Port Number Reference
User Interface
Frequently used icons in Management Cockpit. Icon styles may vary slightly.
Management Cockpit Icons
Icon Purpose Description
Toggle Menu Toggle between showing and hiding the navigation menu in the left pane. Display the menu
for fast, easy navigation; hide it to maximize the window area.
Home Go to the Management Cockpit home screen. Links to frequently used tasks, and useful
information are provided, and current event log XML les are available.
 Note
You may need to con gure Internet Explorer 11 to view the XML event log les:
1. Go to Internet Options Content Feeds and Web Slices Settings .
2. Uncheck "Turn on feed reading view".
About View information about the platform.
Help Access online documentation on the help portal.
5/12/2023
Icon Purpose Description
User Pro le View current user information.
Log Out Log out of the application.
Create De ne a new resource, such as an application or a connection.
Action Settings View a list of available actions, such as Overview, Con gure, Delete, Ping, Export, and
Publish/Unpublish.
Import Import the resource le.
New Add a new item, for example, a connection, a provider, or a feature restriction policy.
Ping Ping a back-end connection.
Sort Sort a list based on criteria you choose, such as ascending or descending order, or the
column name.
Details SortOpen a dialog to see details of the selected resource.
Settings Open a dialog to edit resource settings.
Setting Up Browser Certi cates for Management Cockpit

Connections
To avoid security exceptions when launching Management Cockpit, set up security certi cates correctly.
Context
This task is required when:
The browser session starts from a host computer that is remote from the Management Cockpit installation.
The browser session starts on the same computer as Management Cockpit, and reports a certi cate error. The installer
automatically sets up a local security certi cate, but the certi cate installed for HTTPS in the Web container keystore is a self-
signed root certi cate, which is not recognized by the client browser.
The host computer does not have Visual Studio Certi cate Manager SDK installed.
Follow the steps below to add the certi cate to the Windows certi cates store. Alternatively, follow browser-speci c instructions to
accept the certi cate into the Windows certi cates store.
Procedure
1. Extract the self-signed certi cate:
SMP_HOME\JDK<X.X.X_XX>\bin\keytool.exe -exportcert -alias jetty

-keystore SCC_HOME\services\EmbeddedWebContainer\keystore -file cert.crt
2. Click Start Run , type mmc, and then click OK to import the cert.crt le into the host computer’s Windows store with the
Windows Certi cate Manager. The default password for both the keystore and the alias is "changeit".
Activating Sample Data for ESPM

You can use reference data as a test back end for running sample applications. There are sample applications available on SAP GitHub.
The Enterprise Sales and Procurement Model (ESPM) is a simple business model scenario for developing a retail business. It is based on
the Enterprise Procurement Model (EPM). In this scenario, the datasource is a JPA model for ESPM Java.
5/12/2023
Prerequisites
A security pro le for the namespace 'sap'.
Access to SAP GitHub for downloading samples at http://sap.github.io
Context
To activate the sample data for ESPM:
Procedure
1. In Management Cockpit, select OData Services Services .
2. Con gure the JPA destination for the ESPM service:
a. Select the Destinations tab.
b. Click New and enter:
Configuration Values for New Destination
Field Description
Destination Name A destination name of your choice for Espmservice, for example,
ESPMDestination
Destination Type JPA
<URLt> com.sap.espm.model
<Authentication Type> Basic Authentication
c. Click Save.
3. Assign the destination ESPMDestination for the service or for entity sets. See Assigning and Removing Destinations.
4. Activate the Espmservice service:
a. Go to the Services tab, and verify that ESPMDestination is the default destination for Espmservice.
b. Select the Espmservice row and click Activate/Deactivate to activate the Espmservice.
Related Information
Creating and Con guring Security Pro les
Application Administration
Use Management Cockpit and other tools to manage and monitor native, hybrid, Web, Mobile business intelligence (Mobile BI), and
Agentry mobile applications. Managing includes de ning and con guring applications; monitoring applications and application usage;
viewing statistics and logs; checking system health; and troubleshooting problems.
Native (online and offline), hybrid (Kapsel), Web, Mobile BI, and Agentry (offline) applications are developed using a variety of tools and
methods. SAP development tools help facilitate development of mobile apps, with modularized methods for download, logon, push
noti cation, and error reporting. During the development process, a unique application identi er is generated for each application, and
the application is deployed to an application download site or SAP Mobile Platform Server.
The administrator creates an application de nition in Management Cockpit, which includes the unique application identi er, plus the
connection to its back-end data source in the production system, the security con guration, and application-speci c entries. For Agentry
applications, settings are also made in con guration les. This de nition enables applications to communicate with SAP Mobile Platform
Server.
5/12/2023
The administrator provisions applications to devices through native application stores, through enterprise Web site downloads, or
through Afaria. When a user logs in to an application (or accesses the application as an anonymous user), the application+user+device
combination is registered in Management Cockpit. This registration enables you to manage and monitor device applications in the eld
using Management Cockpit, and to take advantage of individual and aggregate usage statistics. For Agentry applications, the user enters
an Agentry application URL from the device client to access the application. Use Agentry logs to monitor and manage the application in
the eld.
Deploying Applications
Create an application de nition that enables you to manage the application using Management Cockpit. The application de nition
must include a unique application identi er, connections to the back-end data source, and security pro le settings. You can make
additional application-speci c changes.
Managing and Monitoring Applications
Use Management Cockpit to manage applications, registrations, users, back-end connections to the data source; manage security
pro les; view application usage statistics; and manage and view application reports.
Provisioning Applications
Provision the application to supported devices so users can install and log in to the application to register with SAP Mobile
Platform Server. You can provision applications through native application stores, through enterprise Web site downloads, or
through Afaria.
Related Information
Server Administration
Security Administration
Application Services (Mobiliser) Administration
SMS Administration
Deploying Applications
Create an application de nition that enables you to manage the application using Management Cockpit. The application de nition must
include a unique application identi er, connections to the back-end data source, and security pro le settings. You can make additional
application-speci c changes.
1. De ning Applications
Create a new native, hybrid, Web, Mobile BI, or Agentry application de nition, which enables you to use Management Cockpit to
manage the application.
2. De ne Back-End Connections
De ne a back-end connection for the selected application. A back-end connection is a connection to the data source, or enterprise
3. De ning Application Authentication

Assign a security pro le to the selected application. The security pro le de nes parameters that control how the server
authenticates the user during onboarding, and request-response interactions with the back end.
4. De ning Client Policies

Set policies that are related to client password and log management for the selected application. For hybrid apps, set feature
restriction policies.
5. De ning Push Noti cations

(Optional) Con gure push-related settings for the selected application. The push listener service provided with SAP Mobile
Platform Server allows back-end systems to send native noti cations to devices. The application developer must have enabled
push noti cation code in the application to use this option.
6. Uploading Client Resources

(Applies only to native, hybrid, and Agentry) Upload client resources, or resource bundles, for the selected application. Resource
bundles are containers used by applications to download dynamic con gurations, styles, or content from the server. The
application developer must set up the capability to use client resource bundles through the OData SDK or REST API SDK, before
the administrator can modify settings in Management Cockpit.
7. De ning Application-Speci c Settings

(Optional, applies only to hybrid and Agentry) Con gure application-speci c settings for the selected application, using
Management Cockpit, con guration les, or other tools.
5/12/2023
8. De ning Offline Application Settings
De ne offline settings for the selected application. Offline support enables client applications to access back-end data without
requiring a connection. Offline applications access data from an offline store on the client. The server moves data between the
back end and the client offline store.
9. Saving Application Settings

Save the application settings.
Related Information
De ning Access Control Policies
Deploying from a Preproduction Environment

The developer and administrator must coordinate to deploy applications from the development or test environment to the production
environment.
Hybrid Apps
To deploy hybrid apps to the production environment:
1. (Administrator) On the preproduction server, select the app in Management Cockpit, and choose Export. This generates a ZIP le
that contains the app, and retains many of the app settings.
2. (Administrator) In Management Cockpit, import the ZIP le to SAP Mobile Platform production server, and de ne the hybrid
application. If the hybrid app uses the AppUpdate plugin, use the App Speci c Settings tab to manage the app version.
3. (Administrator) Continue using Management Cockpit to complete hybrid app con guration tasks in the production environment;
for example, you must set security provider settings as they are not retained as part of the export/import process. Once the
application is de ned and con gured on the server, application users can log in to the client-side application to register the
application with the server, and start using the application and resources from the server.
Native Applications
To deploy native applications to the production environment:
1. (Developer) Deploy the application to the devices.
2. (Administrator) Use Management Cockpit to complete native application con guration tasks in the production environment. Once
the application is de ned and con gured on the server, application users can log in to the client-side application to register the
Web Applications
To deploy Web applications in the production environment:
1. (Developer) Deploy the application to the devices.
2. (Administrator) Use Management Cockpit to complete Web application con guration tasks in the production environment. Once
the application is de ned and con gured on the server, application users can log in to the Web application to register the
Agentry Applications
To deploy Agentry applications to the production environment:
1. (Administrator) In Management Cockpit, de ne the Agentry application. If you are publishing an update to an existing application,
you do not need this step.
5/12/2023
2. (Developer) Use Agentry Editor to publish the application. The publishing process creates the ZIP le, which contains production
de nitions and any other les the developer included.
3. (Administrator) In Management Cockpit, complete any additional Agentry application con guration tasks for the production
environment; use the App Speci c Settings tab to publish the ZIP le.
The ZIP le is uploaded through the browser to the SAP Mobile Platform Server, and is published. You are noti ed of success or
failure.
4. (Administrator) Once the application is de ned and con gured on the server, application users can log on to the client-side
application to register the application with the server, and start using the application and resources from the server.
 Note
if you are publishing an update to an existing application, additional steps may be needed. See Updating Agentry Con guration
Settings.
Parent topic: Deploying Applications
Next task: De ning Applications
Related Information
De ning Applications
Publishing Agentry Apps
Importing an Application Con guration
Con guring a Production Environment for Deployment

The administrator must complete several prerequisite con guration tasks before deploying applications into the production
environment.
 Note
Work with back-end system and security administrators as needed to complete prerequisite con guration tasks.
Server Con guration

Con gure SAP Mobile Platform to support application deployment. Tasks include setting up back-end communications, and push
noti cation.
Task Task Overview
Set up communications between SAP Mobile Platform Server and your Setting up Back-end Communications
back-end systems.
Con gure the push noti cation base URL and SOCK proxy properties to Server Con guration: System
enable back-end systems to send noti cations to SAP Mobile Platform
Server.
Security Con guration

Plan and implement platform security before deploying applications into the production system. Tasks include planning your security
strategy, setting up levels of security from server to device, and setting up security pro les.
Task Task Overview
5/12/2023
Task Task Overview
Plan your SAP Mobile Platform security landscape, using the security Planning Your Security Landscape
support matrices to plan your strategy and make decisions.
Secure your SAP Mobile Platform Server installation as soon as possible SAP Mobile Platform Authentication Quick Start
after installation, using the quick starts as a guide.
Con gure security pro les and authentication providersand map Con guring Security Pro les and Authentication Providers in SAP Mobile
physical roles to logical roles Platform
Role Mapping
Production Environment Deployment Tasks By Application Type

Many application deployment tasks are the same for all application types. However, there are some tasks that are different or do not
apply.
 Note
Work with developers to complete prerequisite deployment tasks.
Task Native Hybrid Web Mobile BI Agentry
De ne applications De ning Applications De ning Applications De ning Applications De ning Applications De ning Applications
De ne back-end De ning Back-end De ning Back-end De ning Back-end De ning Back-end De ning Back-end
connections Connections Connections Connections Connections Connections for Agentry
De ne application De ning Application De ning Application De ning Application De ning Application De ning Application
authentication Authentication Authentication Authentication Authentication Authentication
Web Application
Authentication
Samples
De ne client De ning Client De ning Client Not applicable De ning Client Not applicable
password policy Password Policy Password Policy Password Policy
De ne push Con guring Push for Con guring Push for Not applicable Con guring Push for Con guring Push for
noti cations Native and Hybrid Native and Hybrid Native and Hybrid Agentry
Upload client Uploading Client Not applicable Not applicable Uploading Client Not applicable
resources Resources Resources
De ne application- Not applicable Not applicable Not applicable Publishing Agentry Apps
speci c settings
Con guring Agentry
Settings
Updating Agentry
Con guration Settings
Restarting an Agentry
Application
Localizing Agentry
Applications
De ne offline De ning Offline De ning Offline Not applicable De ning Offline Not applicable.
application settings Application Settings Application Settings Application Settings
5/12/2023
Save application Saving Application Saving Application Saving Application Saving Application Saving Application
settings Settings Settings Settings Settings Settings
Create a new native, hybrid, Web, Mobile BI, or Agentry application de nition, which enables you to use Management Cockpit to manage
the application.
Procedure
1. In Management Cockpit, select Applications, and click .
2. In the Create Application window, enter:
Field Value
Application ID Unique identi er for the application, in reverse-domain notation. This is the application or bundled
identi er that is assigned or generated by the application developer. The administrator uses the
application ID to register the application with SAP Mobile Platform, and client applications use the
Application ID when sending requests to the server.
An Application ID:
Must be unique
Must start with an alphabetic character
Can contain only alphanumeric characters, underscores, and periods
Can contain up to 64 characters
Cannot include spaces
Cannot begin with a period, and cannot contain two consecutive periods
Cannot be any of these case-sensitive keywords: Admin, AdminData, Push, smp_cloud,

resource, test-resources, resources, Scheduler, odata, applications,
Connections, public, lcm
SAP recommends that application IDs contain a minimum of two periods, for example,
com.sap.mobile.app1.
Version Application version.
Name Application name can contain only alphanumeric characters, spaces, underscores, and periods, and be
up to 80 characters long.
Type Application type.
Native – native applications, including Android, BlackBerry, iOS, and Windows Applications.
Hybrid – Kapsel container-based applications.
Web – application that runs in a Web browser.
Agentry – metadata-driven applications.
MobileBI – SAP BusinessObjects Business Intelligence applications.
Description (Optional) The description can contain up to 255 alphanumeric and special characters, but cannot
contain percent signs or ampersands.
5/12/2023
Field Value
Vendor (Optional) Vendor who developed the application. The vendor name can contain only alphanumeric
characters, spaces, underscores, and periods, and can be up to 255 characters long.
Registration Threshold The registration threshold in seconds for the application. Leave blank (default) or set to 0 to remove
threshold. Set a threshold value from 1 ‒ 2147483647. If the number of incoming registration requests
per second exceeds the value, requests are throttled and the server generates HTTP error code "429
TOO MANY REQUESTS".
Online Request Threshold The online request threshold in seconds for the application. Leave blank (default) or set to 0 to remove
threshold. Set a threshold value from 1 ‒ 2147483647. If the number of incoming online requests
exceeds the value, requests are throttled and the server generates HTTP error code "429 TOO MANY
REQUESTS".
Offline Request Threshold The offline threshold in seconds for the application. Leave blank (default) or set to 0 to remove
threshold. Set a threshold value from 1 ‒ 2147483647. If the number of incoming offline requests
exceeds the value, requests are throttled and the server generates HTTP error code "429 TOO MANY
REQUESTS".
Enable CSRF Protection Enable protection against cross-site request forgery (CSRF) attacks for the selected application. This
option protects all services, such as registration, with CSRF tokens. Proxied endpoints are not protected,
since they may be protected on the back end.
Ignore Case for User Name (Not available for Agentry application type) By default, the server uses case-sensitive matching to
compare registered user names for subsequent application access, to ensure that the connection is not
shared by different users, and for push noti cation.
Select this option to use case-insensitive matching for this application. This is useful when the server
processes push noti cations for Fiori applications that expect user names to be matched case-
insensitively, as in ABAP systems.
Security Pro le Name Select a security pro le from the list.

A security pro le protects application resources. See Con guring Security Pro les and Authentication
Providers.
3. Click Save. You see application-related tabs, such as Information, Back End, Authentication, Push, and so forth. The tabs you see
differ by application type. You are ready to con gure the application, based on the application type.
Task overview: Deploying Applications
Next: De ne Back-End Connections
Related Information
Con guring an Application to Use X.509 and an SAP Gateway Service
De ne Back-End Connections
De ne a back-end connection for the selected application. A back-end connection is a connection to the data source, or enterprise

For the selected application, de ne its back-end connections. The server supports one primary endpoint per application ID. An
administrator can create multiple secondary endpoints for services used by the application; secondary endpoints are similar to
proxy connections.
5/12/2023
De ne back-end connections for the selected Agentry application after publishing the application. Before then, the Back End tab is
blank. The application developer creates initial back-end connection settings during development, and then publishes the
application to SAP Mobile Platform Server. Once you publish the application, you must modify the initial back-end connection
values for the SAP Mobile Platform environment.
Previous task: De ning Applications
Next task: De ning Application Authentication

For the selected application, de ne its back-end connections. The server supports one primary endpoint per application ID. An
administrator can create multiple secondary endpoints for services used by the application; secondary endpoints are similar to proxy
connections.
Context
For applications that access a Web service containing relative URLs, add the relative paths to enable the server to handle requests
correctly.
Procedure
1. In Management Cockpit, select Applications Con gure Back End .
2. Enter values for the selected application:
Field Value
Back-End The URL the application uses to access business data on the back-end system or service. This can be a back-end
URL connection, or a service document, usually in the following format:
http://<host>:<port>/gateway/odata/<namespace>/<Connection_or_ServiceName>.../
For a service, the service document URL is the document destination you assigned to the service in SAP Gateway. Include a
trailing forward slash to avoid triggering a redirection of the URL, and losing important HTTP header details. This is
especially important when con guring the application with security such as SSOToken and Certi cates, and when Rewrite
URL in SMP or Rewrite URL in Backend System is selected as the rewrite mode.
 Note
If you select to rewrite the URL, it cannot include a reserved pattern. See URL Rewrite Modes.
Internal White list a service that you create in SAP Mobile Platform. If you de ne an endpoint as internal, the host name and port of
the back-end URL are ignored, and incoming requests are forwarded to internal services in-process, without another HTTP
call to localhost. An example of an internal service is Integration Gateway.
5/12/2023
Field Value
Allow (Optional) If enabled, the user can access the application without entering a user name and password. However, back-end
Anonymous systems still require login credentials for data access, whether it is a read-only user, or a back-end user who is assigned
Access speci c roles.
If enabled and the back end requires it, enter the login credentials to access the back-end system:
User name – the user name for the back-end system.
Password – (required if you enter a user name) the password for the back-end system.
If disabled (the default) or the back end does not require it, you need not provide these credentials.
 Note
If you allow anonymous access for a native OData application, do not assign the No Authentication Challenge security
pro le to the application; anonymous OData requests are not sent, and status code 401 is returned.
Maximum (Optional) The number of back-end connections that are available for connection pooling for this application. The larger the
Connections pool, the larger the number of possible parallel connections to this speci c connection. For primary endpoints, the default
and minimum is 500 connections. Consider the following factors when resetting this property:
The expected number of concurrent users of the application.
The load that is acceptable to the back-end system.
The load that the underlying hardware and network can handle.
Increase the maximum number of connections only if SAP Mobile Platform Server hardware can support the additional
parallel connections, and if the underlying hardware and network infrastructure can handle it.
To disable connection pooling, set this value to 0. Disable connection pooling only if the back-end system does not support
pooled connections, as disabling connection pooling may have a negative impact on processing times.
Timeout in The number of milliseconds before the back-end connection times out. If set to 0, the JVM timeout value is used.
Milliseconds
Online The threshold value to throttle incoming online requests per second for a connection. Leave blank (default) or set to 0 to
Request remove threshold. Set a threshold value from 1 ‒ 2147483647.
Threshold
Certi cate Optional if the Endpoint URL begins with HTTPS.

Alias If the back-end system has a mutual SSL authentication requirement, select the certi cate alias name of the private key and
technical-user certi cate that can access the back-end system. The certi cates are located in the shared keystore
smp_keystore.
Rewrite Select one of:

Mode Rewrite URL on SMP – in request and response messages, the server replaces all back-end URLs with the server
URL.
Rewrite URL on Back End – the back end rewrites the URLs. The server forwards its host name and port to the back
end in an HTTP header, and the back end creates the URL to retrieve back-end entities.
Select Via HCP App to use the x-forwarded-for header value; or leave it unselected to use the default Host
header.
No Rewriting – request and response messages are not modi ed; the server passes messages directly between
clients and back-end systems.
 Note
SAP Mobile Platform Server does not provide the functionality to use No Rewriting mode to support external back
ends for offline usage.
See URL Rewrite Modes.
5/12/2023
Field Value
Relative (Only if Rewrite Mode is Rewrite URL on SMP) If an application requires data from a back end that uses relative URLs,
Path con gure those relative URL patterns here.
The server rewrites relative URLs to include the connection ID (connection name), enabling access to the back-end data. For
example, a Web service application requests an HTML page named abc.html, which contains the relative URLs /sap/bc
and /sap/public/bc in its src or href tags. When a request is made, the server rewrites the relative URLs in the
response, so that subsequent requests to these relative URLs are processed correctly.
For example, if "webApp" is the connection name and the response contains the relative URLs /sap/bc and
/sap/public/bc, the server rewrites these relative URLS to /webApp/sap/bc and /webApp/sap/public/bc.
Without the relative URLs, the request cannot be processed.
To add relative paths, enter a comma-delimited list of relative URLs, for example, /sap/bc,/sap/public/bc.
Virus The server scans incoming traffic for viruses.

Scanning of
Incoming
Traffic
Virus The server scans outgoing traffic for viruses.

Scanning of
Outgoing
Traffic
SSO (Optional) You can add one or more SSO mechanisms, and prioritize them. The runtime calls the rst SSO mechanism for
Mechanisms which corresponding user credentials are available. Only one SSO mechanism is used per connection attempt. If a
connection fails, the server invalidates the client session and requires reauthentication.
Click the Create icon , select an SSO Mechanism, and click Save.
To change the order in which an SSO mechanism is used, select it, and click or .
See Single Sign-On Mechanisms.
Application To add a secondary application connection, click , and in the Create Connection dialog, enter the property values, as you
Connections did for the primary connection, and then click Save.
To enable or disable back-end connections for the application, click the Settings icon , and for each connection, select or
deselect Enabled for Application.
3. Click Save. The new back-end connection is added to the list.
You can maintain the list of server-level back-end connections (including all the connections in SAP Mobile Platform Server), and
of application-speci c back-end connections. Application-speci c back-end connections are the secondary connections that are
enabled for an application; by default, no secondary connections are enabled. You must explicitly enable additional back-end
connections for an application. Users who are registered to an application can access only these back-end connections. Users
cannot access back-end connections (request-response) that are not enabled for an application.
4. To see the back-end connections that are enabled for the application, select .
 Note
You can authenticate multiple back ends using various authentication provider options in the security pro le.
If the back-end system issues a 302 Redirect or 307 Redirect response, which means it is redirecting the request
to a different URL, add the target URL to the list of application-speci c connections.
5. (Optional) To delete a saved connection, from the Home screen, select Connections, select the connection, and click the Delete
icon .
Custom SSO Mechanism Samples

Custom single sign-on (SSO) mechanisms provide a exible way for customers to construct HTTP headers and cookies to send to
the back end. Typically, you con gure a custom SSO mechanism to support custom SSO schemes. The SAP Mobile Platform
administrator who con gures a back-end endpoint must understand how that back-end system processes SSO requests.
Endpoint Reserved Patterns
5/12/2023
If you rewrite an endpoint value for an application back-end connection, do not use a reserved pattern.
Related Information
Certi cate Alias and HTTPS Connections
Certi cates and Keys
Server Con guration: System
Con guring an Application to Use X.509 and an SAP Gateway Service
URL Rewrite Modes
Single Sign-On Mechanisms
Principal Propagation Con guration Properties
Custom SSO Mechanism Samples

Custom single sign-on (SSO) mechanisms provide a exible way for customers to construct HTTP headers and cookies to send to the
back end. Typically, you con gure a custom SSO mechanism to support custom SSO schemes. The SAP Mobile Platform administrator
who con gures a back-end endpoint must understand how that back-end system processes SSO requests.
Custom Cookies and Headers

Custom cookies and headers enable SAP Mobile Platform to send one or more HTTP headers or cookies to the back end. An SAP Mobile
Platform administrator can de ne a cookie or header with a name and a pattern. A pattern can be a constant value, a named credential,
or a method expression.
Constant value – in this example, SAP Mobile Platform Server sends an HTTP request to the back end with the header
Authorization: Basic cc21wQWRtaW46czNwQWRtaW4=
Name: Authorization, Pattern: Basic c21wQWRtaW46czNwQWRtaW4=, Type: Header
Named credential – this example is a generalization of an the existing SSO2 mechanism. When an administrator de nes a custom
cookie with the name MYSAPSSO2, and the pattern ${MYSAPSSO2}, the results are the same as the SSO2 mechanism. The
pattern string is a placeholder, similar to a variable. At runtime, SAP Mobile Platform Server searches for a credential with a
name that matches the pattern string, gets its value, and substitutes it for the pattern string.
Name: MYSAPSSO2, Pattern: ${MYSAPSSO2}, Type: Cookie
The following example has the same effect as using the existing X.509 SSO mechanism:
Name: SSL_CLIENT_CERT, Pattern: ${java.ssl.SSL_CLIENT_CERT}, Type: Cookie
Method expression – SAP Mobile Platform Server tries to execute the method at runtime. If successful, the server substitutes the
pattern with the value that is returned by the method invocation, in this example, Negotiate 89a8742aa8729a8b028
Name: Authorization, Pattern: Negotiate ${spnego.getTicket(app1Realm, app1Service)}, Type: Header
SiteMinder Sample
If a back-end system is protected by a SiteMinder Web agent, an SMSESSION cookie can provide the SSO that is required. You can
con gure the HTTP/HTTPS Authentication provider in various ways to validate or obtain an SMSESSION cookie, which the provider can
attach to the JAAS Subject as a NamedCredential, and forward to the back end. For example:
Name: SMSSESSION, Pattern: ${SMSESSION}, Type: Cookie
5/12/2023
In this example, SAP Mobile Platform Server searches the NamedCredential type credentials attached to the JAAS Subject to nd one
with a name that matches the pattern string, and substitutes it into the pattern string as the value to send to the back end, in this case,
a cookie named "SMSESSION". This is a more exible way of sending custom SSO material than in prior SAP Mobile Platform versions.
OAuth Authentication Sample

If the HTTP/HTTPS Authentication provider can access an identity management (IdM) system, the HTTP/HTTPS Authentication provider
can send client credentials to the IdM, which authenticates the client and returns an SSO token as a cookie; the HTTP/HTTPS
Authentication provider can then save the token as a NamedCredential. The SSO token may be an OAuth token, which is part of a
standard SSO mechanism that is rapidly gaining acceptance.
OAuth authentication can reuse the HTTP/HTTPS Authentication header that is already being used for Basic and Kerberos
authentication, but it must look like Authentication: Bearer <OAuth token in base-64>.
Name: Authorization; Pattern: BEARER ${oauthToken}, Type: Header
In this example, accessing the back end using SSO via OAuth requires that you save the OAuth token that is sent back to the
HTTP/HTTPS Authentication provider as a credential named "oauthToken."
Endpoint Reserved Patterns

If you rewrite an endpoint value for an application back-end connection, do not use a reserved pattern.
If you select Rewrite URL in SMP, the endpoint name may not be any of these reserved words:
Admin
btx
bundles
clientlogs
gateway
hmadmin
it
lcm
log les
MobiLink
Noti cation
odata
public
resources
restnoti cation
SAMLAuthLauncher
smp
tenantadmin
xsutils
5/12/2023
If you select Rewrite URL in Backend System, the URL path may not start with any of these reserved patterns:
/Admin/**
/btx/**
/bundles/**
/clientlogs/**
/gateway/**
/hmadmin/**
/it/**
/lcm/**
/log les/**
/MobiLink/**
/Noti cation/**
/odata/**
/public/**
/resources/**
/restnoti cation/**
/SAMLAuthLauncher/**
/smp/**
/tenantadmin/**
/xsutils/**

De ne back-end connections for the selected Agentry application after publishing the application. Before then, the Back End tab is blank.
The application developer creates initial back-end connection settings during development, and then publishes the application to SAP
Mobile Platform Server. Once you publish the application, you must modify the initial back-end connection values for the SAP Mobile
Platform environment.
Communication between SAP Mobile Platform Server and the back-end system is represented within the application by the back-end
connection type. Each type of back end has its own con guration options. Back-end connection types include:
SQL database connections (both Microsoft SQL Server and Oracle) – between the Agentry application and a single SQL database
Java Virtual Machine connections – between the Agentry application and custom code (use this option to connect to SAP from
Agentry via custom Java code)
HTTP-XML Server (Web Service) connections – between the Agentry application and an XML-based Web service (use this option
to connect to SAP from Agentry via web services)
OData connections – between the Agentry application and OData back-end service.
File system connections – between the Agentry application and a le system
 Note
Before your Agentry application can communicate with some back-end systems, you need to set up Agentry application host server
connectivity.
5/12/2023
Con guring SQL Back-end Connections for Agentry Applications

The rst time you publish an application from Agentry Editor, the publication process creates initial back-end con guration
information, which you must modify using Management Cockpit. Before modifying the con guration information for a SQL
database back-end connection, you need to research and gather information about the database.
Con guring Java Virtual Machine Back-end Connections for Agentry Applications
information, which you must modify using Management Cockpit. Use the Java Virtual Machine option to connect from an Agentry
application to custom code (for example, you could connect to SAP from Agentry via custom Java code). Before modifying the
con guration information for a Java Virtual Machine database back-end connection, you need to research and gather information
about the database. Certain tasks may or may not pertain to a particular implementation environment and you should perform a
careful review of the application’s requirements and functionality before proceeding.
Con guring HTTP-XML Back-end Connections for Agentry Applications
information, which you must modify using Management Cockpit. Use the HTTP-XML option to connect from an Agentry
application to an XML-based Web service (for example, you could connect to an SAP Web service back end). After modifying the
con guration information in Management Cockpit, you may need to perform additional con guration tasks. Certain tasks may or
may not pertain to a particular implementation environment and you should perform a careful review of the application’s
requirements and functionality before proceeding.
Con guring OData Back-end Connections for Agentry Applications
information, which you must modify using Management Cockpit. Use the OData option for an Agentry application that access an
OData back-end service. Certain tasks may or may not pertain to a particular implementation environment and you should
perform a careful review of the application’s requirements and functionality before proceeding.
Con guring File System Back-end Connections for Agentry Applications
For Agentry applications that communicate over a le system connection, use Management Cockpit to con gure the SAP Mobile
Platform Server to connect to the host system. Certain tasks may or may not pertain to a particular implementation environment
and you should perform a careful review of the application’s requirements and functionality before proceeding.
Related Information
Localization Files
Con guring SQL Back-end Connections for Agentry Applications

The rst time you publish an application from Agentry Editor, the publication process creates initial back-end con guration information,
which you must modify using Management Cockpit. Before modifying the con guration information for a SQL database back-end
connection, you need to research and gather information about the database.
Prerequisites
Obtain and record the back-end identi er of the SQL database system connection. This is the name or number de ned in the
Agentry Editor.
Obtain or create the user ID and password to be used to connect SAP Mobile Platform Server to the database system.
Obtain information about, or create and con gure the necessary connection settings on the host system for, SAP Mobile Platform
Server application. This may be the System Data Source Name within ODBC for a SQL Server database, or the Local Net Service
Name for an Oracle database.
Determine whether to authenticate users during synchronization via security information provided by the database.
Context
5/12/2023
After modifying the con guration information in Management Cockpit, you may need to perform additional con guration tasks. Certain
tasks may or may not pertain to a particular implementation environment and you should perform a careful review of the application’s
requirements and functionality before proceeding.
Procedure
2. Under SQL-<n>, edit SQL-related settings. These con guration options are for a single SQL database system connection, and
control the connection behavior between the server and a database system. There may be multiple SQL-<n> sections within the
Agentry.ini le. There must be one such section for each SQL database system connection de nition within the application.
Replace the <n> portion of the section name with the ID value generated by the Agentry Editor for the system connection
de nition.
De nitions Values Descriptions
Allow User to Boolean value of true or Whether users can change expiring passwords on the client. If Enable Authentication is false,
Change false. Default: true. this setting has no affect.
Password
Database Text value with valid The TNS name (Oracle) or ODBC DSN name (such as SQL Server, or any kind of database
Connection system connection name. using an ODBC driver) the server uses to connect with the database.
Name Default: none.
Database Text value with valid The password for the user ID.
Connection password. Default: set
Password by installer.
Database Oracle or ODBC. Default: Whether the server is connecting to the database using an ODBC or Oracle Net Service Name.
Connection set by installer.
Type
Database Text value with valid user The user ID the server uses to log in to the database.
Connection ID.
User ID
Disconnect Boolean value of true or Whether the server should disconnect from the database at the time speci ed in Disconnect
from false. Default: false. Time. The value is set to true when the database performs periodic batch or other processing,
Database and when such processing dictates that no connections should be made to the database
system.
Disconnect 24-hour clock value in A speci ed time when the server disconnects from the database. This setting has no effect if
Time hours and minutes. Disconnect from Database is false.
Default: 2:30.
Enable Boolean value of true or Whether users are authenticated against the back-end system for this system connection. At
Authentication false. Default: true. least one system connection within the application must perform user authentication.
Enable Boolean value of true or Whether previous users are authenticated against the back-end system for this system
Previous User false. Default: true. connection. This authentication occurs when a user change occurs on the client.
Authentication
Name Text value. Default: null. Any text value used to identify the system connection in log les and other areas. This should
be set to a unique value.
Prefetch Rows 1000 Number of rows to retrieve in a single batch from a database query (can be used to optimize
speed).
Query Valid le name or path Name and location of the query constants le, relative to the server. The default for this setting
Constant File and le name. Default: depends on the type of database selected during installation:Oracle_sd.ini or
none. SqlServer_sd.ini.
Query Init File Valid le or path and le Name and location for the query initialization le used by this system connection. The
name to properly initialization le contains multiple sections related to various server events that use a
formatted query database system connection. The le must contain all of these sections in the proper format.
initialization le. Default:
SqlBE.ini.
5/12/2023
Reconnect 24-hour clock value in The time at which the server reconnects to the database; it must be later than Disconnect
Time hours and minutes. Time. This setting has no effect if Disconnect from Database is false.
Default: 4:00.
Shared Zero or positive integer Number of connections created by the server upon start-up. If greater than 0, a connection
Connections value. Default: 0. pool is created and data from a single client may be processed on any of these connections,
including multiple different connections during a single transmission. If set to 0, each client
transmission uses a single database connection from start to nish.
Time Zone Valid time zone name. The time zone to which date and time values are converted when received from clients; or from
Name which they are converted when sent to clients. This conversion is based on the application
de nitions. This setting is used only to specify a time zone that differs from the back-end
system.
User Boolean value of true or Whether the connection that authenticates the user is the same one that processes
Database false. Default: true. synchronization for that user. If false, the server uses a different connection.
Authorization
Connection
Next Steps
If you must modify these les, make the changes to the con guration les in the development environment, not on SAP Mobile Platform
Server, and publish a new ZIP le in Management Cockpit. Restart each server in the cluster to distribute the changes.
Make application-speci c modi cations to the SqlBe.ini con guration le.
Make application-speci c additions or modi cations to the query constants le, or create additional constants les.
Con guring the SqlBe.ini Query Initialization File for Agentry Applications
After con guring the SQL database back-end connections in Management Cockpit, you may need to make modi cations to the
SqlBe.ini con guration le. The SqlBe.ini is the default query initialization le that is provided by the server installer.
Con guring Query Constant Files for Agentry Applications
Query constant les are con guration les containing constant values that may be referenced by any SQL script run by SAP
Mobile Platform Server. Each SQL database system connection can have its own query constant le.
Con guring the SqlBe.ini Query Initialization File for Agentry

Applications
After con guring the SQL database back-end connections in Management Cockpit, you may need to make modi cations to the
SqlBe.ini con guration le. The SqlBe.ini is the default query initialization le that is provided by the server installer.
You can modify the le for all applications; or use it as a template to create custom query initialization les for multiple applications, or
for applications that have multiple SQL database system connection types.
 Note
By default, there is one SqlBe.ini le that is used server-wide for all applications. For application-speci c SqlBe.ini
con gurations, you can create a different SqlBe.ini le, and place it in the desired application's sql\custom directory.
To customize:
1. Make application-speci c changes to con guration les in the development environment, not on SAP Mobile Platform Server.
2. Perform a production publish in the Agentry Editor, which zips the application les in preparation for importing in to SAP Mobile
Platform Server. Be sure to include the con guration les in the project, in the application's directory structure, when you create
the ZIP le, See Developer > Agentry App Development , the Publishing to Product topic.
5/12/2023
3. Import the new ZIP le in Management Cockpit. See Administrator > Application Administration, the Importing an Application
Con guration topic.
Application-Speci c Changes
Query initialization les are generally set up initially by application developers, or as the result of development efforts and standard
application needs. Before making any changes to the settings, you should have a full understanding of how your changes might impact
application behavior. SAP recommends that, rather than changing the Query initialization le, you instead make your changes to the
scripts it references.
Any changes you make, either to the settings in this le or to those scripts it references, are generally the result of speci c
implementation requirements. Items such as user validation or auditing requirements can dictate when and what modi cations may be
necessary.
SQL Script Locations

The scripts referenced in the SqlBe.ini le must be located in one of two directories, both of which are subdirectories of the Agentry
Server within the SAP Mobile Platform installation location (for example,
SMP_HOME\Server\Configuration\com.sap.mobile.platform.server.agentry.application.<app_id>\):
sql
sql\custom
These two separate folders allow for both standard and customized processing. For an application implementation, the sql folder
contains the standard scripts that are provided with the application installer. Make a copy of each script before you make any changes to
it, and then save the new version in the sql\custom folder.
When processing scripts listed in the SqlBe.ini le, SAP Mobile Platform Server looks rst in the sql\custom folder. If a script is not
found in the \custom folder, SAP Mobile Platform Server then looks for the same le in the sql folder.
To return to default processing, simply move or rename the script le. The next time SAP Mobile Platform Server looks for the script, it
nds the default version, and executes it.
Sections Listing
The following is a list of the sections within this le and the events to which they relate:
[Misc] – do not modify this section; it contains two queries, used for internal purposes, that are executed by SAP Mobile
Platform Server.
[DbConnect] – a list of SQL scripts to be run when SAP Mobile Platform Server connects to the database. The connection is
made when SAP Mobile Platform Server is started, and also when SAP Mobile Platform Server reconnects to the database based
on the Disconnect from Database setting in Management Cockpit.
[DbDisconnect] – a list of SQL scripts to be run when SAP Mobile Platform Server disconnects from the database. This occurs
as a part of the SAP Mobile Platform Server shutdown process, and also when SAP Mobile Platform Server disconnects from the
database based on the Disconnect from Database setting in Management Cockpit.
[DbConnectionInit] – a list of SQL scripts that are run when SAP Mobile Platform Server creates a connection to the
database. This differs from the DbConnect section, in that DbConnectionInit scripts are run whenever SAP Mobile Platform
Server creates a new connection to the database, not just during start-up and reconnect. New connections may be made
whenever a user synchronizes the Agentry client, or when SAP Mobile Platform Server adds a connection to the shared
connections pool.
[ValidateUser] – a list of SQL scripts that validate a user against the database during client-server synchronization. These
are the primary processing steps for user authentication with a SQL database system connection. These scripts are run after
those listed in [DbConnectionInit] and before any step de nitions for the application are processed. If the scripts listed here
5/12/2023
return one of the failed validation values, the user is logged out of SAP Mobile Platform Server, and no application data is
synchronized.
[ValidatePreviousUser] – a list of SQL scripts that validate a previous user against the database during client-server
synchronization when a user change has occurred on the Agentry client. These scripts are run after those listed in
[DbConnectionInit] and before those listed in [ValidateUser]. If the scripts listed here return one of the failed security
validation values, the previous user’s data (pending transactions on the Agentry client) is not synchronized. A user change cannot
be completed until the previous user’s data has been successfully synchronized.
[LoggedIn] – a list of SQL scripts to be run after a validated the user has logged in successfully.
[LoggedOut] – a list of SQL scripts to be run just prior to a user logging out of the server, when client-server synchronization
has completed.
[UserInfo] – a list of SQL scripts to be run after those listed in the [LoggedIn] section, and before the step de nitions for
the application are processed. These scripts are expected to return values, including SQL step de nitions within the application,
that are then accessible to all other SQL scripts run against the system connection for a user. The values are available via the
Syclo Data Markup Language using the data tag <<user.info.valueName>>.
[ApplicationGlobals] – a list of SQL scripts that retrieve override values for global de nitions within the application. These
values are for the application in general; that is, not user-speci c.
[UserGlobals] – a list of SQL scripts that retrieve override values for global de nitions within the application. These values are
for a speci c user or user group, and allow for overrides on a per-user basis.
[LoginFailed] – a list of SQL scripts to be run when scripts in [ValidateUser] or [ValidatePreviousUser] indicate
the user has failed validation. This section is processed when validation fails for any reason, including the user being blocked.
[LoginBlocked] – a list of SQL scripts to be run when a user fails validation because he or she has been blocked. The scripts in
[ValidateUser] or [ValidatePreviousUser] must explicitly indicate the user has been blocked. In this case, these scripts
are run after those in [LoginFailed].
[ChangePassword] – a list of SQL scripts that process a password change by the user. The scripts, which perform the
necessary processing to change a user's password, are run after a user receives noti cation of an expired password, or when a
password is about to expire. The scripts are expected to return a value indicating success or failure in processing the password
change.
[ChangePasswordFailed] – a list of SQL scripts to run when a user password change fails. The scripts should provide the user
with information about why the new password was rejected.
[EnablePush] – a list of SQL scripts to run when a user performs a transmit and stays logged in for push processing.
Speci cally, these scripts run when both of the following conditions are met:
The Agentry client remains connected after synchronization, as the transmit con guration de nition is de ned to enable
push functionality, and
A push de nition exists within the application.
[DisablePush] – a list of SQL scripts to run when a client previously connected to SAP Mobile Platform Server to receive push
data is about to disconnect. These scripts are run prior to those listed in the [LoggedOut] section.
[TimeZone] – a list of SQL scripts that determine the time zone of the database. The time zone returned by these scripts is be
used when the application converts date and time values from one time zone to another, based on different settings for database
and Agentry client time zones.
[PasswordValidationAudit] – a list of SQL scripts that handle a password validation audit record. These scripts run as an
update query once per incoming password validation record. Typically the application designer writes a query that posts the
password validation record into an auditing database.
 Note
Make application-speci c modi cations to the passwordValidationAudit.sql le.
5/12/2023
Con guring the PasswordValidationAudit.sql File for Agentry Applications
After con guring the SqlBe.ini le, you may need to make modi cations to the passwordValidationAudit.sql le, which
enables you to handle password validation audit records. The developer must enable password validation in the application
de nition.
Con guring the PasswordValidationAudit.sql File for Agentry

Applications
After con guring the SqlBe.ini le, you may need to make modi cations to the passwordValidationAudit.sql le, which
enables you to handle password validation audit records. The developer must enable password validation in the application de nition.
The passwordValidationAudit.sql le is used for all applications. The le should be in the same directories as other SQL script
les, as described in Con guring the SqlBe.ini Query Initialization File for Agentry Applications.
Make changes to con guration les in the development environment, not on SAP Mobile Platform Server, and publish a new ZIP le in
Management Cockpit.
Password Validation Audit Template File

Following is the passwordValidationAudit.sql template le format:

Password Validation Audit File Values

Script le values.
Value Type Description
ID String The user ID for which the password was requested.
Reason Enum The reason the password is requested. Values include:
Login(0) ‒ initial login screen password entry.
IdleTimeout(1) ‒ idle timeout screen requested the password entry.
PasswordChange(2) ‒ password change screen requested password entry.
TransactionValidation(3) ‒
password was requested to validate a transaction.
Success Boolean Whether the password validation attempt was successful.
Lockout Boolean Whether a failed password attempt caused the client to be locked out.
Transaction String For transaction-related attempts, the transaction by name if the reason for the password was a transaction
Name validation. Otherwise the value is empty.
5/12/2023
Value Type Description
Transaction ID For transaction-related attempts, the transaction by ID if the reason for the password was a transaction validation.
ID Otherwise the value is 0.
Attempt Time TimeandDate The date-time stamp when the password was requested for the validation attempt. Attempt time is always in UTC
format.
Password Validation Processing

When a user performs a password-related action (login, idle timeout, password change, and transaction validation), an encrypted
password validation audit record is created on the client device.
The encrypted audit record is sent to the server. Records are typically sent on a rst-in, rst-out basis, which means the oldest record is
processed rst, but that is not guaranteed. Once the server receives the record, the server sends con rmation to the client, and the
client deletes the encrypted audit record.
Related Information
Con guring the SqlBe.ini Query Initialization File for Agentry Applications
Con guring Query Constant Files for Agentry Applications

Query constant les are con guration les containing constant values that may be referenced by any SQL script run by SAP Mobile
Platform Server. Each SQL database system connection can have its own query constant le.
By default, there are two such les installed in the SAP Mobile Platform installation directory
(SMP_HOME\Server\Configuration\com.sap.mobile.platform.server.agentry\):
Oracle_sd.ini – used by a system connection to an Oracle database systems
SqlServer_sd.ini – used by a system connection to an SQL Server database systems
 Note
These default les should not be modi ed. Instead, copy the les to
com.sap.mobile.plaform.server.agentry.application, and modify the copies. Otherwise changes will be lost if
the server is upgraded; les in com.sap.mobile.platform.server.agentry could be overwritten by the installer.
Make changes to con guration les in the development environment, not on SAP Mobile Platform Server, and publish a new
ZIP le in Management Cockpit. Restart each server in the cluster to distribute the changes.
The values in these scripts are intended to make SQL commands more portable when executed, either from de nitions within the
application, or from the query initialization le (SqlBe.ini). You can use the values in these les to write a single SQL statement that
executes properly throughout the applicable database system.
SDML data tags make the values within these les accessible to SQL statements that are run by the server. Like all other con guration
les for the server, the query constant les can contain multiple sections. By default, each contains the single section [Database],
which includes these values:
name – do not change this value, which represents the database type.
getSystemTime – the database function that is called to return the current date and time.
timeStampFormat – do not change this value, except in exceptional circumstances. The value represents the format of a date
and time value that is inserted into a table column for a date and time data type. This is also the format used by the SDML
processor within SAP Mobile Platform Server when a date and time SDML data tag is expanded.
5/12/2023
dateFormat – do not change this value, except in exceptional circumstances. The value represents the format of a date value
that is inserted into a table column of a date or date and time data type. This is also the format used by the SDML processor
within SAP Mobile Platform Server when a date data tag is expanded.
timeFormat – do not change this value, except in exceptional circumstances. The value represents the format of a time value
such that is inserted into a table column of a time or date and time data type. This is also the format used by the SDML processor
within SAP Mobile Platform Server when a time data tag is expanded.
tempdate – a temporary date value of 1/1/1901 12:00:00, which represents the proper format for the database type to use as a
date and time value. The default value is assumed to be unlikely for real data; if it is a valid date and time for the system, change it
to re ect an invalid date and time.
substring – the database function that is called to return a range of characters from within a larger string.
stringcat – the database function or operator that concatenates two string values.
charFunction – the database function that converts a value to a character data type.
nullFunction – the database function that determines whether a value is null.
singleRow – Oracle databases require every SELECT statement to include a FROM clause. When you select literal values, for
example, SELECT ʻX’..., the table object DUAL is used. The singleRow value in the Oracle constant le contains the text "FROM
DUAL." In the SQL Server script, this value contains an empty string.
unicodePrefix – the value that is pre xed to a Unicode value, that identi es it as such to the database.
terminalErrorCodes – a semicolon-delimited list of return values that are treated as terminal error codes by SAP Mobile
Platform Server. When such an error is returned, the server ends the synchronization with the client, and returns an error
message.
retryWithChangeErrorCodes – a semicolon-delimited list of return values that may be received from the database system
as the result of processing a SQL statement. The values listed here are treated as a retry-with-change error for the purposes of
transaction failure handling. If this functionality is not enabled, this setting has no affect on server behavior.
retryWithoutChangeErrorCodes – a semicolon-delimited list of return values that may be received from the database
system as the result of processing a SQL statement. The values listed here are treated as a retry-without-change error for the
purposes of transaction failure handling. If this functionality is not enabled, this setting has no affect on server behavior.
fatalWithMessageErrorCodes – a semicolon-delimited list of return values that may be received from the database system
as the result of processing a SQL statement. The values listed here are treated as a fatal-with-message error for the purposes of
transaction failure handling. If this functionality is not enabled, this setting has no affect on server behavior.
fatalWithoutMessageErrorCodes – a semicolon-delimited list of return values that may be received from the database
system as the result of processing a SQL statement. The values listed here are treated as a fatal-without-message error for the
purposes of transaction failure handling. If this functionality is not enabled, this setting has no affect on server behavior.
Additional Query Constant File Sections

You can add other sections to the query constants les, which includes values or functionality for application-speci c purposes. The
contents of this le are usually modi ed by, or at the direction of, the application developer, as the values are referenced as a part of the
application’s business logic. Before making any changes, understand the effect that such changes will have, and how the con guration
options are used. The default values provided with SAP Mobile Platform Server should only be changed in the rarest of situations,
particularly those related to date and time formats.
Examples of application-speci c changes:
The application extends a back-end system that may be deployed on different database systems, and certain values or
functionality is different within those systems.
The application extends a back-end system that is deployed in multiple languages. As a result, certain constant values, such as Y
and N ags, are different in different languages. You can represent such values as options in an application-speci c section, to
become the items referenced via SDML in the SQL statements. When the application is deployed to different languages, you can
update the constant le with the proper language-speci c value.
5/12/2023
Additional functions may be needed beyond those in the standard version of the query constants le. It may be more
straightforward to add a separate section that differentiates between the functions that are provided by default, and those that
are added later.
Con guring the Query Constant Files for a System Connection

A single SQL database system connection might use multiple query constant les. You can also change the name of the le that is
referenced for the connection.
If a different le name is to be used, or if multiple constant les are needed for a system connection, modify the queryConstantFiles
con guration option, in the [SQL-n] section, of the Agentry.ini le. For multiple le listings, each le name is separated by a
semicolon.
-- different file name

[SQL-1]
...
queryConstantFiles=MyConstantFile_sd.ini
...
--- multiple constant files
[SQL-1]
...
queryConstantFiles=Oracle_sd.ini;MyApplicationConstantFile_sd.ini
If you use a query constant le other than the default, the le you use must contain the [Database] section, including all con guration
options.
Con guring Java Virtual Machine Back-end Connections for Agentry

Applications
which you must modify using Management Cockpit. Use the Java Virtual Machine option to connect from an Agentry application to
custom code (for example, you could connect to SAP from Agentry via custom Java code). Before modifying the con guration
information for a Java Virtual Machine database back-end connection, you need to research and gather information about the database.
Certain tasks may or may not pertain to a particular implementation environment and you should perform a careful review of the
application’s requirements and functionality before proceeding.
Prerequisites
Obtain and record the back-end identi er for the Java Virtual Machine system connection. This is the name or number de ned in
the Agentry Editor.
Obtain and record the host system network name of the Java application server to which SAP Mobile Platform Server is to
connect.
Obtain and record the application server name of the Java interface, where applicable.
Identify any .jar or .class les that contain business objects that the application being implemented may use, and make them
accessible to SAP Mobile Platform Server. These les are normally provided with the back-end system with which the SAP Mobile
Platform Server is synchronizing.
Determine whether users are authenticated using the JVM system connection. If they are, they cannot synchronize unless they
have rst been successfully authenticated. Proper user credentials must be established within the back-end system before users
are allowed access. This may be done before or after con guring the back-end connection in Management Cockpit.
Procedure
5/12/2023
2. Under JAVA, edit JAVA-related settings. These con guration options are for a single Java Virtual Machine system connection, and
control the connection behavior between the server and a Java interface. There may be multiple Java-<n> sections within the
agentyr.ini le. One must exist for each Java Virtual Machine system connection de nition within the application. The <n>
portion of the section name must be replaced with the ID value generated by the Editor for the system connection de nition.
Class Path Valid fully Contains multiple path values that specify the location of different Java resources. This can include .jar
quali ed les used by the application. Each path must be fully quali ed. Each entry must be separated by a
paths. semicolon. All paths for this setting are added to the system variable CLASSPATH of the server’s host system.
Requires application restart.
Constants File Valid le Name and location of the .ini le, relative to the server, that contains constants that can be accessed from
name or the Java code via the SessionData.
path and
le name.
Default:
none.
Delete Source Boolean Controls whether the les stored in Source Directory are deleted after being successfully compiled by the
(Deprecated) value of JVM. This may be necessary in a development environment if the Java source les are modi ed outside of
true or the Agentry Editor. In development mode, the Agentry Editor can push Java source les to the server for the
false. server to compile. Requires application restart.
Default:
false
Enable Boolean Whether users are authenticated against the back-end system for this system connection. At least one system
Authentication value of connection within the application must perform user authentication.
true or
false”
Default:
true
Enable Boolean Whether previous users are authenticated against the back-end system for this system connection. This
Previous User value of authentication occurs when a user change occurs on the client.
Authentication true or
false.
Default:
true
Name Text Any text value that identi es the system connection in log les and other areas. Set each connection name to
value. a unique value. Requires application restart.
Output Valid path The location where the compiled .class les produced by the JVM are to be stored for execution. The
Directory value, standard is to use the Java subfolder in the server’s installation folder; however, you can use another location.
(Deprecated) relative to This path value you enter here must also be a part of the system’s CLASSPATH (either using a system
the variable, or by adding the value to the classPath con guration option). This only applies to applications
server. running in development mode; in development mode the Agentry Editor can push Java source les to the
server for the server to compile. Requires application restart.
Print Boolean Setting this option to true results in messages generated by the AJ-API exception class
Business value of JavaBusinessLogicError being printed to the events.log le produced by the server. Requires
Logic Stack true or application restart.
Trace false.
Default:
false
Print Stack Boolean Setting this option to true results in messages generated by the exception stack trace being printed to the
Trace value of events.log le produced by the server. Requires application restart.
true or
false.
Default:
false
5/12/2023
Scripts Path Valid le Name and location of the scripts le, relative to the server. This is the directory in which Agentry Editor places
name or Java source code, when the source code for a Java class is entered directly into the Editor to de ne a steplet
path and or similar. Requires application restart.
le name.
Default:
none.
Server Class Valid Java The application-speci c extension of the AJ-API syclo.agentry.server class. This option is
Server automatically set when this API class has been extended by a server class for the application. If no such class
Class exists, the default syclo.agentry.server class is assumed and should not be set for this con guration
extension. option. Requires application restart.
Source Valid path This directory can be used for all other source code on which the Scripts Path might depend. This is the
Directory value, location of the .java les for the Steplet, ComplexTable, and DataTable classes. Files are placed
(Deprecated) relative to here before they are compiled by the JVM. This is not where the Java project les reside that are related to
the the application. The .java les are written to this location by the server at runtime. Their contents are based
server. on the de nitions in which they are contained. This only applies to applications running in development mode;
in development mode the Agentry Editor can push Java source les to the server for the server to compile.
Time Zone Valid time Identi es the time zone to which date and time values are converted when received from clients; or from
Name zone which they are converted when sent to clients. This conversion is based on the application de nitions. This
name. setting is used only to specify a time zone other than the one for the back-end system.
Default:
null
3. Restart the application if you changed any setting that requires it.
Con guring HTTP-XML Back-end Connections for Agentry

Applications
which you must modify using Management Cockpit. Use the HTTP-XML option to connect from an Agentry application to an XML-based
Web service (for example, you could connect to an SAP Web service back end). After modifying the con guration information in
Management Cockpit, you may need to perform additional con guration tasks. Certain tasks may or may not pertain to a particular
implementation environment and you should perform a careful review of the application’s requirements and functionality before
proceeding.
Prerequisites
Obtain and record the back-end identi er for the HTTP-XML system connection. This is the name or number de ned in the
Agentry Editor.
Obtain and record the base URL of the HTTP-XML server to which the SAP Mobile Platform Server will make CGI or HTTP
requests. This value is pre xed to the paths of speci c requests within the application, as de ned in the Agentry Editor.
Make a note of any speci c name spaces that exist in the XML schema to be used.
Determine the back-end user authentication needs of the application.
Obtain and record other relevant communication information for the back-end system, including port numbers and network
timeout durations.
Procedure
2. Under HTTPXML, edit HTTPXML-related settings. These con guration options are for a single HTTP-XML system connection, and
control the connection behavior between the server and an HTTP server. There may be multiple HTTPXML-<n> sections within the
Agentry.ini le. One must exist for each HTTP-XML system connection de nition within the application. The <n> portion of the
section name must be replaced with the ID value generated by the Editor for the system connection de nition.
5/12/2023
De nition Values Description
Authentication MY Speci es the location of the authentication certi cate for the server. This le may be a Certi cate
Certi cate le (.cer), Certi cate store le (.sst), or Personal Information Exchange le (.pfx). Used only if Listen
Store On is set to a valid port. Requires application restart.
Authentication None The authentication certi cate store password.

Certi cate
Store
Password
Base URL Valid URL and The base URL address of HTTP requests made by the server for this system connection. Set this
optional port option before starting the server.
number (format:
http://localhost:81).
Default: none
Basic None The basic authentication password.

Authentication
Password
Basic None The basic authentication user identi cation.

Authentication
User ID
Constants File Valid le name or The constants le used for this system connection. This le contains constant named values that
path and le name may be referenced by the HTTP-XML application components.
to constants le.
Default:
httpxml_sd.ini
Enable Disabled Whether users are authenticated against the back-end system for this system connection. At least
Authentication one system connection within the application must perform user authentication.
Enable Disabled Whether previous users are authenticated against the back-end system for this system connection.
Previous User This authentication occurs when a user change occurs on the client.
Authentication
HTTP 60 Time out period, in milliseconds, for this system connection. When the connection attempt exceeds
Connect this value, the connection terminates. The timer resets when data is exchanged between server and
Timeout the back-end system during client synchronization.
HTTP Receive 300 Time out for receiving the response from the remote Web server.
Timeout
HTTP Resolve 60 Time out for resolving the DNS name for a remote connection into an IP address.
Timeout
HTTP Send 300 Time out for sending a request to the remote Web server.
Timeout
Listen On Disabled Port to use for connections to the HTTPXML-BE by remote systems to trigger system events in
Agentry (used for Web service calls). Requires application restart.
Name Text Value Any text value used to identify the system connection in log les and other areas. This should be set
to a unique value especially when working with multiple system connections. Requires application
restart.
Time Zone None The time zone to which date and time values are converted when received from clients; or from
Name which they are converted when sent to clients. This conversion is based on the application
de nitions. This setting is used only to specify a time zone that differs from the back-end system.
Timeout 300 (seconds) Speci es how long the server will keep a connection open with a client when no messages or
responses are received from the client.
Trusted None Speci es the location of the trusted certi cate store for the server. This store is only used when
Certi cate clients are required to provide authentication certi cates during synchronization. Used only if Listen
Store On is set to a valid port. Requires application restart.
5/12/2023
Use SSL None Whether to use SSL when accepting incoming Web connections. This is used for system event
processing for the HTTP-XML back end, since system events for this back end are connections to
Agentry's built-in Web server from remote systems. Used only if Listen On is set to a valid port.
XML None Registers new XML pre xes (the " <localNames>") for XML namespaces that may appear in
Namespaces documents retrieved from remote servers; these pre xes can then be used in XPath expressions
that are de ned in the Agentry Editor for processing the documents. The format is
<<localName>>|<<URI>>[|<<localname>>|<<URI>>]*, with as many pairs as needed to
de ne the needed namespaces. Separate each entry using a pipe ( | ) symbol.
3. Restart the application if you modi ed any values that require it.
Next Steps
If required, make application-speci c additions or modi cations to the XML constants le, or create additional constants les. The XML
Constants le is used to de ne values that can be referenced from Agentry Editor XML de nitions for Server Data Markup Language
(SDML) tags. The structure of the le is similar to the SQL query constants les.
 Note
Make changes to con guration les in the development environment, not on SAP Mobile Platform Server, and publish a new ZIP le in
Management Cockpit. Restart each server in the cluster to distribute the changes.
Con guring OData Back-end Connections for Agentry Applications

which you must modify using Management Cockpit. Use the OData option for an Agentry application that access an OData back-end
service. Certain tasks may or may not pertain to a particular implementation environment and you should perform a careful review of the
application’s requirements and functionality before proceeding.
Prerequisites
Obtain or generate the URL for the back-end service connection
(Optional) Obtain the user name and password for the URL, if required
Procedure
2. Under OData, edit OData-related connection settings.
Authentication Certi cate MY Speci es the location of the authentication certi cate for the server. This le may be
Store a Certi cate le (.cer), Certi cate store le (.sst), or Personal Information
Exchange le (.pfx). Used only if Listen On is set to a valid port. Requires
application restart.
Authentication Certi cate None The Authentication Certi cate Store password. Requires application restart.
Store Password
baseURL Valid URL and The base URL address of HTTP (or OData) requests made by the server for this
optional port system connection. Set this option before starting the server.
number (format:
http://localhost:81).
Default: none
5/12/2023
basicAuthenticationPassword None The base authentication password.
 Note
This entry may not be needed for client log in, if the user ID and password are
supplied from the client. But it is needed to perform operations on the OData
services.
basicAuthenticationUserID None The base authentication user identi cation.
 Note
This entry may not be needed for client log in, if the user ID and password are
supplied from the client. But it is needed to perform operations on the OData
services.
Constants File Valid le name or The constants le used for this system connection. This le contains constant
path and le name named values that may be referenced by the HTTP (or OData) application
to constants le. components.
Default:
odata_sd.ini
Enable Authentication Enabled by default. Whether users are authenticated against the back-end system for this system
connection. At least one system connection within the application must perform user
authentication.
 Note
Be sure to enable if you want to perform authentication on an OData system
connection for user login.
Enable Previous User Whether previous users are authenticated against the back-end system for this
Authentication system connection. This authentication occurs when a user change occurs on the
client.
httpConnectTimeout 60 Time out period, in milliseconds, for this system connection. When the connection
attempt exceeds this value, the connection terminates. The timer resets when data
is exchanged between server and the back-end system during client synchronization.
httpReceive Timeout 300 Time out for receiving the response from the remote Web server.
httpResolve Timeout 60 Time out for resolving the DNS name for a remote connection into an IP address.
httpSendTimeout 300 Time out for sending a request to the remote Web server.
listenOn Disabled Port to use for connections to the OData back end by remote systems to trigger
system events in Agentry (used for Web service calls). Requires application restart.
Name Text Value Any text value used to identify the system connection in log les and other areas.
This should be set to a unique value especially when working with multiple system
connections. Requires application restart.
Time Zone Name None The time zone to which date and time values are converted when received from
clients; or from which they are converted when sent to clients. This conversion is
based on the application de nitions. This setting is used only to specify a time zone
that differs from the back-end system.
Timeout 300 (seconds) Speci es how long the server will keep a connection open with a client when no
messages or responses are received from the client.
Trusted Certi cate Store None Speci es the location of the trusted certi cate store for the server. This store is only
used when clients are required to provide authentication certi cates during
synchronization. Used only if Listen On is set to a valid port. Requires application
restart.
5/12/2023
useSSL None Whether to use SSL when accepting incoming Web connections. This is used for
system event processing for the OData back end, since system events for this back
end are connections to Agentry's built-in Web server from remote systems. Used
only if Listen On is set to a valid port. Requires application restart.
xml Namespaces None Registers new XML pre xes (the "<<localNames>>") for XML namespaces that may
appear in documents retrieved from remote servers; these pre xes can then be used
in XPath expressions that are de ned in the Agentry Editor for processing the
documents. The format is <<<localName>>>|<<URI>>[|<<localname>>|
<<URI>>]*, with as many pairs as needed to de ne the needed namespaces.
Separate each entry using a pipe ( | ) symbol.
Con guring File System Back-end Connections for Agentry

Applications
For Agentry applications that communicate over a le system connection, use Management Cockpit to con gure the SAP Mobile
Platform Server to connect to the host system. Certain tasks may or may not pertain to a particular implementation environment and
you should perform a careful review of the application’s requirements and functionality before proceeding.
Prerequisites
Obtain and record the back-end identi er for the le system connection. This is the name or number de ned in the Agentry Editor.
Determine whether users are authenticated during synchronization by logging them in to the host system.
Obtain and record the Windows User Domain for user authentication.
Determine the location in whichSAP Mobile Platform Server stores temporary script les for execution. The default location is the
Windows TEMP folder as con gured for the system.
Determine whether the previous user should be connected to the Windows system when a user change occurs on the clients. You
might want to omit this portion of synchronization to expedite the le transfer process.
Create a user account for SAP Mobile Platform Server to connect to the host system.
Procedure
2. Under File, edit le-related connection settings. These con guration options are for a single NT File system connection, and
control connection behavior between the server and the server’s host system. There may be only one File-<n> section within the
agentry.ini le. This section must exist for an NT File system connection de nition within the application. The <n> portion of
the section name must be replaced with the ID value generated by the Editor for the system connection de nition.
Enable Boolean value of Whether users are authenticated against the host system for this system connection. At least one
Authentication true or false. system connection within the application must perform user authentication.
Default: false
Enable Boolean value of Whether previous users are authenticated against the host system for this system connection. This
Previous User true or false. authentication occurs when a user change occurs on the client. If Allow Previous User Login is false,
Authentication Default: false this setting has no affect.
User Domain Text value of a The domain under which all users are logged in to the host system. It is only used on Windows, to
con gured user control which Active Directory domain users are authenticated against by Agentry, when the le back
domain. end is con gured to do authentication.
5/12/2023
Temporary Valid full path. The location where temporary les produced by the server for le system processing are stored
Path (normally the batch le de ned in the application). If this option is null or not included, the con gured
Windows temporary folder is used.
Allow Boolean value of Whether previous users are logged in to the le system when a user change occurs on the client. If not
Previous User true or false. logged in, no le system connection processing de ned in the application is performed for the
Login Default: true previous user.
Name Text value. This setting can contain any text value used to identify the system connection in log les and other
areas. Set this to a unique value, especially when working with multiple system connections.
PAM Service agentry Name of the Pluggable Authentication Modules (PAM) service that Agentry should use to authenticate
Name users on UNIX platforms.
De ning Application Authentication

Assign a security pro le to the selected application. The security pro le de nes parameters that control how the server authenticates
the user during onboarding, and request-response interactions with the back end.
Prerequisites
In a production environment, con gure security pro les for application authentication. In a development or test environment, you can use
a security pro le such as Default.
Context
Security pro les are made up of one or more authentication providers. These authentication providers can be shared across multiple
security pro les, and can be modi ed in Management Cockpit. For more information about authentication providers, see Authentication
in SAP Mobile Platform.
You can stack multiple providers to take advantage of features in the order you chose; the Control Flag must be set for each enabled
security provider in the stack.
Procedure
1. In Management Cockpit, select Applications.
2. For an application, select Con gure Authentication .
3. Select a Security Pro le Name, or select Create New, and enter a name for the new pro le.
The authentication providers that are associated with the security pro le appear under Authentication Providers.
 Note
For Mobile BI applications, administrators can choose a security pro le from the list, which becomes the default pro le for the
current application. Mobile BI applications can send an X-SMP-SC header during registration requests, which can override the
security con guration assigned to the Mobile BI application in Management Cockpit. After registration, all requests use the
same security con guration that was used when creating the application connection ID. Normal data requests with an
accompanying application connection ID retrieve the security pro le that was used when the application connection ID was
registered, and use it for authentication.
4. (Optional) For token-based authentication, enable Check Impersonation to prevent authentication when the user name
presented cannot be matched against any of the user names validated in the login modules.
5. (Optional) To add an authentication provider to the security pro le, click the Add icon , and in the Add Authentication Provider
dialog:
a. Select an Authentication Provider from the list.
5/12/2023
b. Select the Control Flag.
c. Enter an optional description for the provider.
d. To validate the settings, click Test Settings.
e. Click Save.
Previous: De ne Back-End Connections
Next: De ning Client Policies
Related Information
Stacking Authentication Providers and Combining Results
Security Pro les
Con guring Security Pro les and Authentication Providers
Web Application Authentication Samples

Several authentication scenario samples demonstrate how to con gure Web applications using the same security con guration and
supportability measures that are available for mobile applications.
Create a Web Application

Use the following steps to de ne and con gure a Web application. Once de ned, four tabs appear: Overview, Back End, Authentication,
and Access Control.
1. De ne the Web application, saving when prompted.
a. In Management Cockpit, select Applications, and click New.
b. Con gure the Web application using the following required items (you can con gure additional items):
ID ‒ the Web application ID, such as web.basic_basic.
Name ‒ the Web application name, such as Web basic application.
Type ‒ select Web.
2. In Back End, complete the following:
Endpoint ‒ enter the back-end address URL, using either the application ID, or the X-SMP-APPID, in the format:
https://<host>:<port>/<applicationId>
https://<host>:<port>/<applicationId>?X-SMP-APPID=<applicationId>
SSO Mechanism ‒ select an single sign-on option, such as Basic.
3. In Authentication, add the security pro le.
Name ‒ the Web application name, such as Web basic application.
Authentication Providers ‒ select HTTP/HTTPS Authentication.
URL ‒ enter the authentication URL, such as http://<host>:

<port>/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/?spnego=disabled.
Web App Guidelines
5/12/2023
Keep in mind the following guidelines for the back-end access URL:
The following format does not work for all Web application types (such as hybrid or native) that use the Backend Rewrite URL
method for a root path ("/") back end:https://<host>:<port>/<applicationId>
For example: https://cnpvglwssc856.test.corp.sap:8081/web.basic_basic
The following format works for all Web application methods: https://<host>:<port>/<applicationId>?X-SMP-APPID=
<applicationId>
For example: https://cnpvglwssc856.test.corp.sap:8081/web.basic_basic?X-SMP-APPID=web.basic_basic
Web App with x.509 Sample

Use the following information to con gure a Web application using x.509 authentication.
1. De ne a Web application; for example, using the name: web_x509.
2. Con gure the Back End tab.
Endpoint ‒ enter <Your mutual HTTPS back-end URL>.
Certi cate alias ‒ enter <Your certi cate private key alias>.
SSO Mechanism ‒ select X.509.
3. Con gure the Authentication tab. Create a security pro le using the Authentication Provider: x.509 User Certi cate.
4. To test, access the Web type application using a browser, for example: https://<host>:<port>/web_x509.
Web App with SAML (Basic) Sample

Use the following information to con gure a Web application using SAML security. Technical User (Basic) is used in the sample, but you
can use other SAML security types.
1. De ne a Web application; for example, using the name: saml2.app.basic.
2. Con gure the Back End tab.
Endpoint ‒ enter the back-end address URL, using the application ID.
SSO Mechanism ‒ select Technical User (Basic).
3. Con gure the Authentication tab. Create a security pro le using the Authentication Provider: SAML2, and enter your Identify
Provider Name in the General tab. Contact your administrator to obtain the Identity Provider Name.
4. To test, access the Web type application using a browser, for example: https://<host>:<port>/saml2.app.basic.
Web App with Back-end Rewrite URL Sample

If you elect to rewrite the URL to the back-end system, follow the steps in Create a Web Application above, with these differences in Back
End:
Rewrite Mode ‒ select "Rewrite URL in Backend System".
URL ‒ modify the URL as follows: https://<host>:<port>/<backend_rewrite_path>?X-SMP-APPID=

<applicationId>.
Web App with Relay Server Samples

When con guring Web applications for a landscape that implements Relay Servers, you must modify the back-end URL:
5/12/2023
Linux Relay Server ‒ https://<RelayServerHost>:
<RelayServerPort>/<URL_Suffix>/<farmid>/<applicationId>
For example:
https://cnpvgllssc1093.test.corp.sap:18081/cli/iarelayserver/SMP3RHFarmHTTPS/web.basic_basic
Windows Relay Server ‒ https://<RelayServerHost>:

<RelayServerPort>/<URL_Suffix>/<farmid>/<applicationId>
For example:
https://cnpvglwssc1060.test.corp.sap:1081/rs16.5/client/rs.dll/SMP3WINFarmHTTPS/web.basic_basic
De ning Client Policies

Set policies that are related to client password and log management for the selected application. For hybrid apps, set feature restriction
policies.
De ning Client Password Policy

(Not applicable to Agentry and Mobiliser) De ne the client password policy that is used to unlock the DataVault for the selected
application.
De ne the policies for log and trace information generated on clients for the selected application. You can download and view
client log les. Trace information is generated as part of an end-to-end trace session.
De ning Client Upload Database Files Policies
De ne the policy for uploading database les from the device client.
De ning Usage Report Policies
Enable the server to upload application-speci c usage statistics and reports from mobile devices.
Previous task: De ning Application Authentication
Next task: De ning Push Noti cations
De ning Client Password Policy

(Not applicable to Agentry and Mobiliser) De ne the client password policy that is used to unlock the DataVault for the selected
application.
Context
The application developer must have added enforcement code to the application DataVault to enforce the password policy. The
administrator enters the application password policy used to unlock the DataVault during application initialization.
The client password policy applies only to the application password that is used to unlock the DataVault during application initialization; it
has nothing to do with SAP Mobile Platform security pro les, or the back-end security systems with which they integrate. Password
policies for back-end security systems are administered by customer information technology departments using their native security
administration tools.
Procedure
2. For an application, select Con gure Client Policies .
3. Under Passcode Policy, select Enable Passcode Policy and con gure the policy properties:
5/12/2023
Property Default Description
Expiration Days 0 The number of days a password is valid before it expires.
Minimum Length 8 The minimum password length required.
Retry Limit 10 The number of retries allowed when entering an incorrect

password. After this number of retries, the client is locked out, and
the DataVault and all its contents are permanently deleted, the
application is permanently unusable, and its encrypted data is
inaccessible.
Minimum Unique Characters 0 The minimum number of unique characters required in the
password.
Lock Timeout 300 The number of seconds the DataVault may remain unlocked within
the application, while the application remains inactive. Once this
time passes, the user must re-enter their password to continue
using the application (similar to a screen-saver feature).
 Note
If the application implements the SAP Mobile Platform Mobile
SDK, the Mobile SDK interprets the Lock Timeout from the
Data Vault Password Policy differently than described here. See
SAP Mobile Platform SDK > Native OData App Development >
iOS Applications > Developing with MAF Login for iOS >
Customizing the Logon UI > Logon Screen Con guration
Options > Data Vault Life Cycle (the section: Handling Timeout
with MAF Logon Components). Work with the application
developer if appropriate.
Default Passcode Allowed Disabled Indicates whether a default password can be generated by the
DataVault; from the user's point of view this policy turns off the
password.
Has Digits Disabled Indicates whether the password must include digits.
Has Lower Disabled Indicates whether the password must include lower case letters.
Has Upper Disabled Indicates whether the password must include upper case letters.
Has Special Disabled Indicates whether the password must include special characters.
Fingerprint Allowed Disabled Indicates whether you can unlock the application with a ngerprint.
4. Click Save.
Related Information
Securing Sensitive Data On-Device with DataVault
Device Data Security
Client Password Policy for Data Vault Logins

De ne the policies for log and trace information generated on clients for the selected application. You can download and view client log
les. Trace information is generated as part of an end-to-end trace session.
Context
Client log and trace policies are propagated to the client. Clients must adhere to the policies. For example, clients must delete logs based
on the de ned time period.
5/12/2023
The log and trace policies speci ed here apply to all application registrations. These settings can be overridden for a speci c registration
by the log and trace policies de ned at the registration level.
Procedure
1. In Management Cockpit, select Applications Con gure Client Policies
2. Under Log Policy, enable Log Upload.
3. Select the log level, or None.
Logging Levels
Log Level Description
Path For tracing execution ow. Used, for example, in the context of entering and leaving a method, looping, and
branching operations. (Not applicable to the offline logging component.)
Debug For debugging purposes, includes extensive and low-level information.
Info Informational text, used mostly for echoing what has been performed.
Warn The application can recover from the anomaly, and ful ll the task, but requires attention from the developer or
operator.
Error The application can recover from the error, but cannot ful ll the task due to the error.
Fatal The application cannot recover from the error, and the severe situation causes fatal termination.
4. Select the time period after which logs are to be deleted from the database.
5. Select the E2E trace level to specify the type of trace information captured during an end-to-end trace session..
Trace Levels
Level Description
None No trace information is collected. Use this level when performing analysis on the client.
Low Collects trace information related to response time distribution. Use this level to analyze the amount of time
spent on each server component.
Medium Collects trace information related to performance. This trace level corresponds to the Info log level setting. During
a trace session, this level overrides a lower log setting to increase the amount of information logged.
High Collects detailed functional logging and tracing information. This trace level corresponds to the Debug log level
setting. During a trace session, this level overrides a lower log level to increase the amount of information logged.
6. Click Save to save the settings.
Related Information
Changing Client Log and Trace Settings
Setting Log Levels
De ning Client Upload Database Files Policies

De ne the policy for uploading database les from the device client.
5/12/2023
Context
Enable the client database le upload policy for an individual application to troubleshoot problems on the client side. The application
must be con gured by the developer to allow this feature; the administrator must enable the policy; and the application users must
upload the database les from the client device. Once the les are uploaded, the developer can troubleshoot problems. The database
les are deleted once the length of time speci ed by the administrator has elapsed.
Procedure
2. Select an application, then select Con gure Client Policies .
3. Under Database Upload Policy, enable Database Upload, and enter:
Database Upload Properties
Delete Databases After 7 days The time to elapse before the database les are
deleted automatically. This security measure
protects the device user, but be sure to allow
enough time for the developer to perform the
troubleshooting or analysis.
Maximum Database Size 32 MB The maximum size allowed for the database
les.
4. Once the policy is enabled, the device user can upload the local database les for the developer to analyze or troubleshoot.
De ning Usage Report Policies

Enable the server to upload application-speci c usage statistics and reports from mobile devices.
Procedure
1. From Management Cockpit, select Applications.
2. Select an application, then select Con gure Client Policies .
3. Under Usage Report Policy:
a. To enable the server to accept records for an application, select Enable Usage Report Upload.
b. In Upload Report After, enter the number of days, after which reports are uploaded to the SAP Mobile Platform Server.
Next Steps
To view usage information, select Reporting.
De ning Push Noti cations

(Optional) Con gure push-related settings for the selected application. The push listener service provided with SAP Mobile Platform
Server allows back-end systems to send native noti cations to devices. The application developer must have enabled push noti cation
code in the application to use this option.

(Optional) Enable the custom push provider to manage push noti cations for the application at the device platform level, rather
than for all device platforms.
5/12/2023
Con guring Push Noti cation Settings
(Optional) Con gure push-related settings by device type for the selected native, hybrid, or Mobile BI application. The application
developer must have enabled push noti cation code for the application, and SAP Mobile Platform Server must be con gured to
support push.
Con guring Custom APNS Host and Port
Con gure application APNS push to use custom APNS hosts and ports, rather than the default Apple push server. You can, for
example, use this as a way to reach the official APNS ports directly from inside your network.
Con guring Push for Agentry
Con gure Apple (APNS) and Android (GCM) push-related settings for the selected Agentry application, after publishing the
application and restarting the application. Before then, the Push tab is blank. The Agentry application developer must have
con gured push for the application via Agentry Editor, and enabled or registered push noti cation as part of application branding.
No SAP Mobile Platform Server con guration settings are required for Agentry push.
Previous: De ning Client Policies
Next task: Uploading Client Resources

(Optional) Enable the custom push provider to manage push noti cations for the application at the device platform level, rather than for
all device platforms.
Prerequisites
Create the application on SAP Mobile Platform Server.
Context
Enabling custom push providers gives you more control for managing push for the application.
Procedure
1. In Management Cockpit, select Applications Con gure Push .
2. Under Custom Push Provider, select one or more device platform types.
3. Con gure custom push provider settings for the selected device platforms. Entries are required unless stated otherwise.
Application (Optional) A display name for the application. By default, the application ID is used, for example, com.sap.today.
URL Push URL.
User Name The user name to connect to the push URL.
Password The user password to connect to the push URL.
Con guring Push Noti cation Settings

(Optional) Con gure push-related settings by device type for the selected native, hybrid, or Mobile BI application. The application
developer must have enabled push noti cation code for the application, and SAP Mobile Platform Server must be con gured to support
push.
Prerequisites
5/12/2023
SAP Mobile Platform Server noti cation properties must be con gured:
The base noti cation URL that was con gured during installation (sample format: http://SMPHostName:8080/). The host name
set here must be accessible from the back end that triggers the noti cations.
 Note
In a cluster con guration, the push (noti cation) URL should point to the load balancer/proxy server, not a particular server
node. This enables the load balancer to distribute the request to the appropriate node in the cluster.
(Optional) Proxy host and port used by SAP Mobile Platform Server to send noti cations to APNS.
Context
Use native noti cations to allow third-party applications, or a back end to deliver native noti cations, directly through the SAP Mobile
Platform HTTP noti cation channel to the device, for example, BlackBerry (BES/BIS), Apple (APNS), or Android (GCM).
For more information, see REST API Application Development > Developing the Application> Native Push Noti cation for a Back End.
Procedure
2. Under Apple, BlackBerry, Android, WNS, and MPNS, make push noti cation settings for the device or devices you choose.
Apple Push Noti cations

Con gure Apple push noti cations for the selected application.
Android Push Noti cations
Con gure Android push noti cations to enable the selected application to receive either Firebase Cloud Messaging (FCM) or
Google Cloud Messaging (GCM) noti cations.
BlackBerry Push Noti cations
Con gure BlackBerry push noti cations to enable the selected application to receive BES/BIS noti cations.
Windows Push Noti cations
Con gure Windows push noti cation services (WNS) for the selected application, to enable the back-end con gured with the
mobile platform to send toast, tile, badge, and raw updates to Windows desktop and tablet application users.
Windows Phone Push Noti cations
Con gure Microsoft Push Noti cation Service (MPNS) for the selected application, to enable the back-end servers that are
connected to SAP Mobile Platform to send toast, tile, badge, and raw updates to Windows phone users running mobile
applications. Only unauthenticated push noti cation is supported.
Apple Push Noti cations

Con gure Apple push noti cations for the selected application.
Context
You can con gure push for your production environment or a development and testing environment, using the default host and port
values; or you can con gure push using custom host and port values. You must provide the certi cate le and password for push
noti cation security.
Procedure
2. Under Apple, indicate the APNS Endpoint. The endpoints identify the host and port values for the APNS noti cation and feedback
services.
5/12/2023
None ‒ the default endpoint value for all the applications.
Sandbox ‒ accept the default APNS endpoint values for the testing and development environment.
Default Sandbox APNS Settings
Setting Value
Noti cation Service Host: gateway.sandbox.push.apple.com
Noti cation Service Port: 2195
Feedback Service Host: feedback.sandbox.push.apple.com
Feedback Service Port: 2196
Production ‒ accept the default APNS endpoint values for the production environment.
Default Production APNS Settings
Setting Value
Noti cation Service Host: gateway.push.apple.com
Noti cation Service Port: 2195
Feedback Service Host: feedback.push.apple.com
Feedback Service Port: 2196
Custom ‒ provide your own custom APNS endpoint values. The entries must conform to the guidelines.
Custom APNS
Setting Provide Custom APNS Endpoint Values
Noti cation Service Host:
Noti cation Service Port:
Feedback Service Host:
Feedback Service Port:
Guidelines for creating a custom APNS:
The maximum length of Noti cation Service Host and Feedback Service Host is 253 characters. Additional
characters are truncated.
The format of Noti cation Service Host and Feedback Service Host should follow one of these:
The string can only contain alphanumeric, hyphen (-), and dot (.) characters; should start and end with
alphanumeric characters; and only alphanumeric characters are allowed before and after the dot. For
example: my-server-name01.my-company.com.
The string should match the Internet Protocol version 4 (IPv4) format. For example: 192.168.1.100.
The Noti cation Service Port and Feedback Service Port should be between 0 and 65535.
3. Provide the certi cate le and password to use for push noti cations.
a. Click Browse to navigate to the certi cate le.
b. Select the le, and click Open.
c. Enter a valid password.
4. (Optional) Con gure push noti cations for other applications.
5/12/2023
Android Push Noti cations

Con gure Android push noti cations to enable the selected application to receive either Firebase Cloud Messaging (FCM) or Google
Cloud Messaging (GCM) noti cations.
Procedure
2. Under Android, do one of the following:
For FCM, enter the server key for API key. To get the key, go to the Firebase Developer Console, select Settings from the
project context menu, then go to the Cloud Messaging tab.
 Note
To use an FCM client with a GCM-based server, enter the legacy server key.
For GCM, enter the access key for API key. This is the access key you obtained for your Google API project
(https://developers.google.com/cloud-messaging/http-server-ref ).
3. Enter a value for Sender ID. This is the project identi er.
 Note
For FCM, the Sender ID is located under the Cloud Messaging tab.
BlackBerry Push Noti cations

Con gure BlackBerry push noti cations to enable the selected application to receive BES/BIS noti cations.
Prerequisites
(Optional) Enable push synchronization in the BlackBerry server. See the BlackBerry server documentation.
Procedure
2. Under Blackberry, select the push type.
Select None if you do not want to con gure Blackberry push noti cation.
Select BES to con gure Blackberry Enterprise Server (BES) native noti cation properties.
Server URL Address in the form http://<domain_name> or <IP_address>:

<port_Number>/pap.
User (Optional) User who is accessing the URL.
Password User password to connect to the URL. If you set a user name, you must enter a password.
Select BIS to con gure Blackberry Internet Server (BIS).
5/12/2023
Server URL Address in the form

https://cp<XXXX>.pushapi.eval.blackberry.com/mss/PD_<pushRequest>
Listener Port The push listener port for BIS noti cations
Application ID The unique identi er assigned to the registered push application service
Password The con guration property provided by BlackBerry for BIS push
Windows Push Noti cations

Con gure Windows push noti cation services (WNS) for the selected application, to enable the back-end con gured with the mobile
platform to send toast, tile, badge, and raw updates to Windows desktop and tablet application users.
Procedure
2. Under WNS, enter the application credentials provided by the application developer.
Package SID Package security identi er
Client Secret Client secret information
Windows Phone Push Noti cations

Con gure Microsoft Push Noti cation Service (MPNS) for the selected application, to enable the back-end servers that are connected to
SAP Mobile Platform to send toast, tile, badge, and raw updates to Windows phone users running mobile applications. Only
unauthenticated push noti cation is supported.
Procedure
2. Under MPNS, set Enable MPNS HTTP Push to On to send HTTP push noti cations to devices.
Con guring Custom APNS Host and Port

Con gure application APNS push to use custom APNS hosts and ports, rather than the default Apple push server. You can, for example,
use this as a way to reach the official APNS ports directly from inside your network.
Prerequisites
A reverse proxy must be con gured in the network landscape. The reverse proxy exposes the external APNS services with standard host
names and ports.
5/12/2023
Context
Con gure the custom host names and ports in Management Cockpit.
Procedure
2. Under Apple, select Custom as the APNS Endpoint, and con gure custom APNS endpoint values using the host name and port
values exposed by the reverse proxy. The entries must conform to the custom guidelines.
Custom APNS
Setting Provide Custom APNS Endpoint Values
Noti cation Service Host:
Noti cation Service Port:
Feedback Service Host:
Feedback Service Port:
Guidelines for creating a custom APNS:
The maximum length of Noti cation Service Host and Feedback Service Host is 253 characters. Additional characters are
truncated.
The format of Noti cation Service Host and Feedback Service Host should follow one of these:
The string can only contain alphanumeric, hyphen (-), and dot (.) characters; should start and end with
alphanumeric characters; and only alphanumeric characters are allowed before and after the dot. For example: my-
server-name01.my-company.com.
The string should match the Internet Protocol version 4 (IPv4) format. For example: 192.168.1.100.
The Noti cation Service Port and Feedback Service Port should be between 0 and 65535.
3. Provide the certi cate le and password to use for push noti cations.
a. Click Browse to navigate to the certi cate le.
b. Select the le, and click Open.
c. Enter a valid password.
Next Steps
With this con guration in place, push noti cations can reach the official APNS hosts and ports directly from inside the network.
Con guring Push for Agentry

Con gure Apple (APNS) and Android (GCM) push-related settings for the selected Agentry application, after publishing the application
and restarting the application. Before then, the Push tab is blank. The Agentry application developer must have con gured push for the
application via Agentry Editor, and enabled or registered push noti cation as part of application branding. No SAP Mobile Platform
Server con guration settings are required for Agentry push.
Context
For Agentry Editor and Agentry app development information, see SAP Mobile Platform SDK product documentation.
Procedure
5/12/2023
2. Under Push, edit push-related settings for the Agentry application.
Properties Values Description
APNS Certi cate apnsCertificates SAP Mobile Platform directory used for the Apple Push
Directory Noti cation certi cate. Requires application restart.
APNS Certi cate None Password associated with the Apple Push Noti cation
Password certi cate. Requires application restart.
APNS Certi cate Enabled Whether the Apple Push Noti cation certi cate password
Password Encoded should be encrypted. Requires application restart.
APNS Enabled Enabled Whether Apple Push Noti cation is enabled. Requires
FCM Enabled Enabled Whether Google Cloud Messaging is enabled. Requires

FCM Server Authorization:key Google Cloud Messaging server authorization key, if GCM is
Authorization Key enabled. Requires application restart.
FCM Server Link https://fcm.googleapis.com/fcm/send Google Cloud Messaging server link URL, if GCM is enabled.
Uploading Client Resources

(Applies only to native, hybrid, and Agentry) Upload client resources, or resource bundles, for the selected application. Resource bundles
are containers used by applications to download dynamic con gurations, styles, or content from the server. The application developer
must set up the capability to use client resource bundles through the OData SDK or REST API SDK, before the administrator can modify
settings in Management Cockpit.
Context
Keep in mind these resource bundle guidelines:
Supportability – a resource bundle can be of any le type (.pdf, .xls, .xml, or any other extension).
Size – there are no restrictions on resource bundle size. For best performance, SAP recommends a maximum of 1MB. If you need
resource bundles that are larger than 1MB, work with the application developer to address any performance issues.
Default resource bundle – the rst resource bundle you upload is considered to be the default. After that, you can upload
additional versions of the bundle, but only one can be the default. You can delete obsolete resource bundle versions.
URL for the default resource bundle – http://<ServerIP>:<Port>/bundles/<ApplicationName>/
URL to access other resource bundles – http://<ServerIP>:<Port>/bundles/<ApplicationName>/<BundleName>:

<BundleVersion>
Procedure
1. In Management Cockpit, select Applications, select the application, and then click Con gure Client Resources .
2. Under Client Resources, enter values.
a. Enter the customization resource bundle name and version.
b. Click Browse, select the le to be uploaded, and con rm. The resource bundle name appears under Bundle Name.
3. Select the resource bundle to make it the default.
5/12/2023
Updating a Resource Bundle
Upload a newer version of a resource bundle. You can make the new version the default. You cannot assign a new default resource
bundle, and delete an old resource bundle in the same step; you must use separate steps.
Deleting a Resource Bundle
Delete a resource bundle from the application de nition. This may be required if an error is discovered, or a newer resource
bundle has been uploaded. You cannot assign a new default resource bundle, and delete an old resource bundle in the same step;
you must use separate steps.
Previous task: De ning Push Noti cations
Next task: De ning Application-Speci c Settings
Updating a Resource Bundle

Upload a newer version of a resource bundle. You can make the new version the default. You cannot assign a new default resource
bundle, and delete an old resource bundle in the same step; you must use separate steps.
Procedure
2. Select a new resource bundle to upload.
3. Select the new resource bundle to make it the default.
4. Click Save.
Deleting a Resource Bundle

Delete a resource bundle from the application de nition. This may be required if an error is discovered, or a newer resource bundle has
been uploaded. You cannot assign a new default resource bundle, and delete an old resource bundle in the same step; you must use
separate steps.
Procedure
2. Select a bundle.
3. Click Delete, and con rm.
De ning Application-Speci c Settings

(Optional, applies only to hybrid and Agentry) Con gure application-speci c settings for the selected application, using Management
Cockpit, con guration les, or other tools.
Uploading and Deploying Hybrid Apps

If the selected hybrid app uses the AppUpdate plugin, you can activate a new version of the app.
To publish a new Agentry application, upload the Agentry application ZIP le to SAP Mobile Platform Server. To update an Agentry
application, you must publish a new version using a new ZIP to change the de nitions.
Managing Agentry App Versions
View multiple versions of published Agentry applications that are currently in use, and delete versions that are no longer needed.
5/12/2023
After you upload an Agentry application, you can change the Agentry production application de nitions made by the developer,
and con gure additional Agentry application settings. Some settings apply to the current application, and others apply to all
applications.
Update Agentry con guration les, and deploy the changes to the production environment. Agentry con guration les include
back-end connection les, and override les (localization les, query les, and constants les). Con guration les may apply to the
landscape, or to a particular application. In some cases, you must restart the application before the changes take effect, in others
you must restart SAP Mobile Platform Server.
Con guring the Transmit Con guration File for Agentry Applications
To override transmit values for an application, you can create a transmit con guration le. This can be useful when you are
running multiple Agentry applications on SAP Mobile Platform Server.
Restarting an Agentry Application
Restart an Agentry application in Management Cockpit.
Agentry applications provide full support for localizing mobile applications without directly modifying the application project
de nitions.
Con guring User Language Selection
Con gure the ability for Agentry client end users to select the desired language within the Agentry application, overriding the
default device operating language settings.
Previous task: Uploading Client Resources
Next task: De ning Offline Application Settings
Uploading and Deploying Hybrid Apps

If the selected hybrid app uses the AppUpdate plugin, you can activate a new version of the app.
Prerequisites
A hybrid app package that:
Contains the contents of the application's www folder and the config.xml project le, with a separate folder in the archive for
each mobile platform (android/www and/or ios/www in all lowercase). The format structure for a hybrid apps is:
|- android
| |- config.xml
| |- www
|- iOS
Is compressed into a standard .zip le for upload.
Procedure
2. For an application, select Con gure Application-Speci c Settings .
3. To import a new application or update an existing application version, click Upload.
a. In the Kapsel Upload dialog, click Browse, and navigate to the directory that contains the hybrid app package.
b. Select the package, and click Upload.
New version information appears for the uploaded Kapsel app for each mobile platform. You cannot change this information.
Kapsel App Properties
5/12/2023
Operating System The operating system on which the application runs.
Revisions Identi es the production version revision. A revision number is assigned to a newly uploaded Kapsel
app and incremented when a new version is uploaded.
 Note
When the Kapsel app is deployed, the revision number is incremented.
Required Kapsel Version Identi es the Kapsel SDK version that was used to develop the Kapsel app, for example, 3.0.0.
 Note
This version attribute is informational only; it is not used to determine whether device clients
should receive a Web application update.
Development Version Identi es the internal development version that was used to develop the Kapsel app.
Uploaded By The user who uploaded the Kapsel app.
Last Modi ed Date last modi ed.
State State of the Kapsel app version:
New – a newly uploaded version.
Staged – in testing. A user who is de ned as a tester can download and test applications. See
Managing Registrations and Users.
Once testing is complete, an administrator can promote a version to the Current state, so it
becomes active. If testing fails, the administrator can change the state back to New.
Current – the version that is currently active.
Moving Applications Between States
Beginning Action Ending State

State
New Click Stage Staged
New Click Deploy Current
Staged Click Remove New
Staged Click Deploy Current
 Note
Each platform can have an unlimited number of versions in the New state, but only one version in
the Staged state, and one version in the Current state.
4. To deploy applications, select the check box for each application you want to deploy, and click Deploy.
Deployed Kapsel app information appears as the current version, and the revision number is incremented.
For device-application users:
If a Kapsel app with the default version (revision = 0) connects to the server, the server downloads the full Kapsel app.
If a Kapsel app with a version (revision = 1 or higher) connects to the server, the server calculates the difference between
the user's version and the new version, and downloads a patch containing only the required changes.
If the application implements the AppUpdate plugin, the server checks for updates when the application starts or resumes.
If the developer has made changes, AppUpdate detects them using the www folder content (the HTML-based content), and
not with native plugins or changes made outside of that folder. For changes made outside the www folder, the developer
must post a new copy of the app to the application download site, or use Afaria to push the new app to all users.
5/12/2023
5. To remove application versions that have been imported, but not yet deployed, select the check box for each application you want
to remove, and click Remove.
To optimize life-cycle management for Kapsel applications and to provide more efficient client updates, mobile services archive a
limited number of applications that a client has previously downloaded to his or her device. If a client requests an application
update and the client version of the application is available, the delta version is sent to the client; if the client version is not
available, the full version is sent to the client.
Managing Application Versions Using REST APIs

You can automate application version management by integrating it into your application build or application artifact management
processes: use REST APIs to deploy, promote, delete, and view information for application versions.
 Note
The REST API calls must be made using a secure port and the HTTPS protocol. Please see your client documentation for details on
how to submit a request over HTTPS to satisfy the server's security requirements.
Deploying Hybrid Apps Using the REST API

Deploy a new or updated hybrid app to SAP Mobile Platform Server using the deploy application REST API.
Promoting Hybrid Apps Using the REST API
Promote a new hybrid app to make it the current version of the application using the promote application REST API.
Retrieving Hybrid App Details Using the REST API
Retrieves details on any new or current versions of a hybrid app using the retrieve application details REST API.
Deleting Hybrid App Details Using the REST API
Delete a hybrid app using the delete application REST API.
Deploying Hybrid Apps Using the REST API

Deploy a new or updated hybrid app to SAP Mobile Platform Server using the deploy application REST API.
Once the application is deployed, it is considered to be a new version. You can make it the current version using the promotion REST API.
After the application is promoted, users can download a patch to upgrade the application on their devices.
 Note
It is not possible to deploy a hybrid app for a speci c platform: everything in the le is deployed. Once the application is deployed, you
can promote or delete hybrid apps for speci c platforms as needed.
Syntax
Perform a POST request to the following URI:
https://<host>:<admin_port>/Admin/kapsel/jaxrs/KapselApp/{APP_ID}
Parameters
le The le that contains the application archive, sent as multipart/form-data.
Returns
A response providing information about the new and current version of the application. For example:
5/12/2023
{"newVersion":
{"requiredKapselVersion":"1.5",
"developmentVersion":"1.2.5",
"description":"An update for the sample app.",
"revision":-1},
"currentVersion":
{"requiredKapselVersion":"1.5",
"developmentVersion":"1.2.4",
"description":"A sample app.",
"revision":2}
}
On successful deployment, the client receives a 201 status code; otherwise, an HTTP failure code and message.
Examples
 Note
This example uses the curl command line client and the --cacert ag. Your client may require you to pass other arguments or set
speci c con guration options.
Deploy application to all platforms
curl --user <user>:<password> --cacert <your-server.pem> --form "file=@C:\work\app1.zip" https://loca
Promoting Hybrid Apps Using the REST API

Promote a new hybrid app to make it the current version of the application using the promote application REST API.
 Note
You can promote a hybrid app for a speci c platform or for all platforms
Syntax
To promote for all platform, perform a PUT request to the following URI:
To promote for a speci c platform, perform a PUT request to the following URI::
https://<host>:<admin_port>/Admin/kapsel/jaxrs/KapselApp/{APP_ID}/{PLATFORM}
Include the user name and password in the request to provide authentication for the URI.
After the application is promoted, users can download a patch to upgrade the application on their device.
Parameters
None.
Returns
On successful promotion, the client receives a 200 status code. Otherwise, an HTTP failure code and failure message are returned.
5/12/2023
Examples
 Note
Promote Application
curl --user <user>:<password> --cacert <your-server.pem> --X PUT -i https://localhost:8083/Admin/kaps
Retrieving Hybrid App Details Using the REST API

Retrieves details on any new or current versions of a hybrid app using the retrieve application details REST API.
Syntax
Perform a GET request to the following URI:
Parameters
None.
Returns
On successful retrieval of details, the client receives a 200 status code. Otherwise, an HTTP failure code and failure message are
returned.
Examples
 Note
Retrieve Application Details
curl --user <user>:<password> --cacert <your-server.pem> --X GET -i https://localhost:8083/Admin/kaps
Deleting Hybrid App Details Using the REST API

Delete a hybrid app using the delete application REST API.
 Note
You can delete a hybrid app from a speci c platform or from all platforms
Syntax
To delete from all platforms, perform a DELETE request to the following URI:
5/12/2023
To delete from a speci c platform, perform a DELETE request to the following URI:
https://<host>:<admin_port>/Admin/kapsel/jaxrs/KapselApp/{APP_ID}/{PLATFORM}
Parameters
None.
Returns
On successful deletion, the client receives a 200 status code. Otherwise, an HTTP failure code and failure message are returned.
Examples
 Note
Delete application from all platforms
curl --user <user>:<password> --cacert <your-server.pem> --X DELETE -i https://localhost:8083/Admin/k

To publish a new Agentry application, upload the Agentry application ZIP le to SAP Mobile Platform Server. To update an Agentry
application, you must publish a new version using a new ZIP to change the de nitions.
Prerequisites
If you are using an Adaptive Server Enterprise database, before you publish in a cluster environment, verify that the database procedure
cache size is larger than the Agentry application size. If it is not, publishing is successful on the server node, but inserting into the
database and attempting to push to other server nodes in the cluster fails with the message Encountered error while saving the
application to the database. If you proceed without updating the cache size, old and new versions of the application will be used by
different sever nodes in the cluster.
 Note
The procedure to update the Adaptive Server Enterprise database cache size may vary by version, but see the following for a good
example: Procedure Cache .
Context
The application developer can use Agentry Editor to create an application ZIP le, which contains production de nitions, and any other
les the developer included. Only production applications can be published to Management Cockpit.
The administrator uploads the ZIP le to Management Cockpit, and can con gure additional Agentry settings, and change some Agentry
con guration settings made by the developer.
Procedure
5/12/2023
1. In Management Cockpit, select Applications Con gure Application-Speci c Settings .
2. Under Publish, click Browse to locate the Agentry application ZIP le that was created by the application developer. For example,
Northwind-app.zip.
When you publish a new version of an Agentry application, it appears under Published Versions.
3. Con gure additional Agentry settings as needed. Changes to some con guration values may require you to restart the application
for the changes take effect.
Related Information
Managing Agentry App Versions

View multiple versions of published Agentry applications that are currently in use, and delete versions that are no longer needed.
Context
When you publish a new version of an Agentry application, it appears in the Published Versions section of the App Speci c Settings
screen in Management Cockpit. Although you are allowed to maintain multiple versions of an application, it is a good practice to delete
old versions to clean up the database, release memory, and improve load time performance. Before you delete a version, ensure that all
users have upgraded to the newest version. Deleting active versions renders clients using those versions inoperable, and requires the
client application to be reset.
Procedure
2. Under Published Versions, review the list of current application versions.
3. Select an application version, and click the Delete icon . The application version is removed from the list

After you upload an Agentry application, you can change the Agentry production application de nitions made by the developer, and
con gure additional Agentry application settings. Some settings apply to the current application, and others apply to all applications.
Context
If you change settings in a section marked "Affects All Agentry Applications", keep in mind that all Agentry applications are affected.
 Note
The sections that appear and their order vary, depending on how the Agentry application has been developed. The settings that affect
all applications are grouped at the end. The Publish and Logging sections are documented separately.
Procedure
2. Under Time Zone Aliases, map time zone names on remote systems (client devices and back-end systems) to time zone names
on this server. Create a list of key-value pairs, one key-value per line, in the format: "key=value". The keys are the time zone names
5/12/2023
on the remote systems; the values are the equivalent time zone names for the server's host operating system. For example, enter
Central Standard Time=America/Chicago or UTC+2:00=E. Europe.
 Note
The UTC notation (such as UTC+4:00=Moscow Standard Time) is recommended, especially outside of the United States.
3. Under SpinDoc, edit the values that are exposed to the Agentry application as variables [Server Data Markup Language (SDML)],
and the "Face Path" setting.
Face facePath=sql\custom;sql The Face Path setting de nes the search path used by the SQL back end to locate the query
Path les, which are used for database initialization, authentication, password changes, and so
facepath=sql\custom;sql
forth; and the SQL script les, which are used for SQL back-end processing. If this setting is
missing, there is no default to use, so processing may fail.
4. Under Con guration, edit settings for the Agentry directory and path location for con guration-related les.
Application Globals.ini Name and location of the globals localization le. You
Globals File can change this setting if the name of the le is
different from the default.
Application ApplicationText.ini Name and location of the application strings

Strings File localization le. You can change this setting if the name
of the le is different from the default..
Client String ClientStringNames.ini Name and location of the client string names
Names File localization le. You can change this setting if the name
of the le is different from the default. Changes to this
property require an application restart.
Client ClientText.ini Name of the client strings localization le. You can
Strings File change this setting if the name of the le is different
from the default.
Development N/A Read-only. Whether the application is development or

Server production.
Enable Failed True Whether to enable the failed transaction queue, which
Transaction is a part of the transaction failure handling
Logging functionality. By default, when transaction failure
handling is enabled, transactions that fail with a fatal
error code result in the creation of a failed transaction
le on the server containing the data from that
transaction. If this option is set to false, the le is not
generated.
All remaining transaction failure handling behaviors are
carried out, including the removal of the failed
transaction from the client.
 Note
Setting this option to false may result in lost data
for fatal errors that are related to transaction
processing. This option has no effect if transaction
failure handling is disabled (that is,
enableTransactionFailureHandling is false.
Enable Enables.ini Name and location of the enables localization le.

Override File Change this setting only if the le name is different
from the default.
5/12/2023
Enable False Whether to enable the transaction failure handling

Transaction functionality within the Agentry platform. This option
Failure must be true for all aspects of this functionality to be
Handling enabled.
Failed Server-generated XML le name Format of the le name for each failed transaction
Transaction queue le generated by the server. The format strings
Filename %{userid}, %{transaction_name}, %{date}, %
Format {time}, and %{count} may be used. The le
generated is always be in XML format, and the le
extension provided (.xml) should re ect this content
type.
Failed FailedTransactionsQueue Location of the failed transaction queue les. This path
Transaction is relative to the installation folder of the server.
Queue
Images Path \Application\<Development_or_Production>\Images Location of image les in either the development or

production environment.
Localization localizations Location of localization les for use in the application.

Path This path is relative to the server’s installation folder. If
the default folder “localizations” does not exist, it must
be created.
Localizations None One or more local names, according to the ISO 639-1
standard. This option lists the supported languages,
which also require corresponding override localization
les, for an application. Use semicolons to separate
names.
Scripts Path Application\Development\Scripts If you use an Server Data Markup Language (SDML) tag
in the Agentry application that includes content from a
le using a relative path, this is the directory under
which the le in question needs to be located.
Spin Doc INI None If this value is speci ed, then the [SpinDoc]
File con guration is loaded from the named .ini le
instead of from Agentry.ini.
Transmit TransmitConfigurations.ini Name and location of the transmit con gurations

Con guration override le. Change this setting if the le name is
File different from the default.
Trusted None Location of the trusted certi cate store for the server.
Certi cate This store is used only when clients are required to
Store provide authentication certi cates during
synchronization.
URL Path None Overrides the path portion of the WebSockets URL (for
example, if the URL is
https://<server>:8081/<MyApp>, this value
overrides <MyApp>, which is the default application
name.
5. Under User Selectable Languages, add a list of key-value pairs that represent the language codes and human readable display
names for each language in the format <code>=<display name>.
The language codes should match the string of codes used in the "Localizations" con guration setting (see Step 4, Con guration),
and the display names should be the desired display names for each language in the application. Ideally, use the native spelling of
each language option for the display name (for example, "Español" for Spanish). Enter each language key-value pair as one entry
per line, for example:
5/12/2023
de=Deutsche
en=English
es=Español
fr=Français
See Con guring User Language Selection for additional information.
6. Under Logging (Affects All Agentry Applications), set these logging values:
Event Log Valid le name, or path The le to which event log items are written. You can change the default to specify a different le
File and le name; the default name or location. The path can be relative to the server installation folder; or a full path that
is events.log. includes the drive letter. Requires server restart.
Maximum Numeric value, in bytes; The maximum size of the log le in bytes. A value of 0 indicates no maximum size. Any other
Log Size the default is 0. value results in the log le rolling over when the le exceeds the value set here.
Log Roll Time of day in 24-hour The time at which to roll log les. The server must be running for the les to roll over at the
Time clock format (HH:MM); the speci ed time. Requires server restart.
default is 1:00am.
Log Rolls Enabled or disabled; the Whether to roll the log les based on the time de ned in Log Roll Time. Requires server restart.
At Time default is enabled.
Message Valid le name, or path The le to which message log items are written. You can change the default to specify a different
Log File and le name; the default le name or location. The path can be relative to the server installation folder; or a full path that
is messages.log. includes the drive letter. Requires server restart.
7. Under Agentry (Affects All Agentry Applications), edit Agentry application settings.
Keep 3600 Interval during which the server writes something to the various log les, if nothing else has been written during
Alive (seconds) that time period to indicate that the server is not dead. Changes to this property require an application restart.
Delta
Shut 15000 Length of time Agentry waits for all of its threads to exit while shutting down, before it stops them.
Down (milliseconds)
Wait
System Agentry Name of the Agentry server, which appears in the title bar of the server’s GUI interface on the console. Changes
Name to this property require an application restart.
8. Under Server (Affects All Agentry Applications), edit administrator contact information and client timeout and noti cation
settings.
Properties Defaults Descriptions
Administrator admin@yourcompany.com Administrator e-mail address.

Email
Administrator Your Name Here Administrator name.

Name
Administrator ???-???-???? Telephone number for contacting the administrator.

Phone
Allow Relogin Enabled Whether to allow users to relogin.
Inactive Timeout 7200 (seconds) Length of time that an idle user can remain connected to the server before the connection
is dropped.
5/12/2023
Properties Defaults Descriptions
Maximum 16383 Maximum size to which a segment can grow.

Segment Size
Notify User on Disabled Whether to notify the user on log out.

Logout
Notify User on Disabled Whether to notify the user on shut down.

Shutdown
Websockets Keep 60 (seconds) Speci es how often the server sends a keep alive message to the client. This message
Alive Period may prevent network devices from closing the connection due to inactivity.
9. Restart the application if you modi ed any values that require it.
Related Information
ClientText.ini
Globals.ini Format
ApplicationText.ini Format
Enables.ini Format
Localization Files

Update Agentry con guration les, and deploy the changes to the production environment. Agentry con guration les include back-end
connection les, and override les (localization les, query les, and constants les). Con guration les may apply to the landscape, or to
a particular application. In some cases, you must restart the application before the changes take effect, in others you must restart SAP
Mobile Platform Server.
Context
Developers create con guration les as part of application development. This typically involves copying and renaming a template
le to use as a base. For example, use the ClientTextBase.ini template le to create ClientText.ini, then modify
ClientText.ini to change the con guration settings.
Once the con guration les are published to SAP Mobile Platform Server, they are stored in the production database.
Administrators can update con guration les, or work with developers to update them. The updated les must be republished
using Agentry Editor and Management Cockpit.
 Note
Do not modify the con guration les directly on the server; those changes will be overwritten by les in the production
database.
Some changes require you to restart the application for the changes to take effect:
Changes to con guration items that are related to a con guration le require an application restart. For example,
changing the content of an existing le, like SqlBE.ini, or changing the Query Init File of a SQL back end from
SqlBE.ini to SqlBE_Oracle.ini.
5/12/2023
Changes to actual code require an application restart. For example, changing Java code for the Java back end.
Changes to the SQL query les require an application restart, if the SQL back end’s preloadQueries setting is true.
Updates to application con guration les require an application restart. For example, if a new version of the application
that includes updated con guration les is published from one server in the cluster, you must restart each SAP Mobile
Platform Server in the cluster.
Changes to any settings where Management Cockpit indicates it is necessary, require an application restart.
Changes made in sections labeled "Affects All Agentry Applications" in the App Speci c Settings screen require a SAP Mobile
Platform Server restart for the changes to take effect.
Procedure
1. Use any text editor to update con guration les.
2. Use Agentry Editor to publish the application. Include the updated con guration les in the publish folder structure, along with the
product de nitions, so they are included in the ZIP le.
3. In Management Cockpit, use App Speci c Settings to publish the new ZIP le. You can complete any additional Agentry
application con guration tasks as well. When you save the ZIP le, it is uploaded through the browser to SAP Mobile Platform
Server, and published. You are noti ed of success or failure.
4. Restart the application, or SAP Mobile Platform Server if required. In a cluster environment, restart the application on each
server in the cluster, to distribute the con guration changes. Application users can then obtain the updated application version on
their devices, from the server.
Related Information
ClientText.ini
Globals.ini Format
Enables.ini Format
Localization Files
Con guring the Transmit Con guration File for Agentry Applications
To override transmit values for an application, you can create a transmit con guration le. This can be useful when you are running
multiple Agentry applications on SAP Mobile Platform Server.
Production Work ow
1. (Administrator) Work with developers to create a text le called TransmitConfigurations.ini in the application project.
2. (Developer) In the text le, for each transmit con guration to override, create a section called
[<TransmitConfigurationName>]. Place any override attributes in each section as is appropriate. Include the le when you
publish the project to production. See Publishing to Production in Developer > Agentry App Development .
3. (Administrator) Import the project ZIP le to the server.
5/12/2023
4. (Administrator) In Management Cockpit, select the application and navigate to Application-Speci c Settings. Under
Con guration, make sure the value of Transmit Con guration File points to this ZIP le location.
5. (Administrator) To initiate the changes, restart the application on each server.
 Note
Make changes to the TransmitConfigurations.ini le in the development environment, not on SAP Mobile Platform
Server, and publish a new ZIP le in Management Cockpit. Do not modify the le on the server, or it will be overwritten when
you upgrade the server.
Restart each server in a cluster to distribute the changes.
TransmitCon gurations.ini
The TransmitConfigurations.ini le has one section for each transmit con guration that is de ned in the application, where
<TransmitCon gurationName> is the name of the de nition within the application project. Each section can contain override values for
any and all attributes within a given transmit con guration de nition.
The following example shows several options that are valid within each section of the TransmitConfigrations.ini override le. The
value for stayLoggedIn overrides the general attribute Stay Logged In.
[<TransmitConfigurationName>]
stayLoggedIn=true
retryPeriod=30
retryAttempts=5
onlineRetryAttempts=5
serverInactiveTimeoutOverride=300
All other attributes within the transmit con guration de nition can be overridden using the proper key and value pair. Any attributes that
are not overridden in TransmitConfigurations.ini are sent to Agentry Clients as they are de ned in the application project.
If you have multiple Agentry applications, each server should have its own version of TransmitConfigurations.ini that includes
overrides for the required con guration settings that are unique to that server instance.
TransmitCon gurations.ini Attributes

For information about de nition attributes, see Developer > Agentry App Development > Agentry Language Reference > Application
Level De nitions Overview > Transmit Con guration.
General Settings
Override Item Setting Acceptable Values Description
Name Name of the transmit con guration, which must be unique for all
transmit con gurations de ned for the application.
displayName Display Name Any printable text Each transmit con guration de ned in the application is listed
in the Transmit Dialog on the Agentry application, so choose an
appropriate Display Name that is meaningful to the application
end user.
connectType Connect Type WebSockets over HTTPS Communications protocol used when synchronizing with SAP
xmitCon gGroup Group Transmit Con guration Group into which the transmit con guration is organized within
Group Name the application. There are two default options, Fast and Slow, or
you can create a new group by entering a name in this eld. Any
group name you enter here becomes available to all transmit
con gurations within the same application project.
5/12/2023
failoverTo Failover to Name of other transmit You can select a failover transmit con guration to be used if an
con guration de nition. Agentry application cannot connect to a server using the rst
transmit con guration. You can assign this attribute to any other
transmit con guration within the application.
checkDataTables Check Data Tables true/false Speci es whether the data tables within the application are
synchronized when the transmit con guration is used.
 Note
Consider not selecting this attribute for transmit
con gurations that are intended for slower connection types.
checkComplexTables Check Complex Tables true/false Speci es whether complex tables within the application are
synchronized when the transmit con guration is used.
 Note
Consider not selecting this attribute for transmit
con gurations that are intended for slower connection types.
Session Attributes
Override Item Setting Acceptable Value Description
stayLoggedIn Stay Logged In Keep the client user logged in and the application connected
to the server to support real-time communications within the
mobile application, which includes background sending and
push behaviors. Set this attribute when an Agentry
application requires a constant network connection to the
back-end data.
promptOnLogin Prompt on Log In true/false Display a prompt when the connection between the
application and the server is lost, and the application
attempts to reconnect.
promptOnLogout Prompt on Log Out true/false Display a prompt when the Agentry application is logged out
of the server.
serverInactiveTimeoutOverride Inactive Timeout Duration value in Speci es the time limit, in seconds, to keep the application
number of seconds. connected to the server, both when there is no data
transmission activity between the client and server, and
during an actual transmit. If you experience frequent
disconnects, increase this number.
attemptOnlinePeriod When Off-line -1: Stay offline If the connection to the server is lost, indicates whether to
stay offline or attempt to reconnect at the speci ed interval.
1+: Attempt to work
online every [1+]
seconds
onlineRetryAttempts Attempts Number of attempts to If you select to reconnect when offline, indicate the number of
connect to server. attempts to reconnect. If the number of reconnect attempts
fail, the way the application responds depends on the
Transmit Con guration attributes you de ned. For example,
the application can display a prompt or switch to the failover
transmit con guration.
reconnectAttemptPeriod Reconnect Attempt Duration value, in If online, indicates how often the client should try to
Period number of seconds reconnect.
retryPeriod Retry Period Duration value, in If the connection to the server is lost, indicates how long to
number of seconds attempt to reconnect.
5/12/2023
Override Item Setting Acceptable Value Description
keepAlivePeriod Keep Alive Period Value in seconds (the Determines how often a keep alive message is sent by either
default is 0, meaning the client or the server. Keep alive messages are sent only for
no keep-alive transmit con gurations that are de ned to "stay connected",
messages) which means that either background sending, and/or pushes
must be enabled.
If pushes are enabled, the server sends the keep

alive message to the client. For example, when
keepAlivePeriod=45, the server sends a keep
alive message to the client every 45 seconds.
Otherwise, if only background sending is enabled, the

client sends keep alive messages to the server. For
example, when keepAlivePeriod=60, the client
sends a keep alive message to the server every 60
seconds.
If set to the default value of 0, no keep alive

messages are sent.
Background Sending
backgroundConnection Allow background true/false Whether to allow Agentry clients to send transactions in the
sending from client background. When background sending is enabled, clients
remain logged into the server, and send completed transactions
in the background while a user continues to work online. When a
user works offline, transactions are sent when a connection is
available.
 Note
You must set this attribute before you can set the other
Background Sending attributes for the transmit
con guration.
retryPeriod Retry Period Duration in number of If background sending is enabled, speci es the amount of time,
seconds in seconds, to wait before attempting to resend a failed
message.
retryAttempts Retry Attempts Number of background If background sending is enabled, speci es the number of
sending attempts to times the client should attempt to resend a failed message.
connect to server
Push
Allow server to push None Allow the server to push data to the application. A de nition for
data to client the Pushes module must exist for the application. Users
connecting to the server are logged in as push users.
 Note
You must set this attribute before you can set the other push
attributes for the transmit con guration.
retryPeriod Retry Period None If "Allow server to push data to client" is selected, this attribute
speci es how long the server waits before attempting to resend
data for a push when a failure occurs.
5/12/2023
attempts Attempts None If "Allow server to push data to client" is selected, speci es how
many attempts to push data to the application when a failure
occurs.
clientPort Client Port Disabled for WebSockets
Modem Settings
Override Item Setting Modem Attribute Description
networkConnectionCheck Check for Modem true/false Whether the Agentry application checks for a modem
Connection connection when using the transmit con guration prior to
beginning the transmit.
 Note
You must set this attribute before you can set the other
modem connection attributes for the transmit con guration.
networkConnectionName Connection Name Name of Windows Two options:

network connection. Any dial-up connection requires a user to establish the
network connection manually outside the mobile
application before beginning the transmit. The
remaining modem connection attributes are disabled.
Name of any Windows network connection that is

con gured on the client device. This option uses the
settings of the speci ed connection to establish the
modem connection to the network.
connectNetwork If Not Connected true/false Speci es that the application attempt to create a connection
using the speci ed Windows network connection when there is
no current connection. If this option is not selected, the
remaining modem connection attributes are disabled.
networkConnectionPrompt Connect Prompt Any printable text. Provides instructions to the user on the client prior to
Carriage returns not attempting to create a modem connection. Leave blank if no
allowed. Text auto-wrap message is required.
on the client.
dialUsernamePrompt Prompt User for Dial-up true/false Prompts the user to enter a user name for the network
Username connection, which is used as the login name for the network
connection once the modem’s hand-shaking processes are
successful. If this option is not selected, the Agentry
application login is used.
dialPasswordPrompt Prompt User for Dial-up true/false Prompts the user to enter a password for the network
Password connection. If this option is not selected, the Agentry
application password is used.
modemInitWait Modem Init Wait Duration value, in Speci es the amount of time, in milliseconds, to wait for the
milliseconds client device’s modem to initialize before beginning the dial-up
process.
postConnectWait Post-connect Wait Duration value, in Speci es the amount of time, in milliseconds, to wait after the
milliseconds network connection is made before beginning the transmit
process between the client and server.
closeConnectionPeriod Close Connection Duration value, in Speci es when to close the modem connection once no more
seconds. data is being transmitted between client and server:
Never
If the connection is idle for the speci ed number of

minutes and seconds.
remindToTurnOnModem Remind to Turn On true/false Whether to remind user to turn on modem.

Modem
5/12/2023
Override Item Setting Modem Attribute Description
remindToTurnOffModem Remind to Turn Off true/false Whether to remind user to turn off modem.

Modem
Related Information
Agentry Client Disconnected after Application or Server Restart

Restart an Agentry application in Management Cockpit.
Context
This is useful for restarting an application after making con guration changes, without restarting the server, which would disconnect
users on all applications. In a cluster, the application is restarted on all server nodes in the cluster. (If you use the OSGi console to restart
an application, the application is restarted only on the current server node).
For a server that is not currently started, when you start it, all applications are started and the changes take effect.
Procedure
2. Identify the Agentry application, click the Actions icon, and Restart.
You are informed that the restart request was accepted and that the application will restart.
 Note
If the server fails to start, see the troubleshooting topic, Agentry Server Does Not Start .
Related Information
ClientText.ini
Globals.ini Format
Enables.ini Format
Localization Files

Agentry applications provide full support for localizing mobile applications without directly modifying the application project de nitions.
You can localize the application for one or more languages using localization override les, which replace the display values that are
de ned for the application. You can also use localization overrides for industry- or deployment-speci c terminology.
These localization base les are created by the Agentry Editor when an application is published to the server. The initial contents of these
les are based on the application de nition:
GlobalsBase.ini
5/12/2023
ApplicationTextBase.ini
The ClientTextBase.ini localization base le is located in

<SMP_HOME>\Server\configuration\com.sap.mobile.platform.server.agentry\.
To translate an application’s client UI into a language other than the one in which it was developed, the translator copies and modi es the
localization base les to create override les that contain a localized version of the display values. These les are read and processed by
the server during startup. The override values are then sent to clients during synchronization, after application de nitions are
synchronized but before production data is processed.
For single-language support, translators create only one set of override les. In Management Cockpit, specify the single-language
override les. See the Con guration step in Con guring Agentry Settings to enable the override le.
For multiple-language support, translators:
1. Create additional override les, one for each locale that is supported by the application. The override le name must use the
format:
<default_override_filename>.<locale_name>.ini
where <locale_name> is in the format <language>-<region> (<region> is optional).
2. Copy the override les to the localization folder for the application.
3. In Management Cockpit, specify the locales supported by the application, and the localization folder for the override les. See the
Con guration step in Con guring Agentry Settings to enable the override le.
For example, if:
Application Globals File = AppGlobals.ini
Application Strings File = AppStrings.ini
Client Strings File = ClientTextStrings.ini
Localization Path = localizations
Localizations = en-US;es-ES
The server loads and processes these les on startup:
AppGlobals.ini (default)
AppStrings.ini (default)
ClientTextStrings.ini (default)
localizations/AppStrings.en-US.ini (en-US)
localizations/ClientTextStrings.en-US.ini (en-US)
localizations/AppGlobals.es-ES.ini (es-ES)
localizations/AppGlobals.es-ES.ini (es-ES)
localizations/AppStringss.es-ES.ini (es-ES)
localizations/ClientTextStrings.es-ES.ini (es-ES)
The server uses the locale information provided by the Agentry clients to determine the proper override values, if any, to use. If the
Agentry client locale setting does not match the supported locales for the application, the values from the default localization les are
used. If no localization override les are speci ed, then the values that are de ned in the published application project are sent to the
client.
5/12/2023
To modify localization les, update the les, and use Agentry Editor and Management Cockpit to publish a new version of the application.
Do not update the con guration les on SAP Mobile Platform Server. Restart each server in a cluster to distribute the changes.
Localization Files
Application localization uses two le types: localization base les are created automatically by Agentry Editor during a publish to
the server, and localization override les override the values in the base les with localized values. Both le types are formatted in
plain text; you can use a standard text editor to open and edit them.
Related Information
ClientText.ini
Globals.ini Format
Enables.ini Format
Localization Files
Localization Files
Application localization uses two le types: localization base les are created automatically by Agentry Editor during a publish to the
server, and localization override les override the values in the base les with localized values. Both le types are formatted in plain text;
you can use a standard text editor to open and edit them.
When creating the localization override les:
Create override les only for the les that contain values you want to localize.
You can have a mix of localized and unlocalized values within each le.
Values in, and the behavior dictated by both le types always defaults back to the application de nitions within the Agentry
application project, if they are not de ned in the override les.
ClientText.ini
The ClientText.ini le contains display values that are part of every Agentry client, regardless of the application.
Globals.ini Format
The Globals.ini le contains the group, name, and de ned values of all global values de ned within the application.
The ApplicationText.ini le contains one section for each module de ned within the application, and an additional section
for the application de nition itself. Every module de nition includes a display name, label, or caption attribute. The key portion
identi es the module de nition, and the value contains the display name text.
Enables.ini Format
The Enables.ini le contains one section for each module de ned within the application. Each section lists all actions, pushes,
detail screen elds, and list screen columns that are de ned within the module. The value of each item is either true or false. It
is likely that most of the values are set to true, unless the de nition is disabled in the application.
Related Information
ClientText.ini
5/12/2023
Globals.ini Format
Enables.ini Format
ClientText.ini
The ClientText.ini le contains display values that are part of every Agentry client, regardless of the application.
This is an example of the contents of the ClientText.ini and ClientTextBase.ini les.
[Strings]
AG3_ABOUT_BMP_FILE=about.bmp
AG3_ABOUT_DIALOG_TEXT=About %1
AG3_ABOUT_MENU=&About %1...
AG3_ABOUT_TXT=about.txt
AG3_ABOUT_NAME=Agentry Client
AG3_ABOUT_OK=OK
AG3_ABOUT_PVERSION=Published As: v
The rst line is the section name [Strings], the only section in this le. The same ClientText and ClientTextBase.ini les are
used by all applications that are deployed on the same version of the SAP Mobile Platform Server for a given language. The values here
override the built-in components of the Agentry client and are not application-speci c.
The items in the above example are those that appear when the user selects Help About on the client. The keys for all items begin
with AG3_], followed by additional text that identi es the item to which the keys pertain.
The general naming convention of the keys is:
AG3_CATEGORY_COMPONENT
CATEGORY represents general resource (such as a built-in screen), or de nition type, (such as items related to actions). COMPONENT
describes the speci c component identi ed by the CATEGORY. So, in the above examples, ABOUT refers to the About built-in screen, and
NAME refers to the name value that appears in the About screen.
The values (that is, the text that follows the equal signs in each key) are the built-in display values or resources used by the client.
Changing the value in the le changes the item that appears on the client. For example, AG3_ABOUT_NAME has a value of Agentry
Client, which appears in the About screen. You might want to change this value if you rebrand your application.
5/12/2023
Related Information
Globals.ini Format
Enables.ini Format
Localization Files
Globals.ini Format
The Globals.ini le contains the group, name, and de ned values of all global values de ned within the application.
This is an example of the contents of the Globals.ini and GlobalsBase.ini les:
[STRINGLENGTHS]
; AddressMax: This is the maximum length for an address value.
AddressMax=40
; AddressMin: This is the minimum length for the Address value.
AddressMin=1
; CityMax: This is the maximum length for the City value.
CityMax=12
; CityMin: This is the minimum length for the City value.
CityMin=1
; PhoneMax: This is the maximum length for the Phone value.
PhoneMax=22
; PhoneMin: This is the minimum length for the Phone value.
PhoneMin=1
The rst line is the section name [STRINGLENGTHS], which corresponds to a de ned global group within the application project. Each
global group appears as a section within this le. All global values de ned within a group are listed within the appropriate section.
The second line is a comment line. All comments are preceded by a semicolon, and are automatically generated by the Agentry Editor
when the le is created. The comments are the description values of each global de nition. You can add comments to the base le and
5/12/2023
override le as needed.
The third line, AddressMax=40, is the rst global de nition within the StringLengths group. The name of the global de nition to
which this setting pertains is AddressMax. Its de ned value within the application project is 40, which means that any client Address
eld cannot exceed 40 characters.
Change these values to override the de ned behavior for the application. More speci cally, the value entered in the override le is the
one for the global on the client, affecting any other de nitions that reference the global value.
Related Information
ClientText.ini
Enables.ini Format
Localization Files
The ApplicationText.ini le contains one section for each module de ned within the application, and an additional section for the
application de nition itself. Every module de nition includes a display name, label, or caption attribute. The key portion identi es the
module de nition, and the value contains the display name text.
This is an example of the contents of the ApplicationText.ini and ApplicationTextBase.ini les:
[Customers]
module=Customers
object.MainObject=Main Object
property.MainObject.Customers=Customers
object.Customer=Customer
property.Customer.CustomerID=ID
property.Customer.CompanyName=Company
property.Customer.ContactName=Contact
 Note
The contents of this le are application-speci c. The above example is for a mobile application built for the Northwind demonstration
database in SQL Server.
This override le contains one section for each module de ned within the application, named [<ModuleName>], and one section named
[Misc] for application-level de nitions.
5/12/2023
The second line in the above example, module=Customers, represents the display name of the module. Each override item’s key follows
a de ned format:
<defType>.<ModuleLevelParent>.<parent>.<parent>.<definitionName>
defType – type of de nition that is overridden by the item. Examples include:
property
object
platform
listscreencaption
ModuleLevelParent – name of the module-level parent de nition, of the de nition whose display value is overridden.
Parent.Parent – name of each ancestor de nition, between the module level ancestor, and the de nition that is overridden.
definitionName – de nition name, which is overridden.
The last line in the above example, property.Customer.ContactName, contains the override value for the display name of the
property in the Customer object named ContactName. This le includes de nitions within the application that have a display name,
label, or caption attribute.
Related Information
ClientText.ini
Globals.ini Format
Enables.ini Format
Localization Files
Enables.ini Format
The Enables.ini le contains one section for each module de ned within the application. Each section lists all actions, pushes, detail
screen elds, and list screen columns that are de ned within the module. The value of each item is either true or false. It is likely that
most of the values are set to true, unless the de nition is disabled in the application.
The override le created from this base le can contain items with a value of false to disable the corresponding de nition, or true to
enable it. The effect of disabling a de nition depends on the de nition type. Disabled elds and columns do not appear on the client.
Users cannot execute disabled actions. A disabled push results in all behaviors related to that push being disabled. If there are no
enabled pushes, and background sending is not enabled, users do not remain logged in to the server, regardless of the transmit
con guration de nition.
This is an example of the contents of the Enables- and EnablesBase.ini les:
[Customers]
screencolumn.ShowCustomers.ShowCustomers_List_PPC.CustomerID=true
screencolumn.ShowCustomers.ShowCustomers_List_PPC.CompanyName=true
5/12/2023
action.AddCustomer=true
action.EditCustomer=true
The contents of this le are application-speci c. The above is an example for a mobile application built for the Northwind demonstration
database in SQL Server.
This override le contains one section name, [<ModuleName>], for each module de ned within the application.
The following line:
screencolumn.ShowCustomers.ShowCustomers_List_PPC.CustomerID=true
represents the screen column (screencolumn) CustomerID in the ShowCustomers_List_PPC list screen, which is a child de nition
to the ShowCustomers screen set. Each override item’s key follows a de ned format:
<defType>.<ModuleLevelParent>.<parent>.<parent>.<definitionName>
defType – de nition type being overridden by the item. Examples include:
action
screencolumn
field
ModuleLevelParent – name of the module-level parent de nition, of the de nition whose enabled state is being overridden.
Parent.Parent – name of each subsequent ancestor de nition, of the de nition being overridden is a part of the key.
definitionName – name of the de nition being overridden.
Related Information
ClientText.ini
Globals.ini Format
Localization Files

Con gure the ability for Agentry client end users to select the desired language within the Agentry application, overriding the default
device operating language settings.
Prerequisites
Add the language strings for the application, as described in Localizing Agentry Applications.
Con gure the Agentry application as described in Con guring Agentry Settings . In the Con guration section, the "Localization"
setting should include the language les you want to provide for the Agentry client.
5/12/2023
Context
Agentry provides the ability for the end-user to select the desired language within the Agentry application, overriding the default device
operating system language settings. This functionality is enabled by adding a set of user selectable languages for an Agentry application
on the SAP Mobile Platform Server in Application-Speci c Settings. When User Selectable Languages is populated within the application-
speci c settings on the server, the option to change languages appears in the Agentry client application.
For example, an Agentry client has been con gured for multiple languages. The app's Application-Speci c Settings Con guration
Localizations settings contain the value: de;en;es;fr.
To enable the end-user to pick one of the languages from within the Agentry app, the administrator would add a corresponding set of key-
value pairs to the "User Selectable Languages" section (one entry per line):
de=Deutsche
en=English
es=Español
fr=Français
Procedure
2. On Application-Speci c Settings, add a list of key-value pairs that represent the language codes and human readable display
names for each language in the format of <code>=<display name>.
The language codes should match the string of codes used in the "Localizations" con guration setting (on the same page), and
the display names should be the desired display names for each language in the application. Ideally, use the native spelling of each
language option for the display name (for example, "Español" for Spanish). Enter each language key-value pair as one entry per
line, for example:
de=Deutsche
en=English
es=Español
fr=Français
3. Save the settings.
4. Restart the Agentry application.
Next Steps
From this point on, for any Agentry client that connects to the application on this server, the Change Language menu option appears on
the client's main module selection screen. When the end user chooses the Change Language menu item in the application, a list of
available languages appears and they can choose one of the languages. The Agentry client performs a mandatory transmit to the server
to download the new language de nitions, and then the application displays in the selected language.
Related Information
De ning Offline Application Settings

De ne offline settings for the selected application. Offline support enables client applications to access back-end data without requiring a
connection. Offline applications access data from an offline store on the client. The server moves data between the back end and the
client offline store.
5/12/2023
Context
 Note
Does not apply to Agentry applications.
The offline back-end connection settings determine how the server creates the initial offline store database for the client, and how the
server processes requests for updates from the back end. You de ne offline back-end connection settings for an application by importing
a con guration le prepared by a developer. You cannot update the settings using Management Cockpit. If you need to adjust any
settings, you can export the le and make the updates, then remove the current con guration and re-import the le. You should only
make updates to this le in collaboration with the developer.
Procedure
1. In Management Cockpit, select Applications Con gure Offline Con guration .
2. Select the back-end connection you want to con gure offline settings for and click Import, then browse to select a con guration
le. Only INI type les can be imported.
For information about Application Con guration les, see:
SAP Mobile Platform SDK apps – De ning an Application Con guration File with De ning Requests
SAP Cloud Platform SDK for iOS apps – De ning an Application Con guration File with De ning Requests
The connection state changes to Configured and the connection settings display in Connections Details.
The De ning Requests tab displays information on how the server processes requests from the back end.
The Client Indexes tab displays information about the indexes created on the offline store client database.
The Detailed Settings tab displays all the information from the imported con guration le. If you need to adjust any of
these settings, you can export the le and make the updates, then remove the current con guration and re-import the le.
You should only make updates to this le in collaboration with the developer.
3. Click Save.
When the application goes offline for the rst time, the offline store is created on the server and downloaded to the client.
Subsequent client refreshes will use the current offline application settings on the server.
If you need to remove the current con guration in order to re-import a new con guration, select the connection name and click
Remove. The connection state changes to No Custom Settings.
Previous task: De ning Application-Speci c Settings
Next task: Saving Application Settings
Related Information
Server Con guration: Offline
Saving Application Settings

Save the application settings.
Procedure
1. Enter values in all mandatory elds and any additional con guration settings, then click Save.
5/12/2023
You can click Save on each tab of the selected application, or you can con gure settings on multiple tabs, then click Save. If you
leave application to access another menu option, and have unsaved changes, you are prompted to save.
2. Click the back arrow to return to Applications. The new application appears in the list.
Previous task: De ning Offline Application Settings
Managing and Monitoring Applications

Use Management Cockpit to manage applications, registrations, users, back-end connections to the data source; manage security
pro les; view application usage statistics; and manage and view application reports.
Managing Applications
Manage multiple native, hybrid, Web, Agentry, and MobileBI applications from a single location.
Managing Registrations and Users
Manage multiple native, hybrid, Web, and MobileBI application registrations from a single location. Registered applications are
associated with a user, an anonymous user, or nosec_identity on one or more devices.
Managing Users
Retrieve user application, device, and connection details for users.
Managing Feature Restriction Policies
Manage a list of feature restriction policies that apply to all applications from a central location. Feature examples include
camera, printer, and push. You can add, allow, restrict, edit, or delete features, and apply changes to existing hybrid applications.
Managing Client Database Uploads
Manage client database les that are uploaded from device users. You can download the le for analysis, or drill down to an
individual application to troubleshoot and review uploaded les for a speci c application.
Importing and Exporting Application Con gurations
The import and export of application con gurations enables you to copy a con guration from one SAP Mobile Platform Server
environment to another. For example, export an application con guration from the testing environment, and import it to the
production environment.
Transferring Applications Between System Landscapes
The enhanced Change and Transport System (CTS+) enables you to distribute artifacts, and automate deployment to different
target systems that are connected through transport routes. The SAP Mobile Platform CTS+ system uses SAP NetWeaver.
Managing Security Pro les
Manage multiple security pro les for native, hybrid, Web, Agentry, and Mobile BI applications from a single location.
Managing Connections
Manage multiple back-end connections for native, hybrid, Web, and mobile Business Intelligence (BI) applications from a single
location. You can de ne, edit, and delete back-end connections; test a connection using Ping, and lter connections based on the
connection name.
Viewing Server Usage Reports
View usage statistics for the SAP Mobile Platform Server. Usage reports appear in graphical form and provide a summary of
application registrations, number of users and requests, and response times.
Viewing and Purging Client Usage Reports
View aggregated usage statistics for native, hybrid, and Web applications. Usage reports are summaries of user sessions, which
you can lter by application, device type, operating system, or session duration. You can download reports to CSV les and import
them into tools such as SAP Lumira or Excel and you can purge them when no longer required.
Managing Application Logs and Traces
Set the verbosity for application and component logging, and the purge schedule for log and trace les. View all application logs or
the subset of your choosing, and drill down to view detailed log and trace information if available.
Con guring Agentry Application Logs
Con gure settings for Agentry logs. Agentry log le settings are con gured as part of de ning the application. Log settings apply
to all applications, not just the currently selected application.
Monitoring Hybrid Application Versions
When multiple versions of a hybrid application are running on registered devices, you can see the percentage of devices that are
running each version of the application.
5/12/2023
Managing and Monitoring Tasks By Application Type

Many of the application managing and monitoring tasks are the same for all application types. However, there are some tasks that differ,
or do not apply, for a particular application type. Most of these differences are for Agentry applications.
Managing Managing Managing Managing Managing Managing Applications

applications Applications Applications Applications Applications
Managing Managing Managing Managing Managing Not applicable

registrations Registrations Registrations Registrations Registrations
Managing Managing Users Managing Users Managing Users Managing Users Managing Users
users
Importing and Importing and Importing and Importing and Importing and Importing and Exporting
exporting Exporting Application Exporting Application Exporting Application Exporting Application Application Con gurations
applications Con gurations Con gurations Con gurations Con gurations
Managing Managing Back End Managing Back End Managing Back End Managing Back End Not applicable
connections Connections Connections Connections Connections
Managing Managing Security Managing Security Managing Security Managing Security Managing Security Pro les
security Pro les Pro les Pro les Pro les
Agentry includes an
pro les
additional security level.
Managing Managing Application Managing Application Managing Application Managing Application Viewing Agentry Logs
application Logs and Traces Logs and Traces Logs and Traces Logs and Traces (Agentry logs are viewed
logs under server logs)
Reporting Not applicable

Application Usage Application Usage Application Usage Application Usage
usage
Statistics Statistics Statistics Statistics
statistics
Managing Applications
Manage multiple native, hybrid, Web, Agentry, and MobileBI applications from a single location.
Context
You can add, edit, or delete applications; and ping a selected application for back-end connection and authorization URL status. View
information for all applications, or retrieve a ltered subset of applications. You can view the applications using a list view, or a tile view.
Procedure
Field Value
Application ID Unique identi er for the application, in reverse-domain notation. This is the application or bundled
identi er that the application developer assigns or generates during application development. The
administrator uses the application ID to register the application with SAP Mobile Platform, and the client
application uses the application ID to send requests to the server.
Name Application name can contain only alphanumeric characters, spaces, underscores, and periods, and be up
to 80 characters long.
Type Application type. Examples include native, hybrid, Web, Agentry, and MobileBI.
Vendor Vendor who developed the application.
5/12/2023
Field Value
Security Con guration The security setting for the application, such as None, Basic, and so forth.
Creation Date The date the application was deployed in SAP Mobile Platform.
2. (Optional) Use searching, ltering, and sorting options to display a subset of applications.
3. Identify an application of interest, and, under Actions, click .
4. Select Overview to view the information, registration, and usage details for the selected application.
The Information tab is a summary of settings for the selected application on a single screen. You can easily copy URLs to
paste elsewhere, avoiding typing errors and ensuring accuracy. See De ning Applications to set the information on this
tab.
Select Registrations to view details about valid application registrations.
Select Usage to see usage statistics for the application. Choose your display options:
Select the Usage category.
Select the Time Frame time period, including Today, Yesterday, Last 7 Days, Last 4 Weeks, Last 3 Months, and Last
12 Months.
Indicate whether to show data in bar-chart format (column or line), or table-chart format.
5. Use the back arrow to navigate back to the list or tile view; or select a menu option―such as Con gure, or Export―to continue
with the selected application.
Viewing Application Settings

The Overview tab shows you settings and exposed URLs for the selected application. The settings that appear vary by application
type, for example, Web applications do not include push settings and registration URLs.
Editing an Application
Edit an existing application from the application list.
Managing Application Versions
Administrators can activate or deactivate speci c versions of an application. If an application version is not active, users must
upgrade it to an active version. Multiple versions of an application can be active at the same time.
Deleting an Application
Delete the application from the application list.
Pinging a Back-End Connection
Test a back-end connection for a selected application.
Viewing Application Settings
5/12/2023
The Overview tab shows you settings and exposed URLs for the selected application. The settings that appear vary by application type,
for example, Web applications do not include push settings and registration URLs.
Procedure
2. Identify an application, and, under Actions, select Overview .
3. On the Information tab, view the settings and exposed URLs. The URLs are not live links, but represent accurate paths, so you can
copy them to paste into another location.
Application Settings
Setting Description
Application ID The application identi er.
Version The application version.
Name Application name.
Type Application type, such as Native, Hybrid, and Web.
Description Application description.
Creation Date Date the application was deployed in SAP Mobile Platform Server.
Vendor Application vendor, such as SAP.
Registration Threshold The registration threshold that is set for the application. Values are blank (default) or 0 indicating no
threshold; or 1 ‒ 2147483647.
Online Request Threshold The online request threshold that is set for the application. Values are blank (default) or 0 indicating no
threshold; or 1 ‒ 2147483647.
Offline Request Threshold The offline threshold that is set for the application. Values are blank (default) or 0 indicating no threshold; or
1 ‒ 2147483647.
Primary Back-End URL The URL for the primary back-end data source, for example, www.google.com or
https://<servername>:<port>/sap/opu/odata/sap/SMP_SDK_FLIGHT/.
Server URL The URL for the hosting server associated with the application, in the format:
https://<SERVERHOST>.
Mobile App URL The URL for the application:
If URL Rewrite Mode is set to "Rewrite URL on Back End," the URL format is:
https://<SERVERHOST>/<EndpointPath>.
Otherwise, the URL format is:
https://<SERVERHOST>/<Application_ID>.
Push URL (Does not apply to Web apps) The URL used for push noti cations to the application in the format:
https://<SERVERHOST>/Notification.
Enhanced Push API URL (Does not apply to Web apps) The URL used for push noti cations that implement the REST API, in the
format:
https://<SERVERHOST>/restnotification.
Registration URL (Does not apply to Web apps) The URL used by mobile device users to register for the application, in the
format:
https://<SERVERHOST>/odata/applications/<latest>/<Application_ID>/Connections.
Security Con guration Security con guration setting for the application, such as None, Form, Basic, Certi cate, and OAuth.
5/12/2023
Setting Description
CSRF Protection Whether cross-site request forgery protection is enabled for the application
Ignore Case for User Name Whether case-sensitive matching is used when comparing the registered user name for subsequent
application access and push noti cation
Push Con gured Whether push noti cations are con gured for the applications running on:
Apple devices
Android devices
BlackBerry devices
Windows devices
Windows Phone devices
Prede ned Push Con gured (Content to Go and Fiori Client) Whether the default push con guration that comes with the Apple App Store
and Google Play version of the app is enabled.
Automatic Removal Whether inactive registrations are removed automatically.
Editing an Application
Edit an existing application from the application list.
Procedure
2. Identify an application, and select Con gure .
The application tabs appear, such as Overview, Back End, Authentication, Push, and so forth.
 Note
The Overview tab appears only for registered applications.
3. Select a tab, and make changes.
4. Save your changes.
Managing Application Versions

Administrators can activate or deactivate speci c versions of an application. If an application version is not active, users must upgrade it
to an active version. Multiple versions of an application can be active at the same time.
Procedure
2. Identify an application, and select Con gure .
3. On the Information page, select Support Application Versioning.
4. To add a version, under Application Version Settings, select the Add new version icon , and in the new dialog, enter:
Version – application version number, for example, 1.0.
Active – select Yes or No.
5/12/2023
Description – optional description of the application version.
5. (Optional) To delete an application version, select it, and click the Remove selected version icon .
Deleting an Application
Delete the application from the application list.
Context
 Note
After you delete an application, clients cannot use it. All existing logs and traces are deleted and cannot be retrieved.
Procedure
2. Identify an application, and select Delete .
3. Click OK to con rm.

Procedure
1. In Management Cockpit, select Applications
2. Identify an application, and select Ping .
These values appear:
Connection Name
Back-End URL
Ping Result
3. Click OK.
Managing Registrations and Users

Manage multiple native, hybrid, Web, and MobileBI application registrations from a single location. Registered applications are
associated with a user, an anonymous user, or nosec_identity on one or more devices.
Context
When a user accesses an application from a device, the application is registered. View information for all application registrations, or
retrieve a ltered subset of registrations. For hybrid applications, if the developer has implemented Logger code in the application, you
can upload and view client logs. You can also delete registrations.
Registration is handled on the client side through Logon Manager. When a user logs in from a device (or is logged in anonymously by a
client application), SAP Mobile Platform Server authenticates the user using the security pro le con gured for the application. If
authentication is successful:
5/12/2023
1. The server generates a registration ID for the application+user+device combination, and creates a record in the database, which
allows the device application to consume SAP Mobile Platform data and services.
2. SAP Mobile Platform Server sends the registration ID to the device application.
3. For subsequent requests such as those to access a back-end data source, the device client sends the registration ID to the server.
Procedure
1. In Management Cockpit, select Registrations and Users.
2. (Optional) Select ltering options to display a subset of application registrations:
a. For Application Type, select All, or the application type to narrow the scope of application types.
b. For Application ID, select All, or the Application ID to narrow the scope of applications.
c. For Device Type, select All, or one or more device types to narrow the scope to speci c devices.
d. For Number of Entries, select the maximum number of registrations to display. Limiting the number of registrations
improves performance.
e. For From and To, use the date picker to identify a speci c date and time range.
f. For User Name, type a speci c user name to search only for that name.
You see information for registered applications.
Field Value
User Name Name of a person using the application registration. If the application is
con gured to "Allow Anonymous Access", the user name "anonymous" is
used for a successful registration, and can indicate:
The user did not provide credentials.
The user provided the wrong credentials.
The URL is pre xed with /public/.

If the security pro le is "No Authentication Challenge", the user name
"nosec_identity" is used for a successful registration.
Registration ID System-generated application registration ID.
Application ID Unique identi er for the application, in reverse-domain notation. This is the
application or bundled identi er that the application developer assigns or
generates during application development. The administrator uses the
application ID to register the application with SAP Mobile Platform, and the
client application uses the application ID to send requests to the server.
Application Type The application type, such as Hybrid or Native.
Device Type The parameter value, such as Android and iPhone, sent by the device during
registration/onboarding. "Unknown" indicates that the device type cannot be
detected.
Last Connection/Registration Time The date, time, and time zone the application was registered, in the format
MMM DD YYYY HH:MM:SS TZ.
Last Connection/Registration Time The date, time, and time zone the application was registered, in the format
MMM DD YYYY HH:MM:SS TZ.
Usage Upload Consent Given The date, time, and time zone when the usage upload consent was given, in
the format MMM DD YYYY HH:MM:SS TZ.
Usage Upload Consent Revoked The date, time, and time zone when the usage upload consent was revoked,
in the format MMM DD YYYY HH:MM:SS TZ.
5/12/2023
Field Value
Is Tester (Applies only to hybrid) Select Yes to specify that the user is a tester;
otherwise, select No. You cannot change this value for other applications. The
default value is No.
Users who are de ned as testers can test hybrid apps that are in the staged
state. See Uploading and Deploying Hybrid Apps.
Client Log Settings Enable log upload, specify the log level, and indicate how log to keep logs
before deleting for the selected row.
3. (Optional) Use ltering and sorting options to display a subset of the registration results.
Deleting a Registration
Delete an individual registration, which includes User Name, Registration ID, Application ID, Device Type, and so forth.
Update the client log and trace settings for the selected application registration.
Deleting a Registration
Delete an individual registration, which includes User Name, Registration ID, Application ID, Device Type, and so forth.
Context
This is useful for deleting orphaned registrations, which can occur when a user is no longer using an application on a device, or has
obtained a new mobile device, which requires its own registration. It can also be useful for clearing a registration while troubleshooting
con guration issues. Once the registration is deleted, the user will not be able to use the application on the device unless they reregister
the application.
Procedure
(Information for up to 200 registered applications appears.)
2. Select the application, and click Delete.

Update the client log and trace settings for the selected application registration.
Context
These settings override the client log policy settings that are con gured as part of the application de nition. Log and trace settings are
updated on the client during its next settings exchange with the server, and if log upload is enabled, the client uploads the log to the
server. The downloaded client log is a combined client/server log, so formatting will be different than in the original log. For applications
developed using SAP Mobile Platform SDK 3.0 SP05 or later, client log entries are stored in the database in the appropriate logging
component and can be viewed in the Logs & Traces view. For applications developed using SAP Mobile Platform SDK 3.0 SP04 or earlier,
you can download and view a client log le. Trace information is generated as part of an end to end trace session..
Procedure
Information for up to 200 registered applications appears.
5/12/2023
2. Use the search and ltering options to locate the registration in which you are interested:
3. Click the client log settings icon to display the Client Log Settings dialog.
a. Click Log Upload.
b. Select the logging level in Log Level to determine the type of messages captured in the client log, or None.
Logging Levels
Warn The application can recover from the anomaly, and ful ll the task, but requires attention from the developer
or operator.
c. For Delete Log After, select the number of days, after which logs are to be deleted from the client database.
d. Click Save to save the modi ed settings.
e. View logs:
For applications developed using SAP Mobile Platform SDK 3.0 SP04 or earlier, click a log le name to download the
log and open it in your selected viewer.
For applications developed using SAP Mobile Platform SDK 3.0 SP05 or later, in Management Cockpit, select
Logs Log and Trace . See Viewing Logs and Traces in Administrator.
Related Information
Managing Users
Retrieve user application, device, and connection details for users.
Context
From the list of users, you can search for speci c details, and sort by column. You can also disconnect one or more Agentry user
connections.
Procedure
1. In Management Cockpit, select Registrations and Users Users .
2. Select the lter criteria for each category.
For Application Type, select one or more types (Native, Hybrid, Web, Mobile BI, Agentry) to narrow the scope of application
type. The default is Native.
For Time Frame, select All, or one of the time periods listed (Last Hour, 12 hours, 24 hours, 3 days, or 7 days).
For Number of Entries, select the maximum number of registrations to show. Limiting the number of registrations
5/12/2023
You see information about users that meets the lter criteria.
Field Descriptions
Field Value
User Name Name of the person using the application.
Unique ID Native, Hybrid, Mobile BI, Web apps – the Application

Connection ID.
Agentry apps – the User ID.
Application Application ID.
Device Type The parameter value, such as Android or iPhone, sent by the device
during connection. "Unknown" indicates the device type cannot be
detected.
Last Connection Time The date and time the user application connected to SAP Mobile
Platform Server, in the format MMM DD, YYYY HH:MM:SS AM/PM.
Native, Hybrid (OData), Mobile BI, Web apps – time when
the user rst registered the application with SAP Mobile
Platform.
Agentry apps – last time the user connected to SAP Mobile

Platform.
3. (Optional) To reorder user information, use the column sorting options.
4. (Optional) In Filter By, enter a value to search for a speci c application, user name, unique ID, or device in the retrieved results.
Disconnecting Users
(Applies only to Agentry) Disconnects one or more user connections from the server.
Disconnecting Users
(Applies only to Agentry) Disconnects one or more user connections from the server.
Context
This logs the user out of the server, which is useful when cleaning up an orphaned connection. Once the user is logged out of the server,
the server allows the user to establish a new connection.
 Note
When you disconnect a user, the user is disconnected from all nodes in the cluster.
Procedure
1. In Management Cockpit, select Users on the Home screen to view application and device details for users. Alternatively, select
Applications Users .
2. Select the lter criteria for each category. You see information about users that meets the lter criteria.
3. Select one or more users, and click Disconnect, which is enabled only for Agentry applications.
 Note
The Disconnect button is only enabled for Agentry users.
5/12/2023
Managing Feature Restriction Policies

Manage a list of feature restriction policies that apply to all applications from a central location. Feature examples include camera,
printer, and push. You can add, allow, restrict, edit, or delete features, and apply changes to existing hybrid applications.
Context
From a central location, administrators can manage a list of feature restriction policies for hybrid applications. Each of the centrally
maintained feature restriction policies serves as a template. An updated template is automatically applied to new hybrid applications,
and can be manually applied to existing ones.
 Note
You can override the feature template for individual applications.
Procedure
1. In Management Cockpit, select Settings Feature Restriction Policy Template .
2. View the current status of feature restrictions.
Column Description
Plugin A list of feature plugins that are available with the application, such as Camera, Calendar, and
Push.
ID Unique identi er for the plugin.
Allowed Indicates whether the feature is allowed or restricted.

To allow the feature, select Yes.
To restrict the feature, select No.
3. To add a feature restriction policy, click the Add icon .
In the Add Feature Restriction Policy window, enter restriction policy values, and select Save:
Name A unique feature name.
Plugin A feature plugin that is available with the application, such as Camera, Calendar, and Push.
Plugin Name A plugin that is available with the application, such as Camera, Calendar, and Push.
Description A feature plugin description, such as Cordova Camera Plugin, Cordova Contacts Plugin, and SAP Push Plugin.
JavaScript Module A comma-separated list of the JavaScript modules that this plugin uses. The JavaScript Module value is the
JavaScript API that is used to invoke the plugin, and de ned in the plugin.xml le.
ID Unique identi er for the plugin. The value comes from the cordova_plugins.js le, which appears in the
project after you add a plugin ("pluginId").
Allowed Check to allow the feature.
4. (Optional) To edit a feature restriction policy, click the plugin name.
5. (Optional) To update the feature restriction policies for speci c applications, select Update Apps, select the applications, and click
Apply.
6. (Optional) To change how the list is presented, click the sort icon.
7. (Optional) To delete a feature plugin, select it, and click the Delete icon . You can select multiple rows for deletion.
5/12/2023
Managing Client Database Uploads

Manage client database les that are uploaded from device users. You can download the le for analysis, or drill down to an individual
application to troubleshoot and review uploaded les for a speci c application.
Context
Client database les can be uploaded only by application users for applications for which an upload policy is enabled.
Procedure
1. In Management Cockpit, select Registrations and Users Client Databases .
2. (Optional) Select ltering options to view a subset of application with uploaded client databases, including unique ID, application
ID, device ID, or creator name.
3. At any time, click Refresh, to update the current list of applications with uploaded client databases.
4. To sort results based on application ID, device ID, creator, le size (bytes), and creation time, click , and select the sort by eld.
You can also select ascending or descending.
5. To download the client database le for analysis, click Download and con rm. Identify a program in which to open the le, and
provide a temporary name.
6. When nished, select an application with an uploaded client database, and click Delete and con rm. If you do not delete a
database le manually, it is deleted automatically according to the client database policy.
Importing and Exporting Application Con gurations

The import and export of application con gurations enables you to copy a con guration from one SAP Mobile Platform Server
environment to another. For example, export an application con guration from the testing environment, and import it to the production
environment.
Exporting an Application Con guration

Export the application con guration ZIP le to your local system, retaining many of its settings.
Import the application con guration from one SAP Mobile Platform Server environment to another.
Exporting an Application Con guration

Export the application con guration ZIP le to your local system, retaining many of its settings.
Prerequisites
Ensure the application status is consistent (marked in green) before exporting it to your local system.
Context
You can use the export feature for creating a back-up of the application con guration, and as a prerequisite for importing the application
con guration to another SAP Mobile Platform Server.
In a clustered server environment, the exported application ZIP le is only created on the node to which Management Cockpit is
connected.
The export process only exports the current version of the selected hybrid app. It will not export any versions that are in the "new"
state. If you export an application with no current version, the export process will result in an empty content le. Attempting to
import this le will result in an error message being displayed indicating that the uploaded le did not contain any entries.
5/12/2023
Procedure
2. Select the application, and click Export.
3. Select the relevant con guration to be exported. For all types of application, some con guration settings, such as application
information, security pro le name, and application-speci c con gurations are automatically included:
For native applications, client resource con guration settings are also automatically exported, and you can select to export
Back-end Con guration, Push Con gurations, Client Password Policy, and Offline Con guration.
For Agentry applications, you can also select to export Back-end Con guration les. This option exports Agentry.ini. If
a JavaBE.ini le exists, it is also exported. Note that these les may contain passwords.
For hybrid applications, you can also choose to export Back-end Con guration, Push Con gurations, Client Password
Policy and Offline Con guration.
4. Click Export.
The application con guration le downloads (as <appid_version>.ZIP) to the default (Downloads folder) location, which is
speci ed in the browser.
The downloaded native application con guration ZIP le contains two subfolders: Manifest.MF and Common.
Manifest.MF contains application ID and application version. Common includes an *.smpconfig le, which contains all
the information related to the application in the encrypted form. The Agentry and hybrid ZIP les contain an additional
subfolder with application-speci c settings.
Only security pro le names are exported, and not the complete security pro le.
 Note
If you have a system directory that is shared by all the SAP Mobile Platform servers in your landscape, you can export your
application con guration to the shared directory to make it available to all the other SAP Mobile Platform systems without
having to manually move or send the zip le.

Import the application con guration from one SAP Mobile Platform Server environment to another.
Prerequisites
Before importing the ZIP le, ensure that it is available on the SAP Mobile Platform network.
Context
Many con guration settings are retained, but you must recon gure some application settings for the target server environment.
You can de ne or update an application con guration during import. If the mapped authentication pro le does not exist, the
application is mapped to the “default” authentication pro le. If the back-end con guration or mandatory passwords are missing,
the application is marked as inconsistent, which means it is not ready for use.
Importing an application con guration does not necessarily make it ready for use. Administrators must review the imported
application, and make any necessary adjustments to make it consistent and ready to use.
For hybrid apps that use the AppUpdate plugin, you still need to manage the application version using Applications App Spec
Setting .
For Agentry applications, the imported application overwrites an existing version of the application. You must con gure the
imported application for the target server environment. Currently, Agentry applications do not check for missing passwords or
con guration entries. The application is consistent if the authentication pro le is set.
 Note
5/12/2023
You cannot import ZIP les from a 3.0 SP02 or earlier SAP Mobile Platform Server running on Windows, for use on a Linux
server.
Procedure
2. Click .
3. In Import Con guration, enter a le location. Click Browse, select the application con guration ZIP le, and click Open.
If any manual changes are made to an exported ZIP le, it cannot be successfully imported. A failure message appears
during import.
Importing overwrites any existing application with the same ID.
Passwords, such as for APNS, BES and anonymous user settings, are not available, so the application is marked
inconsistent (excluding Agentry).
Resource bundles, if any, are overwritten.
The URL information, for example, back end or BES URLs, is not overwritten during import.
Upon completion of a successful import, you see a summary message indicating the result for each imported component.
4. Use the information in the summary message to nish con guring the application for the target server environment.
Related Information
Transferring Applications Between System Landscapes

The enhanced Change and Transport System (CTS+) enables you to distribute artifacts, and automate deployment to different target
systems that are connected through transport routes. The SAP Mobile Platform CTS+ system uses SAP NetWeaver.
Con guration
Administrators can use CTS+ to transfer SAP Mobile Platform applications to different system landscapes, for example, from a
development landscape to a testing landscape. To enable transferring applications, con gure the CTS+ components on both SAP Mobile
Platform and SAP NetWeaver.
Prerequisites
SAP NetWeaver version 7.4 or higher.
For SAP NetWeaver 7.4 SP0–SP09, install the latest version of the CTS plugin.
SAP Mobile Platform 3.0 SP10 or higher.
Enable HTTP-based deployment in the CTS+ system by implementing the corrections that are described in SAP Note 2236955 –
CTS+ and HTTP-Based Deployment Offering Requirements .
Review the CTS+ security considerations that are described in Security for the Enhanced Change and Transport System .
Transfer Flow
SAP Mobile Platform Server calls the CTS+ Export Web service to create a CTS+ transport request, and attaches an application le to
the request. The CTS+ server calls the SAP Mobile Platform Server Software Logistics Protocol (SLP) Web service to upload the
5/12/2023
application le and import the application into the target server.
Con gure your CTS+ system by performing these tasks:
1. Creating an SAP NetWeaver Account

In SAP NetWeaver, create an account to use for con guring application transfers.
2. Logging In to the Transport Management System

Log in to the SAP NetWeaver Transport Management System to con gure your CTS+ system.
3. De ning Web Services to Export Applications

De ne a Web service to export applications from the source SAP Mobile Platform Server landscape.
4. De ning Web Services to Transfer Applications

In SAP NetWeaver, de ne the SAP Mobile Platform SLP Web service URL as an HTTPS endpoint so the CTS+ system can connect
to SAP Mobile Platform and transfer applications between landscapes.
5. De ning Application Types to Transfer

De ne the application type that you want to transfer between SAP Mobile Platform landscapes.
6. De ning Source and Target SAP Mobile Platform Systems

De ne source and target SAP Mobile Platform systems, and a deployment method for the target system. Applications are
transferred from the source server to the targer server.
7. Choosing a Transport Strategy

Choose a transport strategy to determine how to create transport requests and when to release them.
8. De ning Transport Routes

De ne a transport route that links the source and target SAP Mobile Platform systems to enable transferring applications
between the two systems.
9. Con guring SAP Mobile Platform CTS+ Properties

Con gure the SAP Mobile Platform CTS+ properties that enable transferring applications.
5/12/2023
10. Exporting Applications to Transport Requests
To move an application from one SAP Mobile Platform landscape to another, export the application con guration to a CTS+
transport request.
11. Importing Applications into Target Servers

After you export an SAP Mobile Platform application using a CTS+ transport request, you can import the application into the
target server.
Creating an SAP NetWeaver Account

In SAP NetWeaver, create an account to use for con guring application transfers.
Procedure
1. Open SAP Logon.
2. In the right pane, right-click, and select Add New Entry.
3. In the dialog that opens, select Custom Application Server as the Connection Type, and enter values for the system connection
parameters:
Description
Application Server – address of your CTS+ server.
Instance Number – instance number of your system.
System ID – an ID for your system.
4. Click Finish.
Task overview: Transferring Applications Between System Landscapes
Next task: Logging In to the Transport Management System
Logging In to the Transport Management System

Log in to the SAP NetWeaver Transport Management System to con gure your CTS+ system.
Prerequisites
Create an SAP NetWeaver account.
Procedure
1. Open SAP Logon.
2. Right-click the CTS+ system, and select Log On.
3. Enter logon values, then click Enter:
User
Password
Logon Language – abbreviation, for example, EN.
4. To the right of the check mark , enter /nSTMS, and click Enter.
Previous task: Creating an SAP NetWeaver Account
5/12/2023
Next task: De ning Web Services to Export Applications
De ning Web Services to Export Applications

De ne a Web service to export applications from the source SAP Mobile Platform Server landscape.
Context
You can con gure and activate a CTS+ export Web service using the SAP NetWeaver Service-Oriented Architecture-based (SOA)
Management tool. For information about SOA management, see:
Con guring a Service Provider
SOA Made Easy With SAP
Procedure
1. Log in to the CTS+ System client that you de ned in the development system.
2. Run the SOAMANAGER transaction.
After authentication, the SOA Management tool opens in a Web browser.
3. Select Service Administration, and then select Web Service Con guration.
4. As the Object Name, enter EXPORT_CTS_WS, and click Search.
5. Under Search Results, click EXPORT_CTS_WS, select Overview, and record the value of External Namespace (for example,
urn:sap-com:document:sap:soap:functions:mc-style).
6. Select the Con guration tab. Existing EXPORT_CTS_WS type Web services and their bindings appear.
7. To use an existing Web service, skip to step 8. To create a new Web service:
a. Click Create Service.
b. In the Web Service Con guration window, enter values for:
Service Name
Service Description Text
New Binding Name
c. Under Con guration of Web Service, select Provider Security, and set these property values:
Communication Security – None (HTTP)
Transport Channel Authentication – User ID/Password
Collected Authentication Methods – sapsp: HTTPBasic
d. Under Operation Settings, click Finish.
8. In the De ne services and bindings table, nd the service you want to use, and click its Open Service WSDL Generation icon .
9. Record the values of Service Name and WSDL URL for Binding.
 Tip
You will need these values and the value of External Namespace (step 5) for later con guration.
Next Steps
If you have trouble running the EXPORT_CTS_WS Web service, see the error log:
1. Log in to the client system that hosts the Web service.

5/12/2023
2. Run the SLG1 transaction and search the log for the CTSPLUS object.
Previous task: Logging In to the Transport Management System
Next task: De ning Web Services to Transfer Applications
Related Information
Con guring SAP Mobile Platform CTS+ Properties
De ning Web Services to Transfer Applications

In SAP NetWeaver, de ne the SAP Mobile Platform SLP Web service URL as an HTTPS endpoint so the CTS+ system can connect to SAP
Mobile Platform and transfer applications between landscapes.
Prerequisites
Create an SAP NetWeaver CTS+ account to use for con guring application transfers.
Context
In SAP NetWeaver, de ne the SAP Mobile Platform SLP Web service URL as an HTTPS endpoint: https://<host>:
<port>/Admin/CTS/slp, where <host> is the target SAP Mobile Platform Server host and <port> is the admin port number.
Procedure
1. Log in to your SAP NetWeaver CTS+ account.
2. To the right of the check mark , enter /nSM59, and click Enter.
3. Select HTTP Connections to External Server, and click the Create icon .
4. Enter:
RFC Destination – SLP Web service destination.
Description – description for the Web service connection.
5. Select Technical Settings, and enter:
Target Host – host name of the target SAP Mobile Platform Server.
Service No. – SAP Mobile Platform Server admin port number; the default is 8083.
Path Pre x – /Admin/CTS/slp, which is the path to the SLP Web service root directory.
6. Select Logon & Security, and enter:
Basic Authentication – select.
User – SAP Mobile Platform admin user name; the default is smpAdmin.
Password – password of the admin user.
SSL – select Active.
SSL Certi cate – select ANONYM SSL Client (Anonymous).
7. (Optional) To improve logging, select the Special Options tab, and either increase the timeout value or select No Timeout.
If the SLP process takes longer than the timeout value, logging details may be lost.
5/12/2023
8. Click the Save icon.
9. To verify that SAP Mobile Platform Server can access the SLP Web service, click Connection Test.
The test calls the SLP root using GET https://<host>:<port>/Admin/CTS/slp with no authentication, so Logon &
Security property values are not veri ed.
Previous task: De ning Web Services to Export Applications
Next task: De ning Application Types to Transfer
De ning Application Types to Transfer

De ne the application type that you want to transfer between SAP Mobile Platform landscapes.
Procedure
1. Log in to the Transport Management System.
2. Click the System Overview icon .
3. Select Extras Application Types Con gure .
4. Click New Entries, and in the new dialog, enter the following values:
Application ID – SMP.
Description – SMP content in CTS+.
Support Details – If you need support, access http://service.sap.com, and select SAP Support
Portal > Report an Incident. Enter "CTS+" in the search box, and click the Search icon.
Search the list for a similar issue, or click Contact SAP Support.
5. Click the Save icon, and click Yes to con rm.
Previous task: De ning Web Services to Transfer Applications
Next task: De ning Source and Target SAP Mobile Platform Systems
Related Information
De ning Source and Target SAP Mobile Platform Systems

De ne source and target SAP Mobile Platform systems, and a deployment method for the target system. Applications are transferred
from the source server to the targer server.
Procedure
2. Click the System Overview icon .
3. De ne the target system:
a. Select SAP System Create Non-ABAP System .

5/12/2023
b. In the new dialog, enter:
System – a name for the target SAP Mobile Platform system.
Description – a description of the system.
Target System Settings – select Activate Deployment Service.
Methods – select Other, and unselect all other methods.
c. Click the Save icon.
d. Click New Entries, and in the new dialog, enter:
Application ID – the ID of the application type you created.
Deploy Method – select HTTP-Based Deployment (Application-Speci c).
HTTP Destination – the SLP Web service destination; value of RFC destination that you de ned in "De ning the
Web Service to Transfer Applications."
e. Click the Save icon, and click Yes to con rm.
Con guration of the target system is complete.
4. Return to the System Overview page by clicking the Back icon twice.
5. (Optional) To view or edit the deployment method, double-click the target system, then select Goto Application Types
Deployment Method .
6. De ne the source system:
a. On the System Overview page, select SAP System Create Non-ABAP System .
b. In the new dialog, enter:
System – a name for the source SAP Mobile Platform system.
Description – a description of the system.
Source System Settings – select Activate Transport Organizer.
c. Click the Save icon.
Con guration of the source system is complete.
Next Steps
Choose a transport strategy to de ne how transport requests are created and released.
Previous task: De ning Application Types to Transfer
Next task: Choosing a Transport Strategy
Related Information
Choosing a Transport Strategy

Choose a transport strategy to determine how to create transport requests and when to release them.
Prerequisites
5/12/2023
De ne both the source and the target SAP Mobile Platform Server systems.
Procedure
1. See Choosing a Transport Strategy for Source Systems.
2. In the system list, double-click the system BD1 that you just created.
3. Select Transport Tool, and switch to Edit mode.
4. Verify that the list of parameters includes both WBO_GET_REQ_STRATEGY and WBO_REL_REQ_STRATEGY; if it does not:
a. Select a row, and click Insert Row.
b. Choose the input help (F4-help).
c. Select the parameter to add, and enter a value, which must begin with a capital letter:
Parameter Valid Values
WBO_GET_REQ_STRATEGY Create, Smart, or Tagged
WBO_REL_REQ_STRATEGY Manual or Automatic
The document cited in step 1 describes how each value affects system behavior.
Previous task: De ning Source and Target SAP Mobile Platform Systems
Next task: De ning Transport Routes
De ning Transport Routes

De ne a transport route that links the source and target SAP Mobile Platform systems to enable transferring applications between the
two systems.
Context
SAP recommends that you de ne client-independent transport routes. See Con guring Transport Routes.
Procedure
2. Click the Transport Routes icon .
3. Set the editor to Change mode by clicking the Display <> Change icon .
4. To create a transport layer, select Edit Transport Layer Create .
5. In the Create Transport Layer dialog, enter values for these properties, then click the check mark:
Transport Layer – a name for the transport layer.
Short Description
6. Put the source and destination systems you created into the routes panel, and click the Add Transport Route icon .
The cursor changes to a pen.
7. Using the pen, draw a line between your two systems.
8. Select the Transport Layer that you created, click the check mark, and click Yes to con rm.
5/12/2023
Previous task: Choosing a Transport Strategy
Next task: Con guring SAP Mobile Platform CTS+ Properties
Related Information

Con gure the SAP Mobile Platform CTS+ properties that enable transferring applications.
Procedure
1. In Management Cockpit select Settings System .
2. Under Enhanced Change and Transport System Settings, enter property values for your system:
CTS+ Export Web None Web Service De nition Language (WSDL) URL of the Web service that
Service WSDL URL exports transport requests. See De ning the Web Service to Export
Applications.
Target Namespace urn:sap- URI that points to XML schemas for the Web service. See De ning the Web
in the WSDL com:document:sap:soap:functions:mc- Service to Export Applications.
style
Service Name in the None Name of the Web service that exports transport requests. See De ning the
WSDL Web Service to Export Applications.
User Name None Name of user on CTS system.
Password None Password for the user.
Application Type None Application type you de ned in the Transport Management System. See
De ning Application Types to Transfer.
System ID None ID of the source system you created in the Transport Management System.
See De ning Source and Target SAP Mobile Platform Systems.
3. Click Save.
Previous task: De ning Transport Routes
Next task: Exporting Applications to Transport Requests
Related Information
De ning Source and Target SAP Mobile Platform Systems
De ning Application Types to Transfer
De ning Web Services to Export Applications
Exporting Applications to Transport Requests

5/12/2023
To move an application from one SAP Mobile Platform landscape to another, export the application con guration to a CTS+ transport
request.
Prerequisites
Con gure CTS+ properties for your source system.
Procedure
1. In Management Cockpit, select Settings Enhanced Change and Transport System .
2. Under Export Application Con guration to Transport Request, select an application, and click Export.
3. In the new dialog, select the options to include in the transport request, and click Export.
4. In the dialog that opens, click the Transport Organizer link.
5. Log in to SAP NetWeaver using your CTS+ system credentials.
6. If the value of CTS_REL_REQ_STRATEGY on the ABAP/CTS+ source system is true, select the transport request, and click Release.
If an error occurs on the SAP Mobile Platform side, a message box opens to report the error. You can also check the server log for
more details.
Previous task: Con guring SAP Mobile Platform CTS+ Properties
Next task: Importing Applications into Target Servers
Importing Applications into Target Servers

After you export an SAP Mobile Platform application using a CTS+ transport request, you can import the application into the target
server.
Prerequisites
See Importing Transport Requests with Non-ABAP Objects.
Procedure
2. Click the Import icon .
3. Double-click your target system. If your system does not appear, click the Refresh icon .
4. On the Import Queue page, click the Refresh icon.
5. Select the request to import, and click the Import Request icon .
6. In the dialog that opens, select Immediate, and click .
7. Click Yes to con rm.
Results
The system returns one of four codes, and you see its corresponding icon. Double-click the icon to learn more about the results.
Icon Return Code Description
0 The import was successful.
5/12/2023
Icon Return Code Description
4 The import was successful, but some warnings exist.
8 The import failed because of errors in the content. Export the application again.
12 The import failed because of issues with the tool. After the issue is xed, import again.
To view the deployment log, click the icon to the left of Deployment.
Previous task: Exporting Applications to Transport Requests
Related Information
Managing Security Pro les

Manage multiple security pro les for native, hybrid, Web, Agentry, and Mobile BI applications from a single location.
Context
You can de ne new security pro les, and edit or delete existing ones. Security pro les include con guration properties, and one or more
authentication providers.
Procedure
1. In Management Cockpit, select Con gure Security Pro le on the Home screen to view application connections. Alternately, select
Settings Security Pro le . Information for all security pro les appears (up to 200 rows)
There are three default security pro les, which you cannot delete:
Security
Pro le Description
Admin The Admin security pro le authenticates and authorizes administrative users.
Default The Default security pro le authenticates access to SAP Mobile Platform Server if a client application does not explicitly
specify one. This pro le is also used by any container managed authentication if a Web application is deployed to SAP Mobile
Platform Server.
Noti cation The Noti cation security pro le enables push noti cations for the Noti cation User role.
2. (Optional) To view more details about a speci c security pro le, select its URL.

Create and con gure security pro les to control how the server authenticates users during onboarding, and to manage request-
response interactions with the back end.
Editing a Security Pro le
Change the settings for an existing application security pro le.
Deleting a Security Pro le
Delete an existing application security pro le.
Related Information
5/12/2023
Con guring Security Pro les and Authentication Providers

Create and con gure security pro les to control how the server authenticates users during onboarding, and to manage request-
response interactions with the back end.
Context
For Agentry applications, which have an additional authentication layer that is con gured elsewhere, a common scenario is to
con gure No Authentication Challenge as the security provider, so that only Agentry performs authentication.
You can stack multiple security providers to combine security features in complex systems; place the providers in the order that
takes advantage of the features you chose. Set the Control Flag for each enabled security provider in the stack.
You must map logical roles to physical roles, as required by the application.
When you create a new security pro le, a corresponding XML le is created in the
<SMP_HOME>\configuration\com.sap.mobile.platform.server.security\CSI\ directory. When a security pro le is
updated, a copy of the XML le is saved, which allows you to recover the previous version.
For an example of how to con gure a security pro le with an X.509 User Certi cate authentication provider, see Creating a
Security Pro le with X.509 Authentication.
Procedure
1. In Management Cockpit, select Settings Security Pro les .
2. Click the Create icon .
3. Enter the following:
Field Value
Security A unique name for the security pro le.

Pro le Name
Check (Optional) In token-based authentication, whether to allow authentication to succeed when the user name presented cannot
Impersonation be matched against any of the user names validated in the login modules. By default, the property is enabled, which
prevents user authentication in this scenario.
4. Under List of De ned Authentication Providers, set up one or more providers for the application.
a. Click .
b. Select an authentication provider from the list.
Authentication Provider Description
No Authentication Challenge Always authenticates the supplied user. The provider offers pass-through security for
SAP Mobile Platform Server, and should typically be reserved for development or testing.
SAP strongly encourages you to avoid using this provider in production environments—
either for administration or device user authentication.
System Login (Admin Only) Con gured by the installer with the initial administrator credentials to give platform
administrators access to Management Cockpit, so they can con gure SAP Mobile
Platform Server for production use. Administrators should replace this authentication
provider immediately after logging in the rst time. SAP encourages you to avoid using
this provider after the production environment is con gured.
5/12/2023
Populate JAAS Subject From Client Enables administrators to add client values as named credentials, name principals, and
role principals to the authenticated subject. This provider copies values from the client's
HTTP request into the JAAS subject as:
Principals – identi es the user.
Roles – grants access rights to resources that are protected by SAP Mobile
Platform.
Credentials – provides single sign-on material to use when connecting to back-

end systems. Adding client values as named credentials allows them to be used
for single sign-on.
X.509 User Certi cate For users who are authenticated by certi cates. You can use this provider with other
authentication providers that support certi cate authentication, for example, Directory
Service (LDAP/AD), by con guring X.509 User Certi cate before the authentication
providers that support certi cate authentication. You can use this provider to validate
client certi cates only when HTTPS listeners are con gured to use mutual authentication.
You can con gure optional advanced properties, such as key-value pairs, for this provider
by selecting Advanced in Management Cockpit.
 Note
Agentry clients on iOS and Android do not support client/user certi cates. Agentry
clients on Windows and Windows CE support client-side certi cates, but Agentry
cannot use these certi cates for user identi cation; Agentry requires separate user
name and password authentication as well.
SAML2 Provider that authenticates a user through a trusted identity provider.

Use only a single SAML2 instance, by itself or in combination with other authentication
providers, when you de ne a security pro le.
Mobiliser Login (Basic Authentication) Authenticates users with basic authentication by passing their credentials to the
Mobiliser system.
OAuth Login (via Introspection Endpoint) The OAuth Authentication Provider can authenticate a user by using a provided OAuth
token. The token is forwarded to an OAuth Introspection Endpoint according to RC7662.
The Introspection Endpoint performs the veri cation of the token and authenticates the
user. Upon successful authentication, the token is remembered in the session and can be
forwarded to back-end systems to support single sign-on scenarios.
Principal Propagation Provides clients with single sign-on access to back-end systems; does not authenticate a
client that is opening a session with SAP Mobile Platform Server.
To use the Principal Propagation provider:
Assign X.509 as the SSO mechanism for application back-end connections.
Specify one or more authentication providers in the security pro le stack. Do not
use X.509 User Certi cate as one of the authentication providers.
HTTP/HTTPS Authentication Authenticates a user with given credentials (user name and password, or SSO tokens
from your SSO system) against a back end that is integrated into your management or
SSO systems. Optionally, this provider may retrieve a cookie that represents additional
SSO credentials to use for back-end systems that are also integrated with your SSO
system.
You can con gure optional, advanced properties, such as Username HTTP Header, and
Token Expiration Interval, by selecting Advanced in Management Cockpit.
5/12/2023
Kerberos Provider that has no part in authenticating the user based on credentials provided, but
once another provider has authenticated the user, this module can provide Kerberos SSO
credentials for that user to back-end systems.
You cannot use Kerberos by itself when you de ne a security pro le.
Kerberos does not authenticate a client that is opening a session with SAP Mobile
Platform Server.
You must specify one or more other authentication providers in the security
pro le stack.
Kerberos can authenticate only between SAP Mobile Platform Server and a back
end that is con gured for Kerberos support, by passing on an authentication
provided by an authentication provider speci ed in the security pro le stack.
Directory Service (LDAP/AD) Integrates with your Active Directory or other Directory Server identity management
system using LDAP. The provider rst connects to your Directory Server using a technical
user identity so it can perform an LDAP search to discover the fully quali ed
distinguished name (DN) of the current user in the directory. It then binds the DN to the
provided password. When the bind succeeds, the user is considered authenticated. The
provider then performs an LDAP search to see which groups the user is a member of.
These group names are considered physical roles in the role mapping de nitions that are
used later for access controls.
This provider is particularly useful in the Admin security pro le to allow existing
enterprise users to use Management Cockpit, and also any custom security pro les used
for authenticating enterprise users for SAP Mobile Platform application usage.
You can con gure optional advanced properties, such as Certi cate Authentication Filter
and Certi cate Attributes, for this provider by selecting Advanced in Management
Cockpit.
SAPSSO2 Generator Internal method of generating a token for SSO access to back-end systems.
To use SAPSSO2 Generator, specify one or more authentication providers in the security
pro le stack.
c. Enter values based on the selected authentication provider.
d. (Optional) To validate your settings, click Test Settings.
e. Click Save.
f. (Optional) Click New to add additional security providers on the stack. Use the up and down arrows to move the security
providers into the correct order.
5. Map SAP Mobile Platform logical roles to prede ned physical roles—see Mapping Logical Roles to Physical Roles.
6. (Optional) If the server is running in a cluster, click Refresh to update the UI with changes made in other server nodes.
7. Click Save, and con rm.
Related Information
Creating a Security Pro le with X.509 Authentication
Editing a Security Pro le

Change the settings for an existing application security pro le.
Procedure
1. Select the Settings tab, and select Security Pro les.
2. Under Security Pro les, click an existing pro le.

5/12/2023
3. Modify the settings as needed.
4. Click Save.
Deleting a Security Pro le

Delete an existing application security pro le.
Procedure
1. Select the Settings tab, and select Security Pro les.
2. Select a security pro le.
3. Click Delete, and con rm. The pro le is removed from the list, and any application using it.
Managing Connections
Manage multiple back-end connections for native, hybrid, Web, and mobile Business Intelligence (BI) applications from a single location.
You can de ne, edit, and delete back-end connections; test a connection using Ping, and lter connections based on the connection name.
Procedure
1. In Management Cockpit, select Connections.
2. To search for a speci c connection, enter a name in the search eld.
3. To see an overview of connection properties, select the connection.
4. To edit connection properties, select a connection, click Edit, and update property values as required. See De ning a Back-End
Connection.
 Note
To prevent momentary inconsistencies, SAP recommends that you modify back-end connection con gurations when few users
are active. After you save the changes, users should be able to use connections without inconsistencies.
5. To ping a connection, select it, and click the Ping icon .
6. To delete a connection, select it, and click the Delete icon .

De ne a new back-end connection to a data source or service for a native, hybrid, or Web application.
Editing Back-End Connections
Modify settings for existing back-end connections.
Deleting Back-End Connections
If you delete a back-end connection, it is removed from any application that is con gured to use it.

De ne a new back-end connection to a data source or service for a native, hybrid, or Web application.
Procedure
1. In Management Cockpit, select Settings Connections .
5/12/2023
2. To create a new connection, click the plus sign , and in the Create Connection dialog, enter:
Field Value
Back-End The URL the application uses to access business data on the back-end system or service. This can be a back-end
URL connection, or a service document, usually in the following format:
http://<host>:<port>/gateway/odata/<namespace>/<Connection_or_ServiceName>.../
For a service, the service document URL is the document destination you assigned to the service in SAP Gateway. Include a
trailing forward slash to avoid triggering a redirection of the URL, and losing important HTTP header details. This is
especially important when con guring the application with security such as SSOToken and Certi cates, and when Rewrite
URL in SMP or Rewrite URL in Backend System is selected as the rewrite mode.
 Note
If you select to rewrite the URL, it cannot include a reserved pattern. See URL Rewrite Modes.
Internal White list a service that you create in SAP Mobile Platform. If you de ne an endpoint as internal, the host name and port of
the back-end URL are ignored, and incoming requests are forwarded to internal services in-process, without another HTTP
call to localhost. An example of an internal service is Integration Gateway.
Allow (Optional) If enabled, the user can access the application without entering a user name and password. However, back-end
Anonymous systems still require login credentials for data access, whether it is a read-only user, or a back-end user who is assigned
Access speci c roles.
If enabled and the back end requires it, enter the login credentials to access the back-end system:
User name – the user name for the back-end system.
Password – (required if you enter a user name) the password for the back-end system.
If disabled (the default) or the back end does not require it, you need not provide these credentials.
 Note
If you allow anonymous access for a native OData application, do not assign the No Authentication Challenge security
pro le to the application; anonymous OData requests are not sent, and status code 401 is returned.
Maximum (Optional) The number of back-end connections that are available for connection pooling for this application. The larger the
Connections pool, the larger the number of possible parallel connections to this speci c connection. For primary endpoints, the default
and minimum is 500 connections. Consider the following factors when resetting this property:
The expected number of concurrent users of the application.
The load that is acceptable to the back-end system.
The load that the underlying hardware and network can handle.
Increase the maximum number of connections only if SAP Mobile Platform Server hardware can support the additional
parallel connections, and if the underlying hardware and network infrastructure can handle it.
To disable connection pooling, set this value to 0. Disable connection pooling only if the back-end system does not support
pooled connections, as disabling connection pooling may have a negative impact on processing times.
Timeout in The number of milliseconds before the back-end connection times out. If set to 0, the JVM timeout value is used.
Milliseconds
Online The threshold value to throttle incoming online requests per second for a connection. Leave blank (default) or set to 0 to
Request remove threshold. Set a threshold value from 1 ‒ 2147483647.
Threshold
Certi cate Optional if the Endpoint URL begins with HTTPS.

Alias If the back-end system has a mutual SSL authentication requirement, select the certi cate alias name of the private key and
technical-user certi cate that can access the back-end system. The certi cates are located in the shared keystore
smp_keystore.
5/12/2023
Field Value
Rewrite Select one of:

Mode Rewrite URL on SMP – in request and response messages, the server replaces all back-end URLs with the server
URL.
Rewrite URL on Back End – the back end rewrites the URLs. The server forwards its host name and port to the back
end in an HTTP header, and the back end creates the URL to retrieve back-end entities.
Select Via HCP App to use the x-forwarded-for header value; or leave it unselected to use the default Host
header.
No Rewriting – request and response messages are not modi ed; the server passes messages directly between
clients and back-end systems.
 Note
SAP Mobile Platform Server does not provide the functionality to use No Rewriting mode to support external back
ends for offline usage.
See URL Rewrite Modes.
Relative (Only if Rewrite Mode is Rewrite URL on SMP) If an application requires data from a back end that uses relative URLs,
Path con gure those relative URL patterns here.
The server rewrites relative URLs to include the connection ID (connection name), enabling access to the back-end data. For
example, a Web service application requests an HTML page named abc.html, which contains the relative URLs /sap/bc
and /sap/public/bc in its src or href tags. When a request is made, the server rewrites the relative URLs in the
response, so that subsequent requests to these relative URLs are processed correctly.
For example, if "webApp" is the connection name and the response contains the relative URLs /sap/bc and
/sap/public/bc, the server rewrites these relative URLS to /webApp/sap/bc and /webApp/sap/public/bc.
Without the relative URLs, the request cannot be processed.
To add relative paths, enter a comma-delimited list of relative URLs, for example, /sap/bc,/sap/public/bc.
SSO (Optional) You can add one or more SSO mechanisms, and prioritize them. The runtime calls the rst SSO mechanism for
Mechanisms which corresponding user credentials are available. Only one SSO mechanism is used per connection attempt. If a
connection fails, the server invalidates the client session and requires reauthentication.
Click the Create icon , select an SSO Mechanism, and click Save.
To change the order in which an SSO mechanism is used, select it, and click or .
See Single Sign-On Mechanisms.
3. Click Save.
Related Information
URL Rewrite Modes
OAuth Login (via Introspection Endpoint)
Editing Back-End Connections

Modify settings for existing back-end connections.
Context
 Note
To prevent momentary inconsistencies, SAP recommends that you modify back-end connection con gurations when few users are
active. Users can use a connection without inconsistencies as soon as you save the changes.
5/12/2023
Procedure
1. In Management Cockpit, select Settings Connections , and select the application connection to edit.
2. Select a connection.
3. In the General Information window, edit the connection details as required.
4. Click Save.
Deleting Back-End Connections

If you delete a back-end connection, it is removed from any application that is con gured to use it.
Procedure
1. In Management Cockpit, select Settings Connections , and select the back-end connection to delete.
2. Click Delete, and Yes to con rm.

Procedure
1. In Management Cockpit, select Applications
2. Identify an application, and select Ping .
These values appear:
Connection Name
Back-End URL
Ping Result
3. Click OK.
Viewing Server Usage Reports

View usage statistics for the SAP Mobile Platform Server. Usage reports appear in graphical form and provide a summary of application
registrations, number of users and requests, and response times.
Prerequisites
Enable applications to collect usage information; to get registration information, there must be registered users.
Context
Server log data is updated periodically, based on the last refresh.
Procedure
1. In Management Cockpit, select Reporting Server Data Report .
2. Select the appropriate Usage option to lter the usage reports:
5/12/2023
Registrations (by Time) – view the number of active registrations during a time period.
Registrations (by Device Type) – view the registered device types, for example, Android, BlackBerry, and iOS.
Users (by Application) – view the number of active users per application.
Requests – view the number of requests made during a time period. Does not include offline requests.
Response Time – view the response time, in milliseconds, per time period. Response time is reported for SAP Mobile
Platform Server, authentication, and the back end. Does not include offline response times.
Offline Requests – view the number of offline requests made during a time period. Requests are reported only for offline
OData applications. Operations requests include:
Initial Download ‒ complete the initial build of the database le on the server, and download the offline data store.
Refresh ‒ complete refresh of the offline data store from the server. May be full or delta-only.
Flush ‒ complete ush of local changes from the offline data store to the server. Delta-only.
Offline Response Time – view the average response time for offline requests per time period. Response time is reported
only for offline OData applications.
Threshold Hit Count for Application – view the number of times that incoming requests hit the threshold that is set for the
application. Incoming requests include registration, online, and offline requests.
Threshold Hit Count for Connection – view the number of times that incoming requests hit the threshold that is set for the
connection. Incoming requests includes online requests.
Outbound Traffic (by Application) – view the outbound HTTP traffic statistics for one or more applications.
Outbound Traffic (by Connection) – view the outbound HTTP traffic statistics for the selected connection.
3. Select the Time Frame to gather and display the statistics report: Today, Yesterday, Last 7 Days, Last 4 Weeks, Last 3 Months, or
Last 12 Months.
4. To change the format in which the data appears, select the appropriate icon in the top-right corner of the page. You can expand
the page, and you can toggle between displaying and hiding the legend.
For offline request and response time statistics, you can use the legend to drill down and view more information about the
selected statistics, including time period, category, number of milliseconds, and number of values represented.
For threshold hit counts, you can use the legend to drill down and view more information about the selected statistics. You can
also view the report data in a table format. Keep in mind:
If you select multiple applications, the value re ects a sum value.
If you select a single application or connection, the value re ects only the selected application or connection.
If the threshold hit count chart shows no data, it indicates that the server is in a good state. The actual request count is
lower than the threshold value.
If the charts show a lot of data, the server load may be too high, or the threshold value may be set too low. You may want to
adjust the thresholds to better control incoming traffic requests.
For outbound traffic statistics, you can use the legend to drill down and view more information about the selected statistics. You
can also view the report data in a table format. These values are for statistical comparison only, and are not comparable to values
used for billing.
Application Usage Statistics

View usage statistics for a single native, hybrid, Web, or Mobile BI application.
Prerequisites
For registration information to appear, an application must have registered users, for registration information to appear.
5/12/2023
Context
The usage information is shown graphically, providing a summary of registrations and requests for the application, and the response time
for these categories: SAP Mobile Platform, authentication, and the back-end connection. This information is visible only after the
application has been de ned.
Procedure
2. Select an existing application, then select Overview. Only de ned applications show an Overview tab.
3. Under Application Usage, select one of the following tabs:
Registrations to view active application registrations.
Select the registration time period, including Today, Yesterday, Last 7 Days, Last 4 Weeks, Last 3 Months, and Last
Year.
Select Over time to view the number of application registrations during the selected time frame. You can choose
the Line Graph or Bar Graph icons in the left corner to vary the graphical presentation.
Select By device type to view the number of application registrations by device type for the time frame selected.
You can choose the Bar Graph or Pie Chart icon in the left corner to vary the graphical presentation.
Requests to view active requests for the application. You can select the registration time period, including Today, Yesterday,
Last 7 Days, Last 4 Weeks, Last 3 Months, and Last Year. You can chooseLine Graph or Bar Graph icons in the left corner to
see a graphical summary.
Response Time to view the response time, in milliseconds, per day. Response time is reported for SAP Mobile Platform,
authentication, and the back end. You can select the registration time period, including Today, Yesterday, Last 7 Days, Last
4 Weeks, Last 3 Months, and Last Year.
4. Under Recent Registrations, view registration details for the selected application.
Viewing Push Statistics

View push noti cation statistics for push enabled apps from Push Statistics. You can see noti cation details, noti cations by applications,
and noti cations by operating system.
Procedure
1. In Management Cockpit, select Reporting Push Statistics .
2. Select the appropriate Usage option to lter the push noti cation report:
Noti cations in Detail – view push noti cation counts by time period, application, and operating system. Count categories
include noti cations sent, received, resulting in error, and consumed successfully.
Noti cations (by Application) – view push noti cation counts by time period and application. Count categories include
noti cations sent, received, resulting in error, and consumed successfully.
Noti cations (by OS) – view push noti cation counts by time period and operating system. Count categories include
noti cations sent, received, resulting in error, and consumed successfully.
3. Select the Time Frame to gather and display the statistics report. The time frame selected determines how the time format
appears:
Today (default) and Yesterday – the time format is <hh - hh>. Twenty four hours is divided into six parts for comparison: 00
- 04; 04 - 08; 08 -12; 12 - 16; 16 - 20; and 20 - 24.
Last 7 Days – the time format is <yyyy/MM/dd>; for example, 2016/11/30.
Last 4 Weeks – the time format is <yyyy/Www>, where <Www> is the week of the year; for example, W22 is week 22 in the
year.
Last 3 Months and Last 12 Months – the time format is <yyyy/MM>; for example, 2016/12
5/12/2023
4. To change the format in which the data appears, select the appropriate icon in the top-right corner of the page. You can view the
report in table format, expand the page, and download the report in .CSV format. You can toggle between displaying and hiding
the legend, and click Reset to reset the lters. When the legend appears, you can use it to drill down and view more information
about the selected statistics.
Viewing and Purging Client Usage Reports

View aggregated usage statistics for native, hybrid, and Web applications. Usage reports are summaries of user sessions, which you can
lter by application, device type, operating system, or session duration. You can download reports to CSV les and import them into tools
such as SAP Lumira or Excel and you can purge them when no longer required.
Prerequisites
Applications for which you are collecting statistics must be enabled to collect usage information.
Context
Usage statistics are aggregated in real time, and you can view them for a subset of applications, which can be a powerful research and
monitoring tool.
 Note
Purging Client Usage Reports
You can purge client usage data by using SQL to connect directly to the database. To purge client usage data, modify one of the
following examples to conform to the SQL syntax for the target database.
Delete client usage statistics by application and timestamp:
Delete from SMP_CLIENTUSAGE_FACT where APPLICATIONDIMID in (select ID from SMP_CLIENTUSAGE_APPLICATION

where APPLICATIONID= {application name}) and RECORDTIMESTAMP <= {timestamp}
Delete client usage statistics by user and timestamp:
Delete from SMP_CLIENTUSAGE_FACT where REGISTRATIONID in (select APPLICATIONCONNECTIONID from

SMP_APPLN_CONNECTON_INFO where USERNAME = {user name}) and RECORDTIMESTAMP <= {timestamp}
Procedure
1. In Management Cockpit, select Reporting Client Data Report .
2. To lter client statistics, select the appropriate Usage and Time Frame options:
User Sessions per Application, Time Period – view the number of user sessions for each application during a time period.
User Sessions by OS, Version, and Device Model – view user sessions based on the operating system, version, and device
model.
OS Share of User Sessions – view the number of user sessions shared between operating systems over a period of one
month.
OS, OS Version Share of User Sessions – view the number of user sessions based on the operating systems and their
versions over a period of one month.
User Session Length (in milliseconds) – view user sessions based on the session durations.
3. To further re ne your search, select Application ID, Application Version, OS, OS Version, or Device Model, and choose the
appropriate options.
5/12/2023
4. To change the data-presentation format, click the Table View icon .
5. To download a client usage report to a CSV le, click the Download icon .
Managing Application Logs and Traces

Set the verbosity for application and component logging, and the purge schedule for log and trace les. View all application logs or the
subset of your choosing, and drill down to view detailed log and trace information if available.
Setting Log Levels

You can change the logging level for one or more logging components. For Agentry, you change the logging level at the application
level. In a troubleshooting situation, you may want to increase the log level to capture more details.
Enable application traces for selected SAP Mobile Platform Server logging components.
View log and trace information to troubleshoot application problems. Use search criteria to nd the log records and trace
statements needed to diagnose a problem. Depending on what information is being captured, log and trace information can
include entries from client logs, server logs, and application traces. For applications developed using SAP Mobile Platform SDK 3.0
SP04 or earlier, you cannot view client logs in the Logs and Traces View but can instead download and view a client log le in the
Registrations view.
Tracing Network Activity
Application users can trace network activity based on user name, connection, application, or content type. You can download
tracing reports to either a .zip or a .har le.
Analyze end-to-end (E2E) tracing to troubleshoot client issues. E2E tracing sessions are conducted by administrators and device
users. E2E trace information is recorded in a Business Transaction XML (BTX) le on the client, which is uploaded to the server,
and then uploaded to SAP Solution Manager for analysis.
Purging Logs and Traces
Con gure a scheduled purge of logs and traces stored in the SAP Mobile Platform Server database, or purge log and trace les
immediately.
Audit Trail Logging
Setting Log Levels

You can change the logging level for one or more logging components. For Agentry, you change the logging level at the application level.
In a troubleshooting situation, you may want to increase the log level to capture more details.
Context
 Note
You must deploy one or more Agentry applications to be able to set Agentry log levels.
Logging detailed information consumes more system resources, so SAP recommends that you change the log level only when you
suspect a serious problem, or are testing a theory. In most situations, logging errors and warnings is sufficient.
 Note
Logs that are generated during an end-to-end tracing request cycle use the trace level set for end-to-end tracing, overriding the
logging level set here.
Procedure
1. In Management Cockpit, select Logs Log Settings .
2. For each component, select a log level.

5/12/2023
System Logging Components
Component Description
Admin Logs system messages related to SAP Mobile Platform administration.
Agentry Logs system message related to Agentry applications.
Agentry user.* Logs system messages related to Agentry application users.
Agentry <app_ID> Logs system messages related to the Agentry application.
Agentry <app_ID>.BackEnd.* Logs system messages related to the back-end data source connections, such as SQL or Java, for
the Agentry application.
Agentry Logs system messages related to the back-end data source push service for the Agentry
<app_ID>.ThirdPartyPushServices application.
Agentry <app_ID>.WebSockets Logs system messages related to server/client communication using WebSockets connection type
for the Agentry application.
Agentry Logs system messages related to server/client communication using WebSockets connection type
<app_ID>.WebSockets.connection.* for the Agentry application.
B2C Application Services Logs system messages related to the Business-to-Consumer services used for Mobiliser logs.
Mobiliser must be enabled to set log levels.
B2C Framework Logs system messages related to the Business-to-Consumer framework used for Mobiliser logs.
Mobiliser must be enabled to set log levels.
Backend Request Header Trace When the logging level is set to Debug, logs the backend request and response headers issued by
SAP Mobile Platform. This log can be used to analyze communication issues between SAP Mobile
Platform and back end systems, including push services.
 Note
This log contains sensitive information such as passwords and should be used for technical
analysis only.
Backend Request Wire Trace When the logging level is set to Debug, logs the backend request and response headers issued by
SAP Mobile Platform, including the payload information (in binary or compressed format). This log
can be used to analyze communication issues between SAP Mobile Platform and back end
systems, including push services.
 Note
analysis only.
Client Request Trace When the logging level is set to Debug, logs the client request and response headers issued by
SAP Mobile Platform. This log can be used to analyze communication issues between SAP Mobile
Platform and clients.
 Note
analysis only.
Cluster Logs system message related to managing the cluster.
Connectivity Logs system messages related to all HTTP connections made by the server.
Foundation Logs system messages for core SAP Mobile Platform Server functionality.
Hybrid Application Management Logs system messages related to managing hybrid apps through Management Cockpit or the API,
and client interactions for requesting and downloading updated hybrid apps.
Integration Gateway Logs server-side system messages for plug-ins integrated with SAP Mobile Platform Server, such
as data sources (SAP and OData), and third-party systems and protocols (such as SOAP, JDBC,
HANA Cloud, and NetWeaver PI).
5/12/2023
Offline Logs system messages related to the offline OData service.
Other Controls all other loggers not covered here. This is implemented by having a single logger named
ROOT in this component, setting the level of the root logger affects any logger that does not fall
under one of the loggers have been assigned a level explicitly
Proxy Logs system messages related to any client-back end interactions using SAP Mobile Platform
Server as a proxy (for example, OData requests).
Push Logs system messages related to push actions.
Registration Logs system messages related to application registration.
Security Logs system messages related to SAP Mobile Platform security.
Serviceability Logs system messages related to framework components such a security or Web services, plus
messages that are related to JDK and the server's runtime environment.
Statistics Logs system messages related to usage statistics.
Logging Levels
Warn The application can recover from the anomaly, and ful ll the task, but requires attention from the developer or
operator.
Related Information

Enable application traces for selected SAP Mobile Platform Server logging components.
Context
Application tracing captures additional business data for a request (such as message data, payloads, HTTP headers, and URIs), which you
can use to troubleshoot application problems. The business data captured in application traces is determined by the application
developer. Enable tracing for individual logging components on an as-needed basis.
 Note
5/12/2023
Enabling traces can impact server performance. Only enable traces when required for debugging or user support.
You cannot enable traces for Agentry logging components.
Procedure
2. For each component, enable tracing as required.
Related Information
Setting Log Levels

View log and trace information to troubleshoot application problems. Use search criteria to nd the log records and trace statements
needed to diagnose a problem. Depending on what information is being captured, log and trace information can include entries from
client logs, server logs, and application traces. For applications developed using SAP Mobile Platform SDK 3.0 SP04 or earlier, you cannot
view client logs in the Logs and Traces View but can instead download and view a client log le in the Registrations view.
Context
 Note
You cannot view Agentry logs in this view. View Agentry log les on the Log Files tab.
Procedure
1. In Management Cockpit, select Logs Log and Trace .
2. Enter log search criteria:
For Application ID, select an application to view only logs or traces speci c to that application, or select All.
For Status, select a logging level to view only log messages and trace information of a speci c type, or select All.
Logging Levels
Warn The application can recover from the anomaly, and ful ll the task, but requires attention from the developer
or operator.
5/12/2023
For Type, select a request type to view only log messages or trace information for that type of request, or select All.
For Component, select a server logging component to view only log messages and trace information speci c to that
component, or select All.
System Logging Components
Admin Logs system messages related to SAP Mobile Platform administration.
Agentry Logs system message related to Agentry applications.
Agentry user.* Logs system messages related to Agentry application users.
Agentry <app_ID> Logs system messages related to the Agentry application.
Agentry <app_ID>.BackEnd.* Logs system messages related to the back-end data source connections, such as SQL or
Java, for the Agentry application.
Agentry Logs system messages related to the back-end data source push service for the Agentry
<app_ID>.ThirdPartyPushServices application.
Agentry <app_ID>.WebSockets Logs system messages related to server/client communication using WebSockets connection
type for the Agentry application.
Agentry Logs system messages related to server/client communication using WebSockets connection
<app_ID>.WebSockets.connection.* type for the Agentry application.
B2C Application Services Logs system messages related to the Business-to-Consumer services used for Mobiliser
logs. Mobiliser must be enabled to set log levels.
B2C Framework Logs system messages related to the Business-to-Consumer framework used for Mobiliser
logs. Mobiliser must be enabled to set log levels.
Backend Request Header Trace When the logging level is set to Debug, logs the backend request and response headers
issued by SAP Mobile Platform. This log can be used to analyze communication issues
between SAP Mobile Platform and back end systems, including push services.
 Note
This log contains sensitive information such as passwords and should be used for
technical analysis only.
Backend Request Wire Trace When the logging level is set to Debug, logs the backend request and response headers
issued by SAP Mobile Platform, including the payload information (in binary or compressed
format). This log can be used to analyze communication issues between SAP Mobile
Platform and back end systems, including push services.
 Note
Client Request Trace When the logging level is set to Debug, logs the client request and response headers issued
by SAP Mobile Platform. This log can be used to analyze communication issues between SAP
Mobile Platform and clients.
 Note
Cluster Logs system message related to managing the cluster.
Connectivity Logs system messages related to all HTTP connections made by the server.
Foundation Logs system messages for core SAP Mobile Platform Server functionality.
5/12/2023
Hybrid Application Management Logs system messages related to managing hybrid apps through Management Cockpit or the
API, and client interactions for requesting and downloading updated hybrid apps.
Integration Gateway Logs server-side system messages for plug-ins integrated with SAP Mobile Platform Server,
such as data sources (SAP and OData), and third-party systems and protocols (such as
SOAP, JDBC, HANA Cloud, and NetWeaver PI).
Offline Logs system messages related to the offline OData service.
Other Controls all other loggers not covered here. This is implemented by having a single logger
named ROOT in this component, setting the level of the root logger affects any logger that
does not fall under one of the loggers have been assigned a level explicitly
Proxy Logs system messages related to any client-back end interactions using SAP Mobile
Platform Server as a proxy (for example, OData requests).
Push Logs system messages related to push actions.
Registration Logs system messages related to application registration.
Security Logs system messages related to SAP Mobile Platform security.
Serviceability Logs system messages related to framework components such a security or Web services,
plus messages that are related to JDK and the server's runtime environment.
Statistics Logs system messages related to usage statistics.
For Number of Entries, select the maximum number of log entries to be displayed. Limiting the number of entries displayed
For the time frame, indicate a start and stop range.
For User Name, enter the name of a user to view only log messages and trace information for requests initiated by that
user.
3. View the logs and traces that meet the search criteria:
Column Description
Status Log entry status, typically Error or Success.
Registration ID The unique connection identi er that makes the request to the server.
User Name The name of the user associated with the application ID.
Registration Creation Time The time and date stamp for the log entry.
Type The log type, such as application settings, deregistration, and so forth.
Log Trace The link to detailed log and trace information associated with the execution request. Optionally,
you can download a text le for further analysis.
Application ID Unique identi er for the application, in reverse-domain notation. This is the application or
bundled identi er that the application developer assigns or generates during application
development. The administrator uses the application ID to register the application with SAP
Mobile Platform, and the client application uses the application ID to send requests to the
server.
4. (Optional) Select one or more rows and click Download to download a text version of the log le to the Downloads directory.
5. (Optional) Click the Log Trace icon to view log messages and trace information.
The Trace Logs Details window appears with log messages and trace information. Click Download to download a text le of the
trace information to the Downloads directory.
6. (Optional) To view log messages and trace information for multiple rows within the browser window, select the rows and click the
View Details icon.
5/12/2023
You can use browser search to search through the information using keywords. You can copy the content in the Log Details
window c to a text editor.
7. (Optional) Click the Reset icon to start fresh.
Related Information
Setting Log Levels
Tracing Network Activity

Application users can trace network activity based on user name, connection, application, or content type. You can download tracing
reports to either a .zip or a .har le.
Context
Con gure the tracing properties before you turn tracing on.
Procedure
1. In Management Cockpit, select Logs Network Traces .
2. By default, SAP Mobile Platform traces all users, connections, applications, and content types. To trace speci c activity, enter
values for one or more of these properties:
User Name
Registration ID
Application ID
Content Type
3. For Logging Type, select either:
Log only the rst 2K of payload, or
Log the whole payload for one hour
4. To start logging network activity, set Enable Network Trace to On. Logging starts immediately.
5. To download a tracing report:
a. Filter the report by specifying one or more of these property values:
User Name
Registration ID
Application ID or select All
Content Type or select All
b. Select the date range.
c. Select the output le type, ZIP or HAR, and click the Download icon.
6. To purge the trace log, select Purge Now.
5/12/2023
Using End-to-End Tracing to Troubleshoot and Diagnose Device

Problems
Analyze end-to-end (E2E) tracing to troubleshoot client issues. E2E tracing sessions are conducted by administrators and device users.
E2E trace information is recorded in a Business Transaction XML (BTX) le on the client, which is uploaded to the server, and then
uploaded to SAP Solution Manager for analysis.
Prerequisites
Con gure the client to support E2E tracing using the supportability-related tracing APIs. For more information, see the Developer
Guide for your platform.
Con gure SAP Solution Manager settings on SAP Mobile Platform Server.
Set the E2E trace level in the application's client policies.
Procedure
1. The user initiates tracing on the device.
2. The user performs the transaction that requires tracing.
3. The user stops tracing on the device.
4. The user uploads the BTX le to SAP Mobile Platform Server.
5. The BTX le is uploaded to Solution Manager where it can be analyzed.
Con guring SAP Solution Manager

Con gure SAP Solution Manager for end-to-end (E2E) tracing. E2E tracing sessions are conducted by administrators and device
users. E2E trace information is recorded in a Business Transaction XML (BTX) le on the client, which is uploaded to the server,
and then uploaded to SAP Solution Manager for analysis.
Related Information
Setting Log Levels
Viewing Client Tracing
Con guring SAP Solution Manager

Con gure SAP Solution Manager for end-to-end (E2E) tracing. E2E tracing sessions are conducted by administrators and device users.
E2E trace information is recorded in a Business Transaction XML (BTX) le on the client, which is uploaded to the server, and then
uploaded to SAP Solution Manager for analysis.
Procedure
1. In Management Cockpit, select Settings System .
2. Under Solution Manager Settings, set the following properties:
Solution Manager Settings
5/12/2023
Solution Manager URL None The URL associated with the SAP Solution Manager instance to which SAP Mobile
Platform belongs.
For an HTTPS URL:
a. Add the root certi cate (for example, SAPNetCA) to the smp_keystore.jks
le.
b. Restart the server.
SAP Solution Manager is used for runtime root-cause analysis of E2E tracing information.
Enabled for End to End False Enables SAP Mobile Platform Server for E2E tracing. BTX les that are uploaded from
Tracing clients are automatically uploaded to SAP Solution Manager.
If you initiate an E2E trace session with a client, the resulting BTX le is uploaded to SAP
Solution Manager for root-cause analysis.
Related Information
Keytool Utility
Purging Logs and Traces

Con gure a scheduled purge of logs and traces stored in the SAP Mobile Platform Server database, or purge log and trace les
immediately.
Context
By default, logs and traces are purged every day at 12:00 AM UTC, permanently deleting all logs except:
error logs (server and client) from the past 14 days
success logs (server and client) from the past day
success and error traces from the past day
 Note
Logs that are stored on the le system are not purged as part of the scheduled purge. Log les on the le system must be purged
manually.
Procedure
2. Under Log and Trace Purge, set the log purge schedule and delete the existing logs.
a. Select the day(s) of the week to purge logs.
b. Select the time of day to purge logs.
c. Select the number of days (1 – 30) to retain the server logs (error and success).
d. Select the number of days (1 – 30) to retain the client logs (error and success).
e. Select the number of days (1 – 30) to retain the traces (error and success).
f. (Optional) Click Purge Now to purge the logs immediately. This deletes existing logs and traces from the database, keeping
only the logs as speci ed in the settings.
g. Click Save.
Related Information
5/12/2023
Purging Agentry Logs
Audit Trail Logging

The audit log provides an ongoing record of the sequence of operations, procedures, event activities, or communications initiated by
individual users. By default, the audit log is always enabled.
Audit logs are stored in the SMP_AUDIT_LOG_DATA database table. Use the following APIs to access the audit logs in the database. The
audit logs can be purged by using SQL statements to access the database directly.
OData service for reading existing audit logs (update and delete are not allowed):
https://<host>:<port>/mobileservices/origin/smp/auditlog/v1/admin/AuditLogSet
Restful export service for downloading audit log data of logTime between starting date and ending date in CSV format:
https://<host>:<port>//mobileservices/origin/smp/auditlog/v1/runtime/downloadcsv?
startDate=2017-05-05T08:05:24.181Z&endDate=2017-07-05T08:05:24.181Z
OData V4 is used for the Admin API. The service document url is:
https://<host>:<port>/mobileservices/origin/smp/auditlog/v1/admin/
Service document:
<app:service xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app"

xmlns:metadata="http://docs.oasis-open.org/odata/ns/metadata" metadata:context="$metadata">
<app:workspace>
<atom:title>
com.sap.mobile.server.auditlog.admin.v1.AuditLogsService
</atom:title>
<app:collection href="AuditLogSet" metadata:name="AuditLogSet">
<atom:title>AuditLogSet</atom:title>
</app:collection>
</app:workspace>
</app:service>
Metadata:
<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">

<edmx:DataServices>
<Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="com.sap.mobile.server.auditlog.admi
<EntityType Name="AuditLog">
<Key>
<PropertyRef Name="ID"/>
</Key>
<Property Name="ID" Type="Edm.String" Nullable="false"/>
<Property Name="LogTime" Type="Edm.DateTimeOffset" Nullable="false"/>
<Property Name="Username" Type="Edm.String"/>
<Property Name="SourceIP" Type="Edm.String"/>
<Property Name="ActionType" Type="Edm.String"/>
<Property Name="ObjectID" Type="Edm.String"/>
<Property Name="ObjectType" Type="Edm.String"/>
<Property Name="ChangedAttributes" Type="Edm.String"/>
<Property Name="Status" Type="Edm.String"/>
<Property Name="Comment" Type="Edm.String"/>
</EntityType>
5/12/2023
<EntityContainer Name="AuditLogsService">
<EntitySet Name="AuditLogSet" EntityType="com.sap.mobile.server.auditlog.admin.v1.AuditLog"/>
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>
The admin API can support $ lter, $skip, $top. The $ lter can support contains,eq, ge, ne, gt,le,lt ,and , or ...
Con guring Agentry Application Logs

Con gure settings for Agentry logs. Agentry log le settings are con gured as part of de ning the application. Log settings apply to all
applications, not just the currently selected application.
Context
Some Agentry settings apply only to the selected application, and other settings apply to all Agentry applications. When you change
settings in a section marked "Affects All Agentry Applications", keep in mind that all Agentry applications are affected.
 Note
Some entries require an SAP Mobile Platform Server restart.
Procedure
2. Under Logging (Affects all Agentry Applications), edit log settings.
Event Log Valid le name, or path The le to which event log items are written. You can change the default to specify a different le
File and le name; the default name or location. The path can be relative to the server installation folder; or a full path that
is events.log. includes the drive letter. Requires server restart.
Maximum Numeric value, in bytes; The maximum size of the log le in bytes. A value of 0 indicates no maximum size. Any other
Log Size the default is 0. value results in the log le rolling over when the le exceeds the value set here.
Log Roll Time of day in 24-hour The time at which to roll log les. The server must be running for the les to roll over at the
Time clock format (HH:MM); the speci ed time. Requires server restart.
default is 1:00am.
Log Rolls Enabled or disabled; the Whether to roll the log les based on the time de ned in Log Roll Time. Requires server restart.
At Time default is enabled.
Message Valid le name, or path The le to which message log items are written. You can change the default to specify a different
Log File and le name; the default le name or location. The path can be relative to the server installation folder; or a full path that
is messages.log. includes the drive letter. Requires server restart.
3. Restart SAP Mobile Platform Server if you changed any setting that requires it.

Agentry application logs are rolled (moved) automatically to the \rolled directory, and are stored until you purge them. Decide
how long you want to keep the Agentry log les, then delete the les manually, or archive them to storage for later analysis.

5/12/2023
Agentry application logs are rolled (moved) automatically to the \rolled directory, and are stored until you purge them. Decide how
long you want to keep the Agentry log les, then delete the les manually, or archive them to storage for later analysis.
Context
The Agentry log les are in <SMP_HOME>\logs\agentry\rolled\<yyyy-mm-dd-HHMMSS>, where <yyyy-mm-dd-HHMMSS>
represents the date and time the log les were moved into the directory. If a version, such as <-1> or <-2> is appended to the le name, it
indicates that the logs were rolled twice in the same second (this happens only rarely, when a large volume of data is added to a log le).
Rolled les are the same as the originals, such as events.log, messages.log, shutdown.log, and startup.log.
Procedure
1. Navigate to <SMP_HOME>\logs\agentry\rolled.
2. Identify the log les to purge.
3. Delete the les, or archive them for later use.
Monitoring Hybrid Application Versions

When multiple versions of a hybrid application are running on registered devices, you can see the percentage of devices that are running
each version of the application.
Procedure
1. In Management Cockpit, select Reporting Hybrid Application Versions Report .
2. Select the Application ID.
For active versions of the selected application, a pie charts shows the percentage of registered devices on which each version is
running. In the following example:
Version 0 (latest) ‒ 12.5% of registered devices are running the latest version of the software.
Version 1 ‒ 50% are running the previous version, and so on.
Version 2 ‒ 25%
Version 3 ‒ 12.5%
3. To lter the report, enter a value for one of the following properties, and click the Search icon .
User Name
Registration ID
Application ID
Client Revision
Device Type
5/12/2023
4. To sort results based on one of these properties, click and select the search eld. You can sort the results in ascending or
descending order.
5. To customize the table view, click and select the columns.
6. To export the table data of a speci c application version to a CSV le, select the row and click its Download icon .
7. To see more information about a speci c application version, select the row .
8. To refresh the report, click the Refresh icon .
Provisioning Applications
Provision the application to supported devices so users can install and log in to the application to register with SAP Mobile Platform
Server. You can provision applications through native application stores, through enterprise Web site downloads, or through Afaria.
 Note
You must de ne and con gure the application on the server before users can register.
Provisioning with Afaria

You can use Afaria to provision native and hybrid applications that use the MAF Logon UI component by creating a provisioning le
containing a set of parameters.
Provisioning with Afaria

You can use Afaria to provision native and hybrid applications that use the MAF Logon UI component by creating a provisioning le
containing a set of parameters.
Context
Afaria uses the provisioning le to deliver application con guration data to the device. The user installs the application through Afaria
client. When the application starts, the MAF Logon UI displays connection registration elds based on settings in the provisioning le.
Setting Up the Afaria Environment

In order to deliver application con guration data using Afaria, you need to install and con gure the Afaria package server and set
up automatic enrollment for your devices. Once devices are enrolled you can de ne the application you are provisioning by setting
up application policies. This includes importing the MAF Logon provisioning le, which is used to seed the application with
con guration data.
Creating an MAF Logon Provisioning File
Create a provisioning le for applications that use the MAF Logon UI component. The provisioning le is an ASCII text le. Each
setting in the le must be on a separate line, or separated by a semicolon. The settings in the provisioning le provide applications
with initial connection registration values that control the elds that display in the MAF Logon UI.

In order to deliver application con guration data using Afaria, you need to install and con gure the Afaria package server and set up
automatic enrollment for your devices. Once devices are enrolled you can de ne the application you are provisioning by setting up
application policies. This includes importing the MAF Logon provisioning le, which is used to seed the application with con guration data.
Context
5/12/2023
For complete information on installing and con guring Afaria, refer to the following Afaria documentation:
Afaria Installation Guide
Afaria Administration Reference
The tasks listed below are speci c to delivering application con guration data. Refer to the Afaria documentation for the details of each
task.
Afaria Setup Tasks
Task Description Afaria Documentation
Install and con gure the Afaria package server Delivers applicaton con guration data to Afaria Installation Guide > Package Server
component devices.
Set up device enrollment policies Automates enrolling devices in Afaria Afaria Administration Reference > Enrolling
management Devices in Management
Afaria Administration Reference > Policy >

Enrollment Policies
Set up application policies De nes application packages for devices Afaria Administration Reference > Application
Onboarding > Provisioning Data for iOS and
Android Applications
Afaria Administration Reference > Policy >

Application Policies
Task overview: Provisioning with Afaria
Related Information

Create a provisioning le for applications that use the MAF Logon UI component. The provisioning le is an ASCII text le. Each setting in
the le must be on a separate line, or separated by a semicolon. The settings in the provisioning le provide applications with initial
connection registration values that control the elds that display in the MAF Logon UI.
You can create a provisioning le for individual applications or provide settings for all applications in a single le. All settings in the
con guration le are optional.
Key Description
servername= The host name for the machine that hosts the SAP Mobile Platform
Server or reverse proxy, if used.
serverport= The server port number for SAP Mobile Platform Server. The default is
8080.
ishttps= Boolean value that determines whether to use HTTPS instead of the
default unsecured HTTP.
5/12/2023
Key Description
vaultpolicy= Controls the use of application passwords in the MAF Logon UI.
Possible values:
defaulton – password elds are displayed. The user can

enable/disable the password,
defaultoff – password elds are not displayed. The user

can enter a password by performing additional steps.
alwayson – password elds are displayed. The user must

enter a password.
alwaysoff – password elds are not displayed.
usercreationpolicy= Controls how user records are created on the server.
Possible values:
automatic – user records are created automatically in the

authentication provider as part of the registration process.
certificate – user records are created automatically based

on the client's security certi cate.
manual – you must create users records on the server by

manually registering applications. The manual user creation
policy applies only to applications that connect to a 2.x version
of SAP Mobile Platform Server.
gatewaypingpath= The Gateway server's ping path. This is used by MAF Logon to identify
the SAP NetWeaver Gateway server.
gatewayclient= Identi es the client on the Gateway server. This is added to registration
requests as a URL encoded parameter.
resourcepath= If you installed a reverse proxy in your landscape, use to specify the
URL suffix that the MAF Logon should use during registration requests.
domain=
 Note
Applies only to applications that connect to a 2.x version of SAP
The server domain that clients will register to.
companyid=
 Note
The company or farm ID of the relay server used to connect to the

server.
securitycon g=
 Note
The security con guration created on SAP Mobile Platform Server.
Example: Example: provisioning le for automatic user creation
servername=smp.server.com;
serverport=8080;
ishttps=false;
5/12/2023
vaultpolicy=defaulton;
usercreationpolicy=automatic;
Example: Example: provisioning le for user creation based on certi cate
servername=smp.server.com;
serverport=8443;
ishttps=true;
vaultpolicy=defaulton;
usercreationpolicy=certificate;
Parent topic: Provisioning with Afaria
Related Information

Administration Overview

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Administration Overview

Uploaded by

Copyright:

Available Formats

5/12/2023

SAP Mobile Platform Server 3.1 | 3.1

Original content: https://help.sap.com/docs/SAP_MOBILE_PLATFORM_SERVER_31/313e7789125149b3b5bb6f1c7e1ea322?locale=en-

For more information, please visit the https://help.sap.com/docs/disclaimer.

Administrator tasks fall into three main categories:

Security administration for setting up secure communications and protecting data.

There are separate administration tasks for Mobiliser applications.

SMS applications are administered through a separate server.

SAP Mobile Platform Server Overview

SAP Mobile Platform Server Overview

Application services consist of services for Mobiliser and Agentry applications.

Core services consist of the following:

HTTP(s) Con guration – open standards for client communications.

Lifecycle Management – managing and deploying multiple versions of a hybrid application.

Supportability – logs for monitoring system health and troubleshooting.

SAP Mobile Platform Server as an OData Proxy

SAP Mobile Platform Server as an OData Proxy

URL Rewrite Modes

SAP Mobile Platform Server supports these URL rewrite modes:

URL Rewrite in SMP

URL Rewrite in Backend

URL Rewrite in SMP or No URL Rewrite

URL Rewrite in SMP

Using Additional Paths

URL Rewrite in Backend

If you select URL Rewrite in SMP, the server replaces:

Backend URL = https://anybackend.sap.com/oData/sample

Response: <a href=”https://anybackend.sap.com/oData/sample/Customers(‘4711’)” />

<a href=”https://smp.sap.com/demo/Customers(‘4711’)” />

<a href=”/oData/sample/Customers(‘4711’)” /><a href=”/demo/Customers(‘4711’)” />

is translated into this:

<a href=”/demo/Customers(‘4711’)” />

Single Sign-On Mechanisms

SSO Mechanism Description

Con gure the back end:

Refer to your back-end system documentation for more information.

SSO Mechanism Description

Name – name of the header or cookie.

Pattern – header or cookie value.

Type – header or cookie.

How SAP Mobile Platform Server Handles Cookies

Oﬄine Applications Overview

You might want to run applications oﬄine to:

Column indexes for the client database

Logging and Tracing Overview

Hybrid App Feature Restriction Overview

SAP Push Plugin

Push Noti cation

Custom Push Provider

Capabilities-based Push Support

Device-type (form factor) Support

Con guration of Capabilities

Client Database Upload Overview

Developers (Application Development)

Exceptions When Working in a Clustered Server Environment

Postinstallation Landscape Setup

Set up the security landscape for the server.

Adding Reverse Proxies or Relay Servers

Adding Reverse Proxies or Relay Servers

Common Requirements for Reverse Proxies

Common Requirements for Load Balancers

Using Relay Server with SAP Mobile Platform

More than two Relay Servers

Hardware load balancer in place of Apache