Monitoring

Monitor message flow

Message Monitoring

Message monitoring is the most important activity that is often performed by administrators in the Administration Cockpit. A record of every message that flows into and out of the Unvired platform is maintained for trouble shooting, debugging, checking utilization of the platform and for various other reports. An auto-archiver is also provided to ensure that old messages do not affect the platform’s performance.

Message Processing

Different categories of messages are saved in the platform depending on the mode of usage. They are:

Asynchronous Messages

These are messages that are submitted by the mobile application in the background for processing by the Unvired server. The client sends the message and on successfully submitting it to the Unvired server disconnects without waiting for the final business result. Once the Unvired server posts the message to the corresponding backend systems and processes the message, the final result is queued for delivery to the mobile device. The mobile application is notified when a message is ready for delivery.

Each message that is held in the Unvired platform is in a specific state and identified by the following status:

• Queued – Queued for processing.
• Ready – Message is ready to be delivered to the device.
• Delivered – Message successfully delivered and acknowledged by the device.
• Failed – Message failed.
• Ignored – Message was ignored by the system. (This is only for pull / scheduled messages wherein the older message was not downloaded by the device but in the meantime newer data was available and the system ignores the older message)
• Discarded – Message was manually discarded by the administrator in the Administration Cockpit.
• Held for Admin Processing – Messages that errored out on the backend system can optionally be held on the UDEP so that administrators can login and update the data and resubmit to the backend system. This is useful wherein users require an “upload and forget” user experience and don’t want to be bothered about errors on SAP or other backend systems.

Synchronous Messages

These are messages that are submitted by the mobile application in the foreground for processing by the Unvired server. The client holds the connection until a final result is available from the Unvired server after processing by all corresponding backend systems. The user will not be able to work with the application during this time and it blocks the user interface. Once the result is delivered to the mobile application and processing, the user will be able to work with the application again.

REST API Messages

These are messages that are submitted by the external application using the REST APIs exposed by the UDEP. The external application can submit requests to be executed by UDEP in foreground or background.

Message Monitoring

Asynchronous Requests

The “Asynchronous Messages” menu option in the navigation tree displays the Asynchronous Message Monitor.

The various criteria for searching messages are:

• All – Show all messages
• Application – Search for all messages for a particular application. You can additionally filter based on a function of that application.
• Conversation ID – Each message is identified by a unique Conversation ID. If the conversation ID is known enter the ID to navigate directly to that message. (The ID can be obtained from the Sent messages view in the mobile application or from the debug logs)
• Delivery Status – Search for the messages based on the message status (explained above)
• Frontend User – Search for the messages for a particular device / user
• On Hold – Search for the messages that have errored out and are being held for processing by the administrators.
• Post Time – Enter a time interval to search for messages
• Tag1/Tag2 – Search for the messages based on tags set by the process agents.

The different fields that are displayed for each message are:

• Post Time – The date / time on the server when the message was received
• Application – The application for this message
• Function Name – The function in the process agent that was executed for this message
• Flow – The further calls to the backend systems that are made by the PA functions can be traced here.
• Conversation ID – The conversation ID for this message
• UDEP Node – In a multi instance UDEP installation, the individual node that processed the request is listed here
• Reference – The external reference that was (optional) supplied to the request by the REST API.
• Message Class – The message class – Can be of type Application or System. If the message class is “Application” the message subclass can be of type:
  • Business Entity data – Data exchanged in the Unvired format (standard).
  • Custom – Custom application defined format.
• Message Subclass - The message subclass. If the message class is “System” the message subclass can be of subtype:
  • Authenticate – User authenticated from the mobile application
  • Activation – Mobile application was activated for the user
  • Backend Authenticate – User’s backend credentials on the mobile device were authenticated on the backend system
  • Ping – Ping message was received from the mobile device and responded to by the server to test connectivity from device to server
  • Log – Log message request sent to device / received log from the device
  • Data dump – Data export request sent to device / received from the device
  • Initiate pull – Data download request sent to device
  • Push Notification – Device informs server of the push notification id to use
  • Reset – Reset data request sent to device
  • Wipe – Wipe data request sent to device
• Message Type – The message type. This can have the following values
  • RQST – Request / response type where the mobile application made a request and (optionally) received a response in return
  • PUSH – Push type where an external system is pushing a message to the mobile device
  • PULL – A schedule pull of data from the backend system queued for delivery to the mobile device
  • QUERY – Typically a search query that was executed by the device
