MobileFirst Analytics Receiver Server Configuration Guide
improve this page | report issueOverview
Configuration for the MobileFirst Analytics Receiver Server.
Jump to
Properties
For a complete list of configuration properties and how to set them in your application server, see the section Configuration Properties.
Configuration Properties
The MobileFirst Analytics Receiver Server can start successfully with following additional configuration.
The configuration is done through JNDI properties on both the MobileFirst Server and the MobileFirst Analytics Receiver Server. Additionally, the MobileFirst Analytics Receiver Server supports the use of environment variables to control configuration. Environment variables take precedence over JNDI properties.
The Analytics Receiver runtime web application must be restarted for any changes in these properties to take effect. It is not necessary to restart the entire application server.
To set a JNDI property on WebSphere Application Server Liberty, add a tag to the server.xml file as follows.
<jndiEntry jndiName="{PROPERTY NAME}" value="{PROPERTY VALUE}}" />
To set a JNDI property on Tomcat, add a tag to the context.xml file as follows.
<Environment name="{PROPERTY NAME}" value="{PROPERTY VALUE}" type="java.lang.String" override="false" />
The JNDI properties on WebSphere Application Server are available as environment variables.
- In the WebSphere Application Server console, select Applications → Application Types → WebSphere Enterprise applications.
- Select the MobileFirst Administration Service application.
- In Web Module Properties, click Environment entries for Web Modules to display the JNDI properties.
MobileFirst Analytics Receiver Server
The following table shows the properties that can be set in the MobileFirst Analytics Receiver Server.
| Property | Description | Default Value |
|---|---|---|
| receiver.analytics.url | Required. The URL that is exposed by the MobileFirst Analytics Server that receives incoming analytics data. For example, http://hostname:port/analytics-service/rest. |
None |
| receiver.analytics.username | Required. The user name that is used if the data entry point is protected with basic authentication. | None |
| receiver.analytics.password | Required. The password that is used if the data entry point is protected with basic authentication. | None |
| receiver.analytics.event.qsize | Size of analytic event queue size. It should be added with caution by providing ample JVM heap size. Default queue size 10000 | None |
| receiver.authorization.server.url | Required. The URL of the OAuth authorization server that is used by analytics receiver service. If the property is not set properly, analytic logs will not be able to sent to the analytics receiver service. | |
| receiver.authorization.client.id | Required. The identifier of the confidential client that handles OAuth authorization for the analytics receiver service. | |
| receiver.authorization.client.secret | Required. The secret of the confidential client that handles OAuth authorization for the analytics receiver service. |
MobileFirst Server
The following table shows the properties that can be set in the MobileFirst Server.
| Property | Description | Default Value |
|---|---|---|
| mfp.analytics.receiver.url | Required. The URL that is exposed by the MobileFirst Analytics Receiver Server that receives incoming analytics data and forward them to MobileFirst Analytics Server. For example, http://hostname:port/analytics-receiver/rest. |
None |
MobileFirst Admin Service
The following table shows the properties that can be set in the MobileFirst Admin Service. These properties are required to configure confidential client for Analytics Receiver service.
| Property | Description | Default Value |
|---|---|---|
| mfpadmin/mfp.receiver.authorization.client.id | Required. The identifier of the confidential client that handles OAuth authorization for the analytics receiver service. Mandatory only if the analytics-receiver enabled. | None |
| mfpadmin/mfp.receiver.authorization.client.secret | Required. The secret of the confidential client that handles OAuth authorization for the analytics receiver service. Mandatory only if the analytics-receiver enabled. | None |
Confidential Client and Scope Mapping
Confidential clients are clients that are capable of maintaining the confidentiality of their authentication credentials. Analytics Receiver API protects resources from unauthorized access by assigning a scope to the resource. The following steps are mandatory only if the analytics-receiver is enabled in the application. For more details see confidential client and scope mapping.
Registering the confidential client
Following step is required only if confidential client for analytics receiver service is not added by default. Ignore if its already added.
In the navigation sidebar of the MobileFirst Operations Console, click Runtime Settings → Confidential Clients. Click New to add a new entry. You must provide the following information:
- Display Name - an optional display name that is used to refer to the confidential client. For example: receiver.
- ID - A unique identifier for the confidential client (can be considered as a username). The ID can contain only ASCII characters.
- Secret - A private passphrase to authorize access from the confidential client (can be considered as an API key). The secret can contain only ASCII characters.
- Allowed Scope - A confidential client that uses ID and Secret combination is automatically granted the scope that is defined here. By default it should be authorization.introspect
Scope mapping
Map the receiver.mobileclient scope element to the application. Mandatory only if analytics-receiver used to send analytics logs.
- Load the MobileFirst Operations Console and navigate to [your application] → Security → Scope-Elements Mapping, click New.
-
Enter receiver.mobileclient in the Scope element field. Then, click Add.
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.