Skip to Content
Author's profile photo David Clavey

Agentry notes on Modifications

Notes on making modifications to Agentry

Notes on making modifcations to Agentry and some estimates on how hard in man hours each operation might be to the following area’s – DT (Data Tables), CT Complex Tables, Exchange Fetch, Trasaction Logic, Data.

1. Data Tables (DT)

– You could be asked to filter out some values from the data table. i.e. Filter Data and download it into an application table. Note: Data Tables should be used sparingly, recomend less than 100 actual records of rarely changing data.

Scenario’s on the Data Tables:

1.1. A Filter is available within the config portal MDO.

  • Check the datatable for DT and see if a filter has already been defined.
  • Specify a new filter value in MBO for the table
  • How do you find the MDO for the datatable ? Look for parameter group DT-MDOID
Estimated effort: 2 hours per filter.

1.2. Filter is not available within the config portal MDO

  • Copy the existing class handler, making a new Z copy.
  • Goto the application config and look for parameters, search for DT_MDOID and find the class handler for that entry. With SAP class handler copy it to Z. Then change the Get method where the filter has been defined.
  • Change the GET_DATA_TABLE method.
  • Copy the MDO, point it to the new class and specify the filter values.
  • Change the mobile application parameter value for the group DT_MDOID with the parameter name –
ABAP Steps
To add a new filter in the config.
  • Copy the MBO class to a new Z class.
  • In the Z copy class change the method GET_DATA_FILTER_LIST which contains a list of filter fields.
  • Copy another class that already has a filter defined as a template to the code you need to add.
For example DT-Data Table | ‘SWM51_BUSINESS_AREA’ | Datafilter TAB – Look at Data Object filter role definition.
  • Change the value accordingly for your new dll.
  • Edit your new Z class method GET_DATA to apply suitable ABAP SQL Statements, altered to include the filter field names and their values.
  • Once activated (ABAP Class), change the DT config for the application, pointing to the new class. This in effect then uses the new filter value added to the MDO calling the Z class method GET_DATA_FILTER_LIST. The filter values can be supplied in the DT config.
Estimated effort: 6 hours per filter.

1.3. Creating a Data Table from new.

  • If the class handler already exists use it.
  • If not create a new class handler. This is either a copy of an existing one with filter logic already includeded in it. Or create a new class (ABAP) with a
  • super class reference to /SYCLO/DTHANDLER and then add suitable methods.
  • Create the MDO
  • Set the new DT-MDOID for the new class and table in the two parameter settings.
  • Create the DT in Agentry, link to an existing Java class. No new Java is needed here. Remember Table for the GUID in SAP function modules or classes is /SYCLO/MDW00 (Use SE16)

Estimated effort: 15 hours per Data Table.


2. Complex Tables (CT)


2.1. Adding a new field to a complex table (CT)

  • It could exist in the BAPI structure or it does not exist i.e. it comes from a custom Z table.
  • Change the backend logic.
  • Agentry definitions also need changing.
  • Java classes field matching also need changing.
Estimated effort: 4 hours per Field.

2.2 Need to add a new filter.

  • Is the new filter exposed in the config panel? You can just change it on the config portal panel.
  • If filter is not exposed on the config portal panel, then see my notes 1.1/1.2.
Estimated effort: 6 hours per Filter.

2.3. Create a new Complex table (CT)

  • Is there a class handler for it already ? Or does the class handler not exist.
  • Look at the config panel parameter CT_BAPI_WRAPPER for the existing Table name and bapi.wrapper.
  • Get the Bapi wrapper assignment CT_MDOID for the CT table name.
  • Then go to the MDO for the wrapper class and see if a filter exists.
  • If the filter does exist then set the appropriate values.
  • If the filter does not exist then copy the wrapper class in SAP.
  • Copy the code for a filter method from another class
  • Change the get method etc then see my notes 1.2. It is possible and recommended to setup dummy SQL data first to test this new method.
#Note# the SQL for the get method requires functional consulting understanding.
  • Create the new MDO using the config Portal.
  • Create the Bapi wrapper assignement, using the config portal, to the new ZCL wrapper. (SAP Class)
  • Extend the POJO to include new field mapping or create a new POJO class using Syclo super class
  • Change the CL_SAPOBJECT parameter to point to the POJO.
  • Using eclipse Java perspective, publish the modified POJO’s by using export to a .jar file that must be added to the agentry.ini file the first time the project is created.
  • Stop and re-start the Agentry server.
Estimated effort: 30 hours per Complex Table.

3. Exchange – New, Changes and Deletes

  • Using Get_new_records, Get_change_records and Get_Delete_records.
  • The insertions of the enhancements into the standard SAP ECC BAPI code can be quite messy because we are trying to detect the new/change and deletions.
  • No automatic reset of the exchange table program is available in the product. Companies implementing Agentry tend to build one of their own by modifying the BAPI code.
  • Filtering can be implmented by modifying the BAPI code itself that feeds the exchange.


