Logging changes made in Designer
From Designer 7.8, you can have changes (including deleted and added properties) to elements of the adlib.pbk, .inf and .fmt configuration files logged in log files automatically, so that administrators can keep track of who changed which application property and when, or to track down the cause of errors due to some misconfiguration.
Entries in these log files will contain as much context information as possible to identify what has changed, when it was changed and who changed it. Below is an example of a log entry on a change of a role for a datasource in the application, providing the date and time of the change, the name of the user responsible, the main object, the relevant object property, the old value and the new value of the property:
12/01/2022 15:32:14|erik|application > datasource 'Catalogue' > Access|Role changed|old: archive|new: archive+library
Each log entry is written to a log file specific to the modified configuration file when that file is saved by Designer. There will be one change log file per modified configuration file per day, the name of the log file will include the name of the file that was changed and the current date in ISO format. So for the adlib.pbk the log file name will be something like adlib.pbk2022-01-12.log, while for collect.inf it might be collect.inf2022-06-13.log and for a screen file named access_management.fmt it might be access_management.fmt2022-06-13.log. You can open such log files in any text editor.
Logging only works if you create a specific settings.xml configuration file and place it in the folder containing AxiellDesigner.exe. Designer will check for that file on startup of Designer (and only then). Example:
<settings>
<applications>
<application>
<name>Our production application</name>
<path>C:\Axiell\model 4.5.2 Live</path>
<log enabled="true">C:\Axiell\Designerprodlogs</log>
</application>
<application>
<name>Our test application</name>
<path>C:\Axiell\model 4.5.2 Test</path>
<log enabled="true">C:\Axiell\Designertestlogs</log>
</application>
<application>
<name>Our development application</name>
<path>S:\Axiell\model 4.5.2 Dev</path>
<log enabled="true">C:\Axiell\Designerdevlogs</log>
</application>
</applications>
</settings>
Here's how to best use this functionality:
1. | First decide IF you want changes made in Designer to be logged at all. The advantage can be that any application configuration errors that pop up after changes were made, can possibly be traced more easily using the Designer logs. A disadvantage might be that the logs provide a false sense of security because logging can be switched off easily by removing the settings.xml file temporarily or by using a Designer instance without that file. Placing Designer in a safe location which can only be accessed by selected application managers can remedy that, of course. |
2. | If logging is desirable, choose which Axiell environments to log. You'll maybe have a development, test and/or live/production environment. At first one may think that logging modifications in the live environment is enough, but you're better off logging the configuration changes in all your environments. This is because you may copy configuration files from environment to another at one point and also because when something goes wrong in your test or development environment, those logs come in handy too. |
3. | This logging functionality works from Designer version 7.8. An instance of Designer will log changes to configuration files if a proper settings.xml file is located in the folder that also contains AxiellDesigner.exe. This needs to be the case for every instance (copy) of Designer that you have and you shouldn't use copies of versions older than 7.8 once you start logging because older versions can't do the logging and a 7.8 (or higher) version of Designer won't do the logging without that file either. If you have instances of Designer on different servers, check that the paths in a copied settings.xml file are still accessible from those servers: UNC paths are not supported, but mapped drives and of course local paths are. The path of the root application folder opened in Designer should be identical to the path registered in the settings.xml file. Also note that even if you have a separate Designer instance per environment, it's worth including all environments in each settings.xml file so that if you accidentally use the Designer instance from one environment to edit another environment, the changes will still be logged. |
4. | In the settings.xml you can specify one or more <application> nodes: we do not mean Collections or Axiell applications or single .pbk's here: we are more thinking of an Axiell environment. Provide each environment section with a descriptive <name>: this name doesn't point to a folder or anything and is only used in this settings.xml file to identify a section easily. In an <application> node you further specify the <path> to the shared root folder for one or more Axiell applications within an Axiell environment, typically this is the path to the folder containing the Axiell \data, \screens, \adapls and Axiell application(s) (e.g. \xplus, \library etc.) subfolders: in other words, the folder one level up from \data. UNC paths are not supported, but mapped drives and of course local paths are. Underneath the path that you select, changes in .pbk's, .inf's and .fmt's in all subfolders will be logged: changes in adapls, text files, XSLT's and Word templates however, won't be logged. Per <application> node you have to specify a <log enabled="true"> path to a folder to contain the new log files. This doesn't need to be an existing folder, it will be created by Designer automatically if it doesn't exist yet. Best choose a different logging folder for each environment in a location where you're not likely to accidentally delete them. |