Information: Controlling Complex Table Data and Delete queries to run in every transmit for Agentry

Are you a new designer or a season veteran in Agentry?

If yes, you probably started to learn how to create complex tables while attending the MOB-300 (Agentry Essentials) class.

The class is based on SQL examples on creating complex tables, fetches and transactions. If you are season veteran then you probably just need to get some refreshers on some known topics.

The purpose of a complex table is to store X amount of records in the mobile device that requires rapid searches for your mobile application to be used in your logic or transactions.

As a new mobile designer or season veteran, one of the stories or requirements that you may get from the company you are building the mobility solutions for is how to control the data that is downloaded to the mobile device.

The questions you may get are as follows:

• Do you expect the mobility user to always get the most up to date records for each transmit?
• Do you only need to download delta updates on each transmit?
• Do you just get the records based on a fetch (on-demand)?
• What if the user has 2 million records but is using a cellular network with low signals and the transmission is too long?

Some of those questions above may lead you to ask how to control data being loaded or deleted in Agentry and especially data in SQL backend due to overhead/cost of the transmit.

This blog will concentrate on SQL Backend and controlling the Complex Table Data and Delete Queries.

A Complex Table Data query is in charge of getting the data from the backend to store newly initialized data (rebuild) or updated data in the complex table while the Delete queries is in charge of removing the record from the complex table.

The first thing a new designer needs to know is that you need to setup a transmission type to connect the Agentry client to the Agentry Server. In this example, we are using the Angel connection. This transmit configuration setting is to setup most WiFi and LAN connection or default connection for transmission. In the picture below, the user is allowed to select or deselect the option to check for Complex Tables. It is mandatory to enable it to run the Data and Delete queries in every transmit unless you designed your application to be more strategic or tied to types of transmission (discussed below).

Why is this option available?

The Agentry software gives the user the control to enable when and when not to download the table data based on business rules. A perfect example of this is when the user is on the field and is using GPRS then to not allow the user to download multi-million rows of data until the user is using the LAN.  The expectation here is that the user has several settings available to be chosen as designed by the user/designer (ex: Angel, GPRS, WiFi and others). One technique a user can do to switch from one selection to another is during transmit to press cancel right away. This enables the drop down selection to be active so that the user can select which one to use (i.e. GPRS, WiFi and others) provided that you have more than 1 selection available (based on your design – seen under the transmit configuration tab).

What will happen if you turn off the option above (Check Complex Tables)?

Then you may want to look at this KB article that explains the expectation on what occurs (problems) and what options are available to you in the Agentry Editor.

https://service.sap.com/sap/support/notes/1978261 – Complex Table Data or Delete query does not run in every transmission – Agentry (you will need your S number to check it out and you may bookmark it). Check KBA symptoms as what is expected.

The article above is a good Knowledge Base Article (KBA) to learn what to setup if you are designing a complex table. You may click on the link and save it for reference as it will also explain what happens if you select the other Agentry options “Check Complex Tables and User Request: Allow user to check for table updates” like the picture below.

The 2 pictures above are available in the Agentry editor and it may affect other backend types but this blog concentrates on SQL backend.

The MOB-300 class will discussed creating the Data and Deleted queries in detail and the SAP Work Manager for Maximo product has real examples (if you have license for it you may download it for reference). I normally recommend to the customer to get one copy of the SAP Work Manager for Maximo if they are designing a SQL backend from scratch to get all reference or examples on how one can do a complex table, fetch, transaction and others. They can also attend the MOB-320 class (they will give you a copy and explain each component, properties, complex table and others in detail). The MOB-320 class is perfect for mobility designers who specialize in SQL or Oracle backend and Java type of application while the MOB-310 is perfect for Java and SAP backend.

Additional comments:

– The products designed under Agentry like Work Manager for SAP uses Java backend (it does not have Data or Delete query) and most of the control are in the SAP Agentry ConfigPanel (or JavaBE.ini for older versions of Work Manager).

– The products designed under Agentry like Work Manager for IBM Maximo uses SQL backend and this blog relates to it (it has Data or Delete Query).

To readers: If you like this type of information please do like and/or bookmark this article and all articles reference herein for us to validate its importance to the user community and for us to create more.

Regards,

Mark Pe

AGS Senior Product Support Engineer