Initialisation Fallback

To avoid that a missing part or issue prevents the BAM logging system from initialising, some fallbacks have been added to get logging started in many scenarios.

This way an attempt is made to get the Ometa framework processes started and running. However, not all scenarios are covered by this logic. If, for example the configuration file contains unknown properties due to typos etc., the framework processes will not start and write error messages to the Windows Event Log. So make sure, the configuration file always has a correct structure. For more information, please consult the article Appsettings.json Configuration.

Fallback Steps

How the fallback acts, depends on what destination you have defined initially in the appsettings.json file.

Basically it works like this:

• When the database connection fails for the database destination, the system will fallback to logging to files;
• If the log directory is not found on disk, in case of a file logging destination (or entered as fallback), a fallback happens (again) to log to the Windows Event Log.

When a fallback occurs, the logging system writes an additional error message about this event to the Windows Event Log and continue.

Important

Keep in mind though, that when the BAM logging system falls back to writing logs to the Windows Event Log, not all logs will be passed on. Only the log data of warnings, errors and critical messages are sent to the Event Log to avoid an overload of items.

Solving the Fallback

The only way to fix this issue, is checking and adapting the configuration settings in the %OMETA_INSTALLATION_MAP%\Ometa Software Suite\appsettings.json file.

Issues Without Fallback

As stated above, no fallback will occur when the structure of the configuration file has errors. But there will be no fallback either when the logging system passes its initialisation, and the database or logging directory becomes unexpectedly unavailable during normal operations of the framework.

In that case, the logging system writes error logging to the Windows Event Log and the framework processes simply keep working as normal but without the logging capability.

When the log destination becomes available again, the logging is resumed as normal.

For more information about solving logging issues, see Troubleshooting about the details.