Estimated effort: 30 hours per Exchange.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi David,

      Very nice posting.

      Thanks a lot for sharing.



      Author's profile photo Manish Meshram
      Manish Meshram

      Hello David,

      Can you explain what is Data Table , Complex table , Exchange Objects , DO and Its purpose

      Author's profile photo Michael Appleby
      Michael Appleby

      Hi Manish,

      Wow, that is an open ended question.  Let me give it a quick shot.  There are essentially 3 data structures (Objects, Complex Tables, and Data Tables) which store information on a mobile device for an Agentry based application.  In addition there are Transactions which store changes to the Objects. 

      Data Tables (DT) are simple two column tables which usually have a hundred or fewer rows.  The two columns are an ID and data, aka Key and Description or similar.  Synchronization consists of deleting and completely refreshing the contents.  In other words, once a change has been detected in the backend, the whole table is refreshed.  An example is a Plant DT which has a Plant number and a description containing a name and perhaps city, state or other location info.

      Complex Tables (CT) typically have more than 2 columns and can have thousands of rows.  They can, depending on mostly on size, have change detection trigger "delta updates" or updates to only the rows for which changes have occurred.  Complex Tables also have one or more indices (indexes) to facilitate searches/filtering.  The update process occurs during a Transmit (Agentry speak for synchronization) and involves the use of Exchange tables in the backend (Agentry Addon for ERP/CRM, database tables in an SQL based backend, etc.).   An example of a CT would be a Product (Material Master) table with indices perhaps on Plant or Supplier.

      Both DT and CT are non-editable by the users (by long standing convention rather than platform limitation). 

      Objects contain records which are intended to be CRUD'ed.  Fetches do the R'ing. .  Transactions do the CUD'ing.  Sales Orders, Work Orders, Notifications, etc. would all be Objects on the mobile device.  Transactions and Objects have a relationship which is the main focus of all Agentry applications.  During a Transmit (synchronization), the Transactions pass changes affecting Objects to the Agentry Server which passes those changes to the backend (which I will assume is SAP ERP for this explanation).  The backend processes the Transaction, CUD's are performed on the underlying back end DO (Data Objects), those changes are compared to the records in the Exchange Tables in the Agentry Addon, relevant Object (on the mobile device) changes are recorded to be passed back once the CUD process is complete.  Once the backend processing is complete for the active Transaction, the updates are passed back to the Agentry Server, which passes them back to the mobile device which then updates the Object table and completes (deletes) the Transaction processing.

      One thing to note is that at no time is there data on the Agentry Server which needs to be synchronized with either the device or the backend.  In the Transmit process, the Agentry Server acts solely as a pass through (traffic cop, if you will) of the Transactions and other backend processing.

      Hope this helps and this is a simple explanation and basic functions.  There are many more features that I am ignoring right now, like Push and Background Processing.  Check the help documents for deeper explanations of how Agentry and its applications work.

      Cheers, Mike

      Author's profile photo Manish Meshram
      Manish Meshram

      Hello Mike,

      Thanks a ton to put this together.

      Does that means DT can be used for master data & CT for transaction tables.

      How conflict resolution is managed on SAP side, i mean 2 users are updating 1 object at same time with different information, then user on SAP decide who wins,  i know this can be managed using exchange objects but how?.

      I would appreciate if you can post a blog to define how DT, CT , Objects , Transactions , fetches, Actions ,steps, service events & Pushed are define for atleast one scenario(say work order) using Agentry Editor.



      Author's profile photo Michael Appleby
      Michael Appleby

      Hi Manish,

      What I can tell you is that in very rough terms is that Master Data and Configuration Data are presented by Data Tables and Complex Tables with the differences based primarily on size and number of columns.  Objects contain the records which are created, updated, or deleted by Transactions with Objects and Transactions being terms within the Agentry context. 

      For the other questions you have, please see the documents being posted by in the SAP For Mobile Community.  There is a wealth of information contained in those documents.  I am familiar with most of them so if you have more questions, please post them in new threads as our continuing discussion has wandered a bit from this one's original topic.

      Thanks, Mike

      SAP Rapid Innovation Group - RIG

      Author's profile photo Former Member
      Former Member

      Data Tables:

      A data table definition defines a set of records stored on the Client. Each record consists of two fields containing a key and value. A data table is intended to contain a small number of records (less than 100) that may be displayed to users in drop-down lists and other uses. A data table is defined at the application level and is available to all modules of the application. Its structure also defines how its data is synchronized.

      The intended purpose of a data table is to provide short lists of records that can be created quickly and with little overhead related to maintaining the data. A data table has no built-in search support and if searching is necessary it is performed row-by-row (e.g., no binary or other search algorithms are employed) as the order of the data is not guaranteed within the data table definition.

      Complex Tables:

      The complex table definition defines a table of records containing multiple fields stored on the Agentry Client in a structured and searchable format. A complex table can contain large amounts of data with records numbering in the thousands. Included in the complex table are the fields for its records and indexes on fields to provide search functionality and structure to the overall data in the table. The complex table definition also defines how its data is synchronized.

      The fields and indexes of a complex table define the structure of the records. A complex table must have a minimum of one index definition, which is the primary index. This index is defined for the field containing the unique identifier for each record. This field and index are then used during synchronization to identify records for addition, replacement, or removal.

      The above information is from the Agentry Language Reference Guide.

      Stephen Streeter

      Author's profile photo Vipin Nagpal
      Vipin Nagpal

      Hi Manish,

      I am also looking for work order scenario details. If you come across such details. please notify me.


      Author's profile photo Vipin Nagpal
      Vipin Nagpal

      Hi David, It would be great if u may able to add some screen shots or video recording with use cases details like when do we need to make changes in filter conditions.

      I am new to Syclo Area, Sorry if i would have requested too much.


      Author's profile photo Joyce Billquist
      Joyce Billquist

      Hi David. I am new to Agentry and Rounds Manager. What is the best practice for making changes to MDO config?  For example, I need to point the Data Object Handler for a Complex Table to a Z class.  Should I first make a copy of the MDO for the Complex Table and make the changes in the copy?

      Thank you.

      Author's profile photo David Clavey
      David Clavey
      Blog Post Author

      I suggest you go on the courses, you need the background info first to make such a decision.