Recovery

In the event that something catastrophic happens and the client no longer has an administrative login to the system, it is possible to restore enough access to get things working again. In extreme cases, these recovery steps will require significant access to the system and are not considered to be a normal part of the application's functionality.

There are two main types of security data:

1. Data that is generated or persisted from the security definitions
2. Actual security definitions

Recovery of this data depends on which of these two types of data were lost or corrupted.

The data that is generated and persisted is generally what BusinessPlus looks at to determine access at runtime, and this data can be regenerated from the definitions using the Rebuild Security tools. The data in this category include the US_ROLE_OUTPUT table, and the rows in IFAS_DATA where the CATEGORY column is equal to "XMLMODEL," "XMLUSERSEC," or "XSLTROLE." This data is recreated or repaired when security is rebuilt.

The more troublesome issue is when the security definitions themselves become damaged. The actual security definitions are stored in the following tables: US_SECOBJ_MSTR, US_ROLE_MSTR, US_ROLE_DTL, and US_ROLESEC_DTL. Depending on what data in these tables is lost or corrupted, there are several recovery paths:

• If the Security Structure (US_SECOBJ_MSTR) has become damaged, the client may be able to recover the missing pieces by using the Manage Security Structure plugin in the Administrative Console to rebuild the security. This will analyze the current setup looking for gaps in the expected structure and will proceed to fill in any missing security elements. In most cases, this should be a harmless recovery step. There are several parts of the Security Structure that are client-defined and cannot be recovered. These include CDD folders and anything client-defined under the Custom folder of the Security Structure. For this reason, it may be necessary to manually recreate CDD folders in the Folder Manager, and to recreate custom menus and tables.
• Assuming the Security Structure (US_SECOBJ_MSTR) is intact, the next question is what state the Security Roles are in. It could just be that the persisted versions of the security roles have become damaged somehow and simply need to be refreshed. In that case, deleting the persisted XML from the IFAS_DATA table and removing the roles from the US_ROLE_OUTPUT should allow the client to rebuild one or all of the users on the system based on the actual security setup.
• If one or all of the remaining security definition tables (US_ROLE_MSTR, US_ROLE_DTL, and/or US_ROLESEC_DTL) are missing data or somehow corrupted, it may become necessary to force an administrative user into the system to get the software working again. Because the Administrative Console only reads the User Security XML it is possible to create a single Role and Role Assignment that will let the user back into the software.