2016-08-24 3 views
1

Я захватил некоторые журналы событий от моего клиента приложения MobileFirst 7.1 (гибридный для прошивки) с помощью Analytics API:Экспорт данных MobileFirst Analytics

WL.Analytics.log({'Module': 'Account', 'Activity': 'Update account'}, 'Message Title'); 

И я мог бы получить журналы из Analytics консоли без каких-либо проблем ,

Далее я бы взял журналы, используя Analytics API. Ниже приведен рабочий формат URL:

http://localhost:10080/analytics-service/data/administration/apps/worklight/export?query={"event":"CustomData","format":"json","limit":10,"offset":0,"startDate":"2016-08-24","endDate":"*"} 

, который возвращает следующие данные в формате JSON:

[ 
    { 
    "mfpAppName": "myApp", 
    "deviceOS": "ios", 
    "appID": "worklight", 
    "mfpAppVersion": "1.0", 
    "deviceOSversion": "7", 
    "deviceModel": "xxx", 
    "deviceID": "xxx", 
    "timestamp": "1472038253030", 
    "Module": "Account", 
    "Activity": "Update account" 
    } 
] 

Мои вопросы:

  1. Как я могу фильтровать результаты JSON на основе моих пользовательских данных? Например, я хочу получить журналы для всех видов деятельности, которые имеют значение: «Module»: «Account».
  2. Как я могу отсортировать результаты JSON, например, на основе значения метки времени?
  3. Когда я пытался добавить в мой собственный параметр (например, «фильтр») в URL, он будет возвращать ошибку, которая говорит:

    { «подстраховаться»: «Непризнанные поле \» фильтр \»(класс com.ibm.mobile.analytics.server.rest.params.ExportParameters), не отмеченные как невежественные (29 известных свойств:, \ "level \", \ "validationCode \", \ "serverIpAddress \", \ "mfpAppVersion \" , \ "hours \", \ "realm \", \ "adapter \", \ debug \ ", \" offset \ ", \" mfpAppName \ ", \" event \ ", \" deviceOSversion \ ", \ "timestampKey \", \ endDate \ "[усеченный]]) \ n в [Источник: [email protected]; строка: 1, столбец: 33] (через ссылочную цепочку: com.ibm.mobile.analytics. server.rest.params.ExportParameters [\ "search \"]) "}

    Могу ли я узнать, где я могу найти все «29 известных свойств», как он упоминает?

Я узнал, что MFP Analytics использует ElasticSearch как свой движок, и я попытался найти любую информацию об этом, но безрезультатно.

ответ

4

Для достижения вашей цели вам нужно будет включить конечную точку REST для Elasticsearch. Если вы находитесь на сервере Liberty, это очень просто, используйте приведенные ниже свойства JNDI.

<jndiEntry jndiName="analytics/http.enabled" value="true"/> 
<jndiEntry jndiName="analytics/httpport" value="9500"/> 

После включения конечной точки REST Elasticsearch вы можете создавать собственные запросы к серверу.

Вы можете написать запрос POST, подобный приведенному ниже:

curl 'http://localhost:9500/worklight/_search?sort=timestamp:asc' -d '{"query" : {"wildcard":{"worklight_data.Module": {"value": "Account"}}}}' 

Некоторые ссылки Elasticsearch могут оказаться полезными: https://www.elastic.co/guide/en/elasticsearch/reference/2.1/search-uri-request.html https://www.elastic.co/guide/en/elasticsearch/reference/2.1/search-request-body.html

+2

Привет Chevy, спасибо за кончик с помощью ElasticSearch REST конечной точки , Я тестировал его на своей локальной машине разработки, и он работает. Однако, когда я попытался сделать то же самое с моим удаленным сервером разработки (размещенным в AWS), он вернул ошибку «Не удалось получить какой-либо ответ». FYI, наш сервер удаленного развития также работает на сервере Liberty. Мы открыли порт 9500 в администрации AWS и перезапустили наш экземпляр MFP после обновления файла server.xml. Что мне здесь не хватает? Благодаря! –

+2

Я нашел ссылку, которая описывает свойства и конфигурации, которые могут быть установлены на сервере MobileFirst в файле worklight.properties: http://www.ibm.com/support/knowledgecenter/SSHSCD_7.1.0/com.ibm. worklight.monitor.doc/монитор/c_op_analytics_properties.html. Однако файл .properties не использует формат XML . Правильно ли, если я изменил свойства JNDI выше: wl.analytics.httpport = 9500 | wl.analytics.http.enabled = true? –

+2

После недельного пробного периода и ошибок выяснилось, что есть еще один файл server.xml, используемый сервером Analytics, и вставлял туда свойства JNDI. Теперь он работает правильно с нашего сервера AWS. –

Смежные вопросы