• Unvired User – The Unvired user ID
• FE User – The frontend device / user for whom the message is (to be) delivered
• Delivery time – The date/time the message was delivered to the mobile device
• Delivery status – The message status as explained earlier
• IP – Device IP address
• Tag1, Tag2 – The optional tags to the messages added by the process agent
• Backend result time – The date / time when the process agent responded with the result (the difference between the post time and - backend result time is the approximate lag between when a message was received from the device and when the backend system(s) actually returned with the result from the process agent)
• Total Time – The total time between start of call to availability of result
• Backend result status – Indicates the process agent result state – Success or Error. Please note that on development systems this status can also be “Test” to indicate that the message was a response when the test mode was enabled. Additionally an overridden function call is indicated by an “O” in the status.
• Message In size – The input message size in bytes
• Message Out size – The output message size in bytes
• Message – The actual message displayed as below
• On Hold – Held on UDEP for further processing by Administrators

Synchronous Requests

The “Synchronous Messages” menu option in the navigation tree displays the Synchronous Message Monitor. The various criteria for searching messages are:

• All – Show all messages
• Application – Search for all messages for a particular application. You can additionally filter based on a function of that application.
• Conversation ID – Each message is identified by a unique Conversation ID. If the conversation ID is known enter the ID to navigate directly to that message. (The ID can be obtained from the Sent messages view in the mobile application or from the debug logs)
• Frontend User – Search for the messages for a particular device / user
• On Hold – Search for the messages that have errored out and are being held for processing by the administrators.
• Post Time – Enter a time interval to search for messages
• Tag1/Tag2 – Search for the messages based on tags set by the process agents.

The different fields that are displayed for each message are:

• Post Time – The date / time on the server when the message was received
• Application – The application for this message
• Function Name – The function in the process agent that was executed for this message
• Flow – The further calls to the backend systems that are made by the PA functions can be traced here.
• Conversation ID – The conversation ID for this message
• UDEP Node – In a multi instance UDEP installation, the individual node that processed the request is listed here
• Message Class – The message class – Can be of type Application or System
• Message Subclass – As defined for Asynchronous messages
• Message Type – The type of message
• Unvired User – The Unvired user ID
• FE User – The frontend device / user for whom the message is (to be) delivered
• IP – Device IP address
• Tag1, Tag2 – The optional tags to the messages added by the process agent
• Backend result time – The date / time when the process agent responded with the result (the difference between the post time and backend result time is the approximate lag between when a message was received from the device and when the backend system(s) actually returned with the result from the process agent)
• Total Time – The total time between start of call to availability of result
• Backend result status – Indicates the process agent result state – Success or Error. Please note that on development systems this status can also be “Test” to indicate that the message was a response when the test mode was enabled. Additionally an overridden function call is indicated by an “O” in the status.
• Message In size – The input message size in bytes
• Message Out size – The output message size in bytes
• Message – The actual message displayed as in the Async message example above
• On Hold – Held on UDEP for further processing by Administrators

REST API Requests

The Unvired Mobile Platform can also be used by external systems using the REST API. All calls to the RESP API are logged and displayed in the REST API Log monitor.

The logs can be searched based on:

The API executed (Refer the REST API document for the list of APIs supported for external system access) Depending on the API chosen further options are available for search.

• Application, additional filtering on the function executed is possible
• Conversation ID
• External Reference
• Master User
• Post time interval

The messages displayed are as follows:

• Post Time – The date / time on the server when the message was received
• Application – The application being accessed
• API Function– The API function that was executed for this message (for more details refer the REST API document)
• User – The Unvired or Master user used for execution
• API – The REST API accessed
• Category – The category within the REST API (for e.g. Authenticate etc.)
• Execute Function – If the API called is Execute, the function name is listed here.
• Message Type – The message subclass can be of type:
  • Business Entity data – Data exchanged in the Unvired format or iBXML for short.
  • Custom XML – Custom application defined format.
• HTTP Verb – POST, GET etc
• HTTP Status Code – The REST API HTTP result code, for e.g. on success return code will be 200
• Conversation ID – The conversation ID for this message
• External Reference – The external reference provided for this message
• IP Address – IP address of the caller
• Message In size – The input message size in bytes
• Message Out size – The output message size in bytes
• Message Details – The actual message is displayed

Message Types

Message Type	Message Sub-type	Description
4000		Authentication type messages
	100	Authenticate to UDEP
	200	Activate application
	300	Authenticate to a Backend System
	400	Change Password
	500	Forgot Password
	600	For later use
	700	Request for a one time use login token to authenticate without password
