U4BW (Agresso) Clean up of Logs and Reports

Each time a report is run within Agresso it produces a log file and a report results file.  These files are stored on the Agresso Application server in the “Server Logging” folder and “Report Results” folder respectively.  They are also stored in the database in a table called ACRPRINTBLOB.  When a report or log file is viewed from “Maintenance of ordered reports” within the Agresso desktop client, the files are retrieved from the database.
Naturally the default setting within Agresso is to maintain these files on a permanent basis.  There are however very good routines within Agresso that will allow you to clear them down.  Please note however, before applying any of the following clean up routines, some organisations do want to keep these indefinitely and this may be for auditing purposes for example. However when auditing purposes as been cited for a reason for keeping reports, it is usually only a very small number of report types that fall into this category.
There are two methods within Agresso for implementing the clean up routines.  The first one is configured within the Agresso Management Console and allows you to specify that you would like to keep the file for a certain number of days.  Or alternatively that you would like to keep a particular number of each type of report.  These settings apply to both report result files and server logging files.
Agresso Blob Cleanup
The  above settings keep all report result and server logging files for 15 days.  The settings will also delete the files from the Agresso Application server which are in “Server Logging” and “Report Results”.
In the above screenshot, the “Mode” option which shows “Number of days” is  a drop down list.  As discussed, the other option available is to keep “Number of Report Orders”.
If you find you do have 10’s of Gigabytes of data in the ACRPRINTBLOB table, then it may be worth setting the value to a higher figure than 15 days and gradually reducing it down to the value you want.  This will just avoid a DELETE statement removing a huge amount of data in a single transaction which could cause the transaction log to grow a lot.
If you are in a situation where you would like to keep one or two specific types of report results files because they are perhaps a point in time snapshot of values.  Then it is possible to remove files on a more granular level.  This cannot be done in the above setup though, you need to use the AG57 report which is run from within the Agresso Desktop Client.  This report accepts parameters for types of particular reports or specific reports.  So if you have scheduled a PO01 report to run every 5 minutes and would like to clear down all of the PO01 reports, then the AG57 can be setup and scheduled to do this.  Or you could just remove all of the PO reports.
Report Deleting
The Ag57 allows a much more granular approach to removing unwanted files, but will take longer to setup than the global approach that is done within the AMC as obviously you would need to schedule one report for each set of report modules that you wanted to remove.
A common question that we are asked is that if the ACRPRINTBLOB table is over 50% the size of the total database.  Will clearing it down make the Agresso Client run twice as fast?  Afraid the answer to that would be No. It would however dramatically reduce the size of your database backups and this is particularly true when you are using SQL Server compressed backups.  The Image files are already compressed when they are stored in the database, so the backup compression has minimal effect on them.
The other advantage of clearing down unwanted report result and log files is that finding log files in the “Server Logging” folder is now manageable.  Faster backup and restore times of the database and reduced backup sizes also provide many advantages both in terms of cost and manageability.
If you are experiencing problems with having massive amounts of files in the “Server Logging” and “Report Results “directories, but are unable to implement either of the above two procedures.  Then as a workaround we would recommend scheduling a PowerShell script to archive the files from the directories and move them into a ZIP or RAR file.  We have implemented this before where once a month the job would run and move files older than a month to a compressed file.  So on the 1st of June the job would move all of the files with a timestamp of April into a single compressed file and so on.

U4BW (Agresso) Delete Logs and Reports over a certain age

In a recent article we covered how to remove old Server Logging and Report Results files.
Some of the feedback that we get around this subject is that there can be an uncertainty around whether all of the files should be deleted from both the database and the U4BW Application Server.
However, having several hundred thousand files in the U4BW Server Logging directory can be an issue when you try to look at any of the files, as File Explorer can take considerable time to show and sort the files.
As an alternative to using the in built U4BW options, it may be a case of leaving the files in the database, but removing them from the Application Server.  Rather than a global delete, it may be preferable to remove files that over a certain number of days old – 30 days for example.
Although it is possible to do this manually it is easier to do it with a Powershell command which can then be scheduled to run once a month.
Before running the command below you will need to edit three variables and these tell the script which directory the files are located in and how many days you want to keep.
Please note, the following code is not supported and should be verified in a non-production environment before running in production.

# Edit these variables
#Location of the Server Logging Directory
$ServerLogging = "C:Program FilesUNIT4 Business World On! (v7)Data Filesabwt05Server Logging"
#Location of the Report Results Directory
$ReportResults = "C:Program FilesUNIT4 Business World On! (v7)Data Filesabwt05Report Results"
#How many days do you want to keep
$Daysback = "30"
# End of editable variables
$CurrentDate = Get-Date
$DatetoDelete = $CurrentDate.AddDays(-$Daysback)
$ServerLoggingBefore = (get-childitem $ServerLogging).Count
$ReportResultsBefore = (get-childitem $ReportResults).Count
$now = Get-Date
"Starting to delete Server Logging " + $now
Get-ChildItem $ServerLogging | Where-Object { $_.LastWriteTime -lt $DatetoDelete } | Remove-Item
"Allowing system to catch up for 1 minute..."
Start-Sleep 60
$now = Get-Date
"Starting to delete Report Results " + $now
Get-ChildItem $ReportResults | Where-Object { $_.LastWriteTime -lt $DatetoDelete } | Remove-Item
$ServerLoggingAfter = (get-childitem $ServerLogging).Count
$ReportResultsAfter = (get-childitem $ReportResults).Count
$ServerLoggingDeleted = $ServerLoggingBefore - $ServerLoggingAfter
$ReportResultsDeleted = $ReportResultsBefore - $ReportResultsAfter
"Files before delete = " + $ServerLoggingBefore
"Files after delete = " + $ServerLoggingAfter
"Number of files deleted = " + $ServerLoggingDeleted
"Files before delete = " + $ReportResultsBefore
"Files after delete = " + $ReportResultsAfter
"Number of files deleted = " + $ReportResultsDeleted


Welcome to our new team member Bobby Balmer

Intersect Consulting would like to welcome on-board the newest member of our team Bobby Balmer.  Bobby has joined the company as a Junior DBA and after only one week with us, Bobby is already adding value to the team and the Company.  Bobby is a bright guy with great ideas and loads of initiative. We are all looking forward to working with him and wish him every success with Intersect Consulting.

Connect with Bobby on LinkedIn


U4BW Supported Operating System & SQL Server Versions

U4BW – Windows and SQL Server Versions

UNIT4 Business World (Agresso) is now supported on Windows Server 2016 and SQL Server 2016 which can offer enhanced performance, security and high availability features such as SQL Server Availability Groups.

SQL Server High Availability Groups  were first introduced in SQL Server 2012 as an Enterprise Feature. In SQL Server 2016 Standard Edition, Basic Availability Groups are now available.

Basic Availability Groups are a cut-down version of the Enterprise offering. They do however fit quite well with the U4BW setup and can be used to provide a very good High Availability / Disaster Recovery setup for a relatively low cost.

The setup can be:-

  • Both servers on-premise
  • Both servers cloud based
  • Primary server on-premise and secondary server cloud based (Hybrid Cloud)

In each setup there are advantages and disadvantages. But each one offers a great solution compared to a single server.

The following table shows which versions of U4BW are supported on Windows Server 2016 and SQL Server 2016. (Please note, SQL Server 2016 doesn’t need Windows Server 2016 and will run on Windows Server 2012 R2.)

U4BW Version SQL Server 2016 Windows Server 2016
Milestone 5 Yes Requires UPDATE05
Milestone 6 Yes Requires UDPATE03
Milestone 7 Yes Yes