Users getting records they should not receive

Owned by Dorian Port
Last updated: Sept 03, 2014 by Mark Giagnacovo
6 min read

Problem

A user has a record on their device that they should not have received, how was it sent to them and why was it sent to them?

Explanation

The server processes records to users through one of two main distribution methods:

An initial load (initload / reload / clear and load) event: This is the load that first populates a device with data or if performed later, clears a device and reloads it with new data.  The rules defined in Rules->Download rules control which records should be initially delivered to your users.  During a load of a device, the user’s Data Source credentials are used to fetch records, so only records they have access to should be included in the load.

Getupdates load: For updates (including new records after the initload), we poll the data source for changes, usually every 10 minutes.  Individual user credentials cannot be used as if there are 300 users activated, we would need to make 300 calls to the data source every 10 minutes for a list of changes.  We would then need to make further calls to retrieve these records.  This is inefficient and can hit web service limits quickly or cause significant delay in processing updates.  As a result, we use one “super user” (usually admin) to retrieve all changes, allowing us to make one call and distribute the records using our own server rules.  The records are distributed using a combination of Rules->Get updates rules, system keys and the details we have stored in the user record.  If the rules are not configured correctly, this can result in records being sent to users who should not have received it.  This can occur if rules are not configured correctly as we are not using the login credentials to validate if they should view individual records.  If records are being distributed incorrectly, usually reworking the rules can prevent this in the future.

Firstly, we need to find out what the data is, when it reached our server and when it was sent to your user.  This should allow us to locate the logs to identify why the record routed the way it did and whether this highlights an error in the data or within the rules.

Step 1 - Identify the user / PIN / details of the user experiencing the issue

In order to check what was sent, we first need to establish if the correct values are stored for your user.  It provides us details of when your user activated, last received a cad and the values used for distribution in some rules (field value).

Identify the user
To find the user details associated with your user:
  1. On the device, select the options (the icon in the top left of the application on tablets, or from the options menu on phones), then select the Advanced Options, and then the App Info tab. You can then see the User Pin value.
  2. From the Swift MEAP™ Admin console, navigate to the Users page and use the "Search" button to try to identify the user having issues
  3. You can search using the activation email address (if known).  If you do not know the activation email address, try searching using "Field Value"
  4. In the search results, click on the "Details" icon to view details of the user

We require: User, PIN, Field Value, Created date, Cad received on and device.

Step 2 - Get the record details

In order to find out how something was distributed, we need to know exactly what it is that we are looking for and what changes took place to that record.

Getting record details

To identify the row id of the record, check in your data source.  If you cannot find it from your systems administrators, you will need to check to see if it can be located in the Swift MEAP™ server.

  1. Select 'DS Modules' in the left menu of the application, select the object / module you wish to search within
  2. Tap on the Search icon
  3. You will need to fill out as many fields as possible to locate the record (use the Operation 'Like', rather than 'Equals' unless you want an exact match).  View the list of records and identify its row id (Data source id)

We require: Rowid of the record and the module.  Also, if there is information in your data source for last mod date, that would be useful also (but not essential)

Step 3 - Check the history in DS Modules

When records are received / updated, we track its history in the Swift MEAP™ Server.  Please provide details of what has happened to the record since it was first delivered to us.

Check history in DS Modules

To identify how/when the record was first inserted to our database, please use the following function in the Swift MEAP™ server:

  1. Select 'DS Modules' in the left menu of the application, select the object / module you wish to search within
  2. Tap on the Search icon and enter the row id of the record you want to view the history of, select search
  3. Some servers will display a 'History' icon  in the right column, next to the record, if this is available, please select 'History' icon and save all details, we want to know the details of the insert date/time (and description) and any updates to the record (what changed and when).
  4. If the 'History' icon is not displayed, please view the details, we will need Created date, updated date and who has the record (users are listed at the bottom of the page)

We require: Record History (from DS Modules) or created date, updated date and details of who has the record

Step 4 - Check delivery to user in Handheld Data

We store details of when a record is delivered to users and when it was last updated for users in Handheld Data.  This table should provide details of when your user specifically first received the record (DS modules shows when the record was added to the server, but it could be for a different user).

Check delivery to user in Handheld Data

To identify how and when the record was sent to your user, please use the following function in the Swift MEAP™ server:

  1. Select 'Handheld Data' in the left menu of the application, selec the object / module you wish to search within
  2. Tap on the Search icon and search for the record using PIN (from Step 1) and Data Source Id (row id from Step 2)
  3. This should display your users email address and the row id of the record.  Please make a note of the operation, created date and updated date

We require: Created date, updated date and operation (whether it was getupdates / auto / manual load) for the record in question

Step 5 - Gather logs for the load

If the information above does not provide enough information (we know how the record was sent to your user and when), we will require logs to investigate (DEBUG logs usually required).

Gather logs for the load

Now that we have details of the user, the record, when it was delivered and how (via getupdates or init load) we need logs and a config to investigate distribution.  Please log into the Swift MEAP™ Server.

  1. Select 'Utility' in the left menu, then select 'Show Log'
  2. When logs are stored, they are stored using the date / time of the last event in the logs.  We usually create log files every hour that the server is operational. 
  3. In step 4 (Handheld Data) we identified the Created Date for the record (when it was first sent to your user).  We need logs for this period.  Navigate the list, if the Created Date of your record was 15th August at 9:30pm, we need the first log saved on the 15th August AFTER 9:30pm.  Please check am/pm values carefully.  If you are unsure, send the logs before / after this time.  Select 'Download' to download a file

NOTE: In split port servers, we usually only require Console logs (logs prefixed with C_) for this, but please also include Service logs (logs prefixed with S_)

We require: Logs for when your user first received the record to track distribution.

Step 6 - Save your configuration

We now have the logs and record details, we need to check whether your rules are configured correctly.

Saving server configuration

To save your configuration, log into the Swift MEAP™ server.

  1. Select 'Utility' and then 'Configuration tool'
  2. Enter your MySql password / username - NOTE: This is not the server login, this is the MySQL login
  3. Select 'Generate Scripts'
  4. A popup will be displayed asking if you wish to save the file, choose a location

Final step - submit information to support

Now that all information has been collated, investigation can begin to identify whether there is a data issue or configuration issue which leads to records routing incorrectly.  Please raise a support ticket and include:

Information required by support

The following information is required to investigate routing issues with data - all information can be obtained using the steps above.

  1. User: User, PIN, Field Value, Created date, Cad received on and device.
  2. Record: Rowid and module name (last mod date if possible from Data Source)
  3. DS Modules: Record History (from DS Modules) or created date, updated date and details of who has the record
  4. Handheld Data: Created date, updated date and operation (whether it was getupdates / auto / manual load) for the record in question
  5. Logs
  6. Config

Please check that all information is available before contacting support.  We can help to obtain this information if you are having difficulty.  It is usually necessary to interrogate the logs to identify why your user was sent the record in question.