5000		System Wipe
	0	Wipe the application and framework database. Removes all access for user to device data via the application.
8000		Application messages
	600	Standard XML or JSON from/to UDEP
	700	Custom XML or JSON from/to UDEP
	800	Standard XML or JSON data pushed from external system
	900	Custom XML or JSON data pushed from external system
9000		System messages
	100	Ping device or server (bi-directional message)
	200	Request device log
	210	Reset device log
	220	Set device log level to ERROR
	230	Set device log level to DEBUG
	300	Request device data dump
	400	Request initial data from UDEP
	500	UDEP Framework settings for device
	600	Application settings for device
	610	Push notification registration
	700	Reset application data
	800	Activation message with framework settings
	900	System error
	1000	System information

Request Types

The device can make requests of different types to the server and the handling is different in each case.

Request Type	Description
RQST	Typical Request response message. Device sends the request to the UDEP for processing and server response is sent back to device. In Async mode device will await the response and will process the response as and when it is available.
QUERY	Device sends a request to the server for which may or may not have a response. Device only expects an optional response in this case.
PULL	Typically master data from server is sent to the device as a PULL message. This will Add/Modify/Delete the existing data based on the action that is returned in the data. Data that is already on the device but not in the current message will be left unaltered.
PULL_D	Pull with delete. This will delete all the existing data on the device for all the business entity types present in the message. The data is then directly imported.
PUSH	Data that is pushed automatically from the server and sent to the device. The data is processed based on the action that is specified in the data itself.

Device Monitoring

The UDEP records every communication from the mobile device to the UDEP server and vice versa. All these messages can be viewed in the Async and Sync message monitor. The Device Monitor offers a simplified view of device interaction. For eg. if an administrator needs to quickly check when was the last communication from the device for a particular user or when was the last instance when they downloaded a message etc can be determined very quickly.

The fields displayed are:

• Last Access Time – The last time the device contacted the UDEP for any communication.
• Last Download Time – The last time the device downloaded messages that were queued and waiting for the user.
• Master User – The Unvired ID of the user.
• Front end user – The device identifier of the user.
• Application – The application name.
• IP – The IP address of the device.
• Activation Time – The activation time of the application.
• Call Type – The last call type, Sync or Async.
• Application Version – The version of the mobile application.
• Framework Version – The version of the mobile framework.
• Update Date – The date / time when the mobile application registered the version with the server (the first time ever)
• Device OS – iOS 9, etc
• Device Type – iPad mini 2G (WiFi), Motorola etc

Selecting a particular user permits the Administrator to perform a few simple operations:

• If Location tracking is enabled, clicking on Show Maps or Show Location brings up a Google Map with the device located on it.
• Clicking on Actions permits the administrator to perform a number of administration tasks as detailed in the Deployment tasks section earlier.

Attachments

The UDEP provides the required support for handling attachments or files in a very easy manner. Attachments can be uploaded from the device to the attachment cache and then associated with other business data or downloaded to the device. Download can be automatically initiated by the device or can be on demand.

Similar to the Async and Sync message monitor the list out all the message interactions between UDEP and mobile application, the Attachment Status log displays all attachment related interactions.

The monitor consists of two tabs.

• Attachment Cache – Lists all attachments (Downloaded and Uploaded) that are present in the UDEP cache currently.
• Attachment Status – Lists all attachment related interactions that have been performed and their status.

Attachment Status

The Attachment Status lists all the attachment related transactions that have been performed. The fields displayed are:

• Direction – Upload to UDEP or download from UDEP
• Application Name – The application that initiated the attachment
• Master User– The Unvired ID of the user.
• Front end user – The device identifier of the user.
• Start Time – The date/time the attachment transaction was initiated
• End Time – The date/time the attachment transaction was completed
• Filename – The file downloaded
• Tags – Tags associated with the attachment
• Status – The status of the transaction, COMPLETED or FAILED

Device Logs & Data

Whenever device logs and/or data are sent to the server, they are available for viewing by clicking on the “Device Logs and Data” menu option in the navigation tree. The list shows all logs and data received from the devices. Click on the details button to display the data and logs. You can additionally delete the selected log or data dump, delete all of them and refresh the list to view data or logs that have been received after the list was displayed.

Audit Logs

Audit logs keep track of all important changes that have been made to the system, messages, configuration etc. by administrators.

The logs can be searched on:

• Administrator user name
• Action type (type of action performed)
• Time

