EN
Español
English
Português
    Tables with High and Lowest Traffic in AFLS


    • AFLS_WORKORDERS: This table stores the work orders in the system and contains the entire operation of the field work. It currently has different indexes to respond to the most popular searches in the application.
    • AFLS_ATTACHMENTS: This table contains the references of work order attachments, customer signatures and SLA attachments; It is not recommended to do any physical debugging as it can generate information integrity problems.
    • AFW_ADDITIONAL_FIELD_VALUE This table contains the values of the additional fields of all the concepts of Aranda FIELD SERVICE AFLS (Model, Orders, Services, Customers, Companies, Locations, Products, Web Users and Mobile Users).
    • AFW_USERS: This is the main table of users, this table concentrates customers, field specialists and web specialists. This table can be fed new users through the web console, integrations with Aranda SERVICE DESK ASDK, and synchronization from the LDAP active directory. This table should not be purged and its records should not be deleted.


    What are the most trafficked tables in AFLS, where records can be deleted?


    • AFLS_APP_LOG: This table only has insert operations for each request to create, edit, or delete system configuration settings; its objective is to record the log of operations on the configuration by answering the following criteria: Who made the operation? What concept is involved and what data? What data was used in the operation?
      Note: This table is for audit purposes and it is not recommended to delete your data; If you want to delete records from this table, use the script:
    DELETE 
FROM [BD_NAME].[dbo].[AFLS_APP_LOG]
WHERE alog_generate_date < '2020-01-01 00:00:00'o
    • AFLS_ASSIGMENT_ENGINE_REQUEST: This table houses the issues that are processed by the Mapping Engine service with their respective solution. This table is supported by an AFLS scheduled task, which deletes by default records older than 2 days.
      If you want to modify the deletion time, you must update the file:
      %ProgramFiles(x86%)\Aranda\Aranda Services\Aranda.AFLS.AssignmentEngineService.exe.config and look for the line:
    <add key="engine:daystoexpire" value="2" />
    • AFLS_LOCATIONS: This table groups the geo-referenced points that a specialist records during his work in the field. This table has quite a bit of INSERT operation, since the mobile application, during manual or automatic synchronizations of each specialist, records its location depending on the location accuracy setting (High Accuracy every 10 meters, Medium Accuracy every 30 meters, and Low Accuracy every 90 meters).
      Table AFLS_LOCATIONS is supported by a scheduled AFLS task which passes records older than 3 days to the AFLS_LOCATIONS_HISTORY table; The entire history of field specialists is stored here.
      This table tends to grow a lot, since the more specialists in the field and the greater the availability of hours and days of the week, the more points will be registered. This table can have a periodic physical erase from specific dates, using the following script:
    DELETE
FROM [BD_NAME].[dbo].[AFLS_LOCATIONS_HISTORY]
WHERE loct_date < ‘2020-01-01 00:00:00’
    • AFLS_REVIEWS: This table records the comments added by specialists, dispatchers, end users, and application monitors; as well as automatic comments generated by the system; These reviews help you see “the history” of a work order for changes.
      If you want to debug, it is recommended to check once a month and check if you want to run any debugging.
      Example deletion script:
    DELETE 
FROM [BD_NAME].[dbo].[AFLS_REVIEWS]
WHERE revi_date < '2020-01-01 00:00:00'
    • AFW_ALERT: This table saves the alerts that the system generates. For example: An order that did not start on time, an inventory product that is about to run out, a satisfaction survey with a low score, etc.; these alerts have 3 statuses (New, Reviewed, and Closed). Depending on the management of the tool, it can generate several alerts and in turn several records.
      A decision can be made to execute a physical deletion script for alerts that have been closed by dispatchers with an effective date since it has an index with the following keys (creation_date, status_id, category_id):
    DELETE
FROM [BD_NAME].[dbo].[AFW_ALERT]
WHERE status_id = 3 and creation_date < '2020-01-01 00:00:00'

    The impact of eliminating these alerts in a closed state is to lose track of their management, compared to the tool. For this reason, a deletion and its periodicity should be considered, if necessary.


    • AFLS_ALERT_ARCHIVES: Alerts from the table are moved to this table AFW_ALERT of orders that are already in closed or canceled status; these alerts have 3 statuses (New, Reviewed, and Closed). This process is done by a scheduled task that runs at midnight.
      You can make a decision to execute a physical deletion script for alerts that have been closed by dispatchers with an effective date:
    DELETE
FROM [BD_NAME].[dbo].[AFLS_ALERT_ARCHIVES]
WHERE StatusId = 3 and CreationDate < '2020-01-01 00:00:00'
    • AFW_ASSISTME_PREREGISTER This table groups the pre-registrations that are carried out from the AssistMe console when it has been enabled from the administration. Pre-registrations mean that end users have requested to enroll in AFLS from AssistMe, once the customer pre-registers, the system sends them an account notification email, to create them as a customer once they successfully validate their account.
      The growth of this table depends on the strategy when using this channel; It is possible that this table can grow by pre-registrations that are pending or have already been enabled. You can make the decision to delete pre-registrations that have not been confirmed for some time or those that have already been confirmed using the following script:
    DELETE
FROM [BD_NAME].[dbo].[AFW_ASSISTME_PREREGISTER]
WHERE actívate = 1
    • AFW_MAIL_HISTORY: The AFLS System sends emails to specialists, clients, monitors, etc. for different reasons. These emails are sent by a scheduled task and once they are sent satisfactorily they go to the AFW_MAIL_HISTORY table; This board can grow quite quickly; This history remains intact and a decision can be made under which criteria to delete the information.
      For example, if you want to delete information, you can use the following script:
    DELETE
FROM [BD_NAME].[dbo].[AFW_MAIL_HISTORY]
WHERE mahi_created < '2020-01-01 00:00:00'
    • AFW_WORKER_LOG: This table has the task execution log that the Aranda worker service runs. This log is used to identify that the tasks have been executed in the expected time and to validate their status by means of the work_success field (0: Failed, 1: Successful, 2: Pending execution and 3: In process).
      You can make a decision to delete with a certain periodicity the tasks that were successfully executed and leave those that present some type of error in case any support or adjustment is required.
    DELETE
FROM [BD_NAME].[dbo].[AFW_WORKER_LOG]
WHERE work_execution_date < '2020-01-01 00:00:00' AND work_success = 1