Skip to content

Troubleshooting Grouped Push

Groued Push is used for some few entities that contains a large set of data. You do not want to push out all of that data to all devices for all users. What you want to do is to minimize the transactions of data that is pushed out to the users devices. Grouped Push Entities are used to synchronize the same set of data to a group of Users.

Introduction

In order for Grouped push to work a System Defined User is created at installation time. The name of that user is IFS<App name> e.g. IFSSERVICEAPP. That User needs to be granted the relevant information and what that is depends on the application. As an example Service Engineer app requires that companies and sites are granted to the user in order to get the data to be pushed out to the device(s). The User is usually Inactive, but that is as it should be.

Further refinement of data that should be pushed out to the App/User/Entity is defined in Grouped Push User Filter, which is generating a list of Filters per Entity and per User that groups the Users used in a Grouped Push process.

Grouped Push Synchronization Process

The Grouped Push Synchronization Process writes all logging information to Grouped Push Transaction Traces. The trace information here consists of data related to the Initialization of Grouped Push Datasets, the maintenance of Grouped Push Datasets and the main Grouped Push Database Process. The logging level for each of these can be changed via the Application Parameters INIT_TRACE_LEVEL, TRIGGER_TRACE_LEVEL and BATCH_TRACE_LEVEL.

Note 1: Trace levels INFO, TRACE and DEBUG may generate huge number of records in Grouped Push Transaction Traces. It is therefore recommended to not leave these parameter set to any value other than STAT or WARNING for longer than a few hours.

In addition to the Grouped Push Transaction Traces the Grouped Push Transaction Queue will also report errors generating or maintaining the Grouped Push Datasets. The Error information will be shown directly in the Queue record.

The Grouped Push Filter Map shows the WHERE statements used within the Grouped Push Synchronization Process to fetch the Grouped Push Datasets for the User. These WHERE statements can be used to determine what data should have been synchronized to the mobile app user. They also indicate if the mobile app user has permission set granting to synchronize the entity data. If the details shown in Grouped Push Filter Map do not match with what is expected then it could be that the mobile app cache has not been refreshed. This is possible via the Refresh Server Cache process.

There are Application Defined Events named GROUPED_PUSH_FAILED and GROUPED_PUSH_BACK_TO_NORMAL which can be configured to alert administrators/end users when issues arise in the Grouped Push process. These events include a MESSAGE field which states either "Group Push Synchronization failed" or "Group Push Synchronization back to normal" and a TASK field which states the sub-process of INIT, REFRESH or PUBLISH.

Troubleshooting

In order to troubleshoot why you do not get records pushed to the users device or do not get the right amount of records pushed to the user device, you need to investigate the following:

Check if the database has been cloned for this environment?

If the database has been replaced with a clone (say replaced Test with a copy of Live) Grouped Push data will be invalid in the replaced database. Do the following actions to make Grouped Push to work again:

  1. Run a script as admin User that calls "FNDMOB_DEPLOYMENT_SYS.Post_Db_Clone_Cleanup" (this procedure has no parameters).
  2. Re-initialize all Apps to ensure they are synchronizing data from the replaced database.

This step does not need to be done if you are sure that the database you are running at is not a cloned database or if you have already performed the above for a cloned database.

Check if the system defined User for Grouped Push has been granted the right information?

Make sure that the System Defined User for Grouped Push has been granted the relevant information, for Service Engineer app it is companies and sites that are needed to push data. For other apps it might be something else. Information about that needs to be provided by the owner of the App.

Check if the Grouped Push User Filter have been set up correctly?

If you do not get the correct number of records down the the end User's device, please check the following in the Grouped Push Filter Map for the App/User/Entity.

  • Is the column Has Permission Set Grant = Yes
  • Is the column for Has User Filter Granted =Filtered?
  • Is the Where Condition showing the correct sites
  • Is the Permission Set Where Condition showing the correct sites.
  • Is the User Filter Where condition showing the correct sites.

If the column Has Permission Set Grant is No or if the column Has User Filter Granted is Blocked you will not get any records for the App/User/Device. You need to check what the definition is for the User Filter in the tabUser Filter Columns in Grouped Push User Filter. Furthermore you need to check what filter conditions exists for the view name. Does the view have a filter that prevents the records to be filtered.

Check in more details using traces.

If the above has not helped and you still have problems to synchronize the Grouped Push then you need to set on traces. This is done in the Application Parameters.

You should start with setting the trace levels to INFO for the following Application Parameters:

  • INIT_TRACE_LEVEL
  • TRIGGER_TRACE_LEVEL
  • BATCH_TRACE_LEVEL.

Then check what information you get in Grouped Push Transaction Traces and investigate why it still doesn't work..

Note 1: Trace levels INFO, TRACE and DEBUG may generate huge number of records in Grouped Push Transaction Traces. It is therefore recommended to not leave these parameter set to any value other than STAT or WARNING for longer than a few hours.