The messages displayed are as follows:

• User name – The administrator user who performed the operation
• Date / Time – The date / time the action was performed
• Action Type – The different actions that have been performed. The actions are:
  • Admin User – All activities like administrator login and logout.
  • Applications/Libraries – All changes and deployment activities related to applications and libraries.
  • LogicalSystem – Changes related to backend configuration.
  • BackendUser – Changes related to backend user configuration.
  • Frontends – Changes related to frontend configuration.
  • FrontendUser - Changes related to frontend user configuration.
  • GlobalProperty – Changes related to global system configuration.
  • Functions – Changes related to function configuration.
  • Groups - Changes related to group configuration.
  • Messagess – Changes related to messages discarded etc.
  • Port – Changes related to port configuration.
  • Schedulers, Repetitive Scheduler, Specified Scheduler – Changes related to scheduler configuration.
  • Users – Changes related to Unvired user configuration.
• Action Sub type – Further categorization of the action performed. For example Administrator’s login and logout activity are additionally categorized here
• Action Message – Detailed message regarding the action performed
• Entity name – Technical details regarding the technical object on which the action was performed. In cases where the Conversation ID is recorded the administrators can refer to that. All other IDs recorded here are for Unvired support purposes.
• IP Address – The IP address of the computer used to access the UAC.

Troubleshooting

The various message monitors and logging capabilities provided by the platform can be used to troubleshoot the platform. Typical issues confronting a UDEP Administrator are:

• Users cannot login to the application.
• Users are unable to submit data to the server or download data.
• Users are getting errors on submission of data to the server.
• Push notifications are not working.
• Exceptions on the server or client.
• UAC is not responding.

The issues are typically related to network issues in reachability of the UDEP server. If this has been ruled out, the administrator can use the monitoring tools as follows:

• View the Device Monitor to check when the device last connected to the server, what is the model of the device and the software version, version of the App installed, was it updated recently. This will give a fair idea on whether the device is establishing connections or not.
• The Admin can queue a PING request to the device and view the Async Monitor to check if the message is delivered to the device. If the message is delivered then the device is confirmed to be online if not maybe the device is not able to reach the server, Further checks on the device can be performed. If all devices are not able to communicate it could also be a DNS issue or otherwise.
• View the Async Monitor and check if messages are being delivered to this device. If a lot of READY messages are seen then the device is not downloading the messages. Request the user to kill the application and restart it to check if connectivity is established and message flow is resumed.
• If the application has a synchronous behavior the Sync message monitor can be checked.
• All admin messages such as activation, push notification registration etc are all listed in the Sync Message Monitor as ADMIN_SERVICES messages.
• If push notifications are not working check if the push has been registered on the server by looking for the appropriate message. If the user can be reached, request them to access the Settings screen and click on Test Push Notification. A notification message is sent immediately for testing. The Admin can also use the Users tab, select the user and choose the send notification option to send a message for testing.
• Retrieve the device logs and/or data for detailed analysis by placing a request either from the Users option or from the Device Monitor. All logs and data that are retrieved from the device are displayed in the Device Logs and Data monitor. If the device is not able to download the message, request the user to access the Settings screen and email the log to the administrator.
• For web applications the initial request received is recorded in the REST API log and can be viewed there. These messages are then further forwarded either for Sync or Async processing and can be seen in the appropriate monitors with the respective conversation IDs.
• Sync, Async and REST API monitors also record the input and the output data. This is controlled by the App Property STORE_MESSAGE_DATA. In production landscapes it is recommended to switch this off. However in case of errors this can be turned on to view the data flowing. Additionally this setting can also be configured at a function level so that only specific functions can be traced.
• The Wildfly server log has a wealth of information and can be analyzed with the Conversation ID for detailed logs and exception troubleshooting. AUDIT traces record all inbound and outbound calls. Configure the standalone-full.xml (if you can restart the server) and set the com.unvired.ump.core and com.unvired.ump.web categories to INFO to see additional logs. Note that com.unvired.ump.app should always be set to INFO level and controlled via the App Property. If the server cannot be restarted, the Wildfly admin cockpit can be used to configure the logs while the system is online.
• Another issue why UAC or UDEP is slow or does not respond could be due to the slowness of the UDEP configuration database that it is connecting. Ensure that there are enough connections in the configuration in the standalone-full.xml file. Also use the Wildfly Admin Cockpit to monitor the number of database connections used and increase if necessary.
• Ensure that the UDEP database is fast and analyze for slow queries, slow database performance etc.