Skip to Content

Branding Agentry Windows Client with Pre-built Agentry.DB Database


We are trying to build a branded windows client that can carry an Agentry.DB with it. This is very much required as we are bringing in huge amount of data in our complex tables. We would like to fetch the data once, and distribute the branded client within our user community so that we can save on the time required to sync the application for the first time. Otherwise, it can take us anywhere between 10-15 mins to load the application for the first time.

We are trying to brand/customize a windows agentry client (70.15.2) by including an already exported Agentry.DB file for SAP Work Manager 6.4.

The SAP Work Manager 6.4 application has been hosted on an SMP 3.0 Server (Development version).

A) Steps to export the Agentry.DB file

  • Set the Database unencrypted in Agentry Configuration.
  • Run the standard windows client, complete the sync and export the .DB file from the Client.
  • The Agentry.DB file was exported by User "USER01"

B) Steps to Brand the Client

Attached the file titled "Agentry Client Branding Instructions.docx" with this message.

C) Other settings in Agentry Configuration on theApplication (Agentry Layer) side

  • 1) Complex tables have been set to NOT reload when the user changes
  • 2) Data Tables have been set to NOT reload when the User changes.
  • 3) Complex tables are set to 'Check once per week' in application settings
  • 4) Data tables are set to 'check in every transmission' in application settings

D) Other settings in the Config panel on the back-end side

  • 1) TABLE_CHECK parameter for each complex table set to 0
  • 2) TABLE_REFRESH parameter set to 168 ( 1 week) setting

E) Expected Functionality After branding the Client and coupling it with the pre-built database (Agentry.DB)

it is expected that the Branded Client will no longer sync all the required complex table's data from the back-end. It is expected to fetch the required data from the offline database 'Agentry.DB'. As per the maintained configuration, it should check for the updates to the data in complex table only ONCE per week.

F) Non-standard configurations and modifications

  • 1) there have been no changes to the definitions of the complex tables.
  • 2) No modifications to the Java POJO classes with respect to forcing the complex tables to RELOAD on every execution (explicit enhancement of the willRebuildTable() method)

G) Issues faced:

1) When any other user except for the user who exported the Agentry.DB file (in this case - USER01) - tries to launch the branded client, and logs in using his credentials - The Client tries to sync data for all complex tables. The client doesn't refer to the offline database (agentry.DB) and tries to fetch everything from the back-end. This is not in-line with the maintained setting that Complex tables will not be forced to reload when the User changes.

2) When the same user (USER01 in this case) tries to launch the branded Client - the Client doesn't load the complex tables from the back-end. Instead, it reads the data from the locally included Agentry.DB file. After reading complex tables and UI definitions - it tries to fetch the transactional data - in this case: The workorders, notifications etc.

Let's assume that the offline database (Agentry.DB) had a total of 4 workorders for the user. We create one more workorder for the same user in the back-end. When the Client tries to fetch the workorders, it is only bringing the workorders contained by the offline database. It DOESN'T read the newer workorder from the back-end. This is not in-line with the standard configuration where the Client SHOULD check for data tables in every transmission.

H) Things we have tried so far:

1) On finding out that the complex table data still has a dependency on the User who initially exported the Agentry.DB - I removed the User's encrypted details from the Agentry.DB file. I opened the Agentry.DB file in a third-party DB file browser, checked the table called 'exportinfo'. Removed the values stored against AgentryUserSalt and AgentryUserHash.

This forced the Agentry Client to not consider the previously logged in User from the Agentry.DB file. This solution also worked for us when we switch the User. Now the User USER02 can log-in and fetch the data in complex tables without sycing with the back-end.

However, this solution created two more issues:

i) The offline sync is either a hit or miss. I observed it to work fine for first 3-4 days without going back to the Back-end for complex table data. Sometimes, on some machines, it just doesn't work. It definitely stops working after 3-4 days on all of our machines. which means it goes back to the back-end to sync the complex tables.

This is still NOT in-line with the maintained configuration of "Checking once per week" for the complex tables.

ii) The issues of missing workorders (issues#2 in section G) persists. It cannot fetch the workorders designated for the new user (USER02), and instead reads the workorders exported for the earlier user (USER01).

2) Played around with the settings for TABLE_CHECK and TABLE_REFRESH parameter but data fetch from back-end remained erratic. Branded Agentry Client would randomly fetch the complex table data.

3) Edited the lastUpdate time for complex tables in the Agentry.DB file. Set it to NULL. This didn't help.

We would want to make sure that the read from offline database (agentry.DB) are consistent during the initial sync. However, the sync behavior is extremely erratic and confusing.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Aug 28, 2017 at 05:54 PM


    Dear experts,

    Appreciate your thoughts on this particular requirement.

    Also, the steps I followed to create a Branded client are attached in the word document.

    Agentry Client Branding Instructions

    Add comment
    10|10000 characters needed characters exceeded

  • Aug 29, 2017 at 12:21 AM

    Following your steps in the attached word doc, on step 8 your should not receive ANY errors and the result will be the Branded_Agentry_ClientDotNET.exe. Also, if you don't need to modify the installer screens at all you can skip copying the AgentryClientDonNET_Branding.nsi and use this file directly in the command as /DBranding=AgentryClientDonNET_Branding.nsi instead of YourCopy.nsi.

    One thing to note which might be the source of your errors during the makensis command. Be sure you are running version 2.51 of NSIS and not the v3.x version.

    Of course none of this directly solves your problem but I wanted to pass it along.


    Add comment
    10|10000 characters needed characters exceeded

    • Hello Bill,

      Thank you very much for your message.

      Yes, I was using 3.0+ version for NSIS to build our installer.I will revert to 2.51 and give it a try again.

      Also, do you have any thoughts about the offline Agentry.DB and a branded Client using this file as the database?

      I tried to list out the issues as much detailed as possible, but if you need any more information, Please let me know.

      For starters, we are unable to understand why would the Agentry Server force the Client to rebuild the complex table when the data has been stored locally and there are no delta changes to the Master data?

      Is this even a supported functionality by the Agentry framework?

      If yes, is there any relevant documentation I could refer to?

      Thanks a lot for your time!

  • Jun 28, 2018 at 02:35 PM

    Arihant Kumar Kothari - Could you provide me the documentation. It seems the link is no more acitve.

    Add comment
    10|10000 characters needed characters exceeded