SLM Application Maintenance
SLM application maintenance gives IT administrators access to logs and configuration information that can help identify application errors, warnings and other events recorded by Safety Lifecycle Manager. Reviewing these records is an important part of investigating application behaviour and maintaining the SLM environment.
SLM records different types of information at the web server and application levels. IIS W3C logs provide records of web server activity, while SLM PHP logs capture application events, errors and warnings generated during execution. Administrators can use these sources together when troubleshooting issues.
This guide covers the main SLM application maintenance tasks demonstrated in the training: accessing and configuring IIS W3C logs, reviewing SLM PHP logs, and updating SLM database-user passwords.
SLM Application Maintenance and Log Files
SLM application maintenance involves understanding where different types of system information are recorded and which source is most useful when investigating a particular problem.
The application platform writes events to logs that can include errors, warnings and informational messages. The training focuses on two primary logging sources:
- IIS W3C web server logs
- SLM PHP application logs
These sources provide different views of application activity. W3C logs record web server requests and responses, while PHP logs provide information generated during execution of the SLM application.
Administrators responsible for the wider SLM infrastructure should also be familiar with the SLM On-Premise Hardware and Software Requirements because application maintenance takes place within the wider web, application and database environment.
Using IIS W3C Logs for SLM Troubleshooting
W3C log files in Internet Information Services provide detailed records of web server activity. Their standardized text-based structure makes them suitable for reviewing requests manually or using compatible log-analysis tools.
Within an SLM environment, these logs can help administrators investigate web activity associated with the application. Typical W3C log information can include:
- Date and time
- Client IP address
- HTTP request method
- Requested URI
- Server response status code
- Client HTTP protocol version
When activity occurs within SLM, the associated web requests can therefore be recorded by IIS and made available for subsequent investigation.
Microsoft documents W3C as a text-based IIS logging format and provides configuration options for the log directory, recorded fields and log-file rollover. Administrators who need more detail about the underlying IIS functionality can refer to Microsoft’s W3C logging documentation.
Configuring and Accessing W3C Log Files
SLM application maintenance may require an administrator to inspect or adjust the IIS logging configuration for the site hosting the application.
As demonstrated in the training, administrators can access the configuration through IIS Manager by selecting the site being managed and opening its Logging feature.
From the IIS logging configuration, administrators can control elements including:
- The directory used to store log files
- The fields recorded within the W3C log
- Custom logging fields where applicable
- Log-file rollover options
IIS can create separate logging directories for individual websites on a server. This helps administrators distinguish the records belonging to the SLM site from those generated by other websites hosted on the same server.
In the training example, W3C log files are generated daily. After activity is performed within SLM, refreshing the current log shows the recently generated web requests, allowing the administrator to correlate application activity with the server records.
SLM Application Maintenance with PHP Logs
PHP application logs provide another important source of information for SLM application maintenance. Whereas W3C logs describe web server activity, PHP logs record events that occur during execution of the application.
These records can include:
- Application errors
- Warnings
- Event timestamps
- Severity information
- Error descriptions
- The file associated with an error
- The line number where the error occurred
This information can help administrators and developers investigate application problems and understand where an error originated.
According to the SLM training, PHP log files are stored within the application’s logs folder and are generated daily. Administrators can therefore use the relevant daily log when investigating application activity from a particular period.
Development and Production PHP Logging
The SLM PHP logging behaviour demonstrated in the training is controlled through the core_environment variable in the application’s .env file.
The training identifies two values for this setting:
- development
- production
When core_environment is set to development, errors are displayed in the web browser and also recorded in the application log file.
When the environment is set to production, errors continue to be written to the log but are not displayed within the user’s browser.
This distinction is particularly useful during SLM application maintenance. An administrator investigating an issue can use the application’s log records to obtain the technical error information generated by SLM, while the production configuration prevents those errors from being presented directly through the normal browser interface.
The transcript demonstrates this behaviour by introducing a PHP error, first viewing it with the environment configured for development and then changing the environment to production. In both cases the error is recorded in the log, but under the production setting it is no longer displayed in the browser.
Updating SLM Database User Passwords
Database credentials are another configuration area that may need to be addressed as part of SLM application maintenance and security administration.
The SLM configuration demonstrated in the training uses three database users, each with a unique password. These database-user configurations are stored in the application’s .env file under the database configuration.
Administrators can update the passwords for these SLM database users within that configuration when required.
Credential changes should be handled as a controlled administrative task. Passwords may need to be changed following a security event, credential exposure, changes in personnel or third-party access, or an organization’s established credential-management requirements.
Because these credentials form part of the application’s database configuration, administrators working in this area may also find the SLM Database Configuration guide useful for understanding the wider database environment.
Using SLM Application Logs to Troubleshoot Problems
The two logging sources covered in this SLM application maintenance guide provide complementary information during troubleshooting.
If the investigation concerns requests reaching the SLM website, HTTP methods, requested resources or response status codes, the IIS W3C records provide the web server perspective.
If the investigation concerns an application error or warning generated while SLM is executing, the PHP application log provides more detailed application-level information, including the error description and its source file and line number.
A practical troubleshooting process can therefore involve:
- Identify the approximate time at which the problem occurred.
- Review the corresponding IIS W3C records for relevant web activity and HTTP response information.
- Review the SLM PHP log for application errors or warnings from the same period.
- Compare timestamps and other available information to determine whether the records relate to the same application event.
- Use the resulting evidence to guide further investigation.
This approach helps administrators work from recorded application and server information rather than relying only on what a user observed in the browser.
Maintaining the Wider SLM Environment
SLM application maintenance is one part of maintaining the wider Safety Lifecycle Manager environment. Application logs can identify web and application problems, but administrators may also need to investigate database configuration, background processing or integration services depending on the nature of an issue.
For database-specific administration, see SLM Database Maintenance. Where an issue involves automated background processing, the SLM Background Task Manager guide provides additional technical context.
Integration-related investigations may instead involve the SLM Cloud Gateway Interface, particularly where the issue concerns the movement and processing of external plant data.
Together, these technical resources allow administrators to investigate the appropriate layer of the SLM environment while keeping application logging, database administration, background tasks and integration functions clearly separated.
