Update to the multi-tenancy model
Multi-tenancy defines who has access to what data on a row-level basis. For example, in a service provider environment, a single application might be used by multiple companies, with the data for each company hidden from other companies using that application.
For information about implementing multi-tenancy, see the section Multi-tenancy in the topic from the BMC Remedy IT Service Management documentation.
This topic provides the following information:
Overview of update to the multi-tenancy model
The following diagram provides a visual representation of the concept of multi-tenancy update, the environment in which it is performed, and methods of performing the update. It also shows the steps for performing a manual update.
The update to the multi-tenancy model is not supported if BMC Service Request Management is installed by itself as a stand-alone product, or if BMC Service Request Management is installed on a mixed-version stack. For more information, see in BMC Service Request Management documentation.
The update to the multi-tenancy model addresses issues related to row-level security on the Company ID field (Field ID 112) and Vendor Assignee field (Field ID 60900), which were inaccurately set on the following forms:
- Main application transactional forms; for example, Help Desk, Problem, and Change
- Multi-tenant aware child forms of the main application transactional forms; for example, Assignment Log and Impacted Areas
- Join forms related to the forms mentioned in the preceding two bullets; for example, HPD:HelpDeskAssignmentLogJoin and CHG:CostAssociationJoin
The update to the multi-tenancy model also updates data related to the updated forms.
Automatic (during installation) or manual update to the multi-tenancy model
The following table describes scenarios in which the update is transparent to you and scenarios in which it is handled by an interactive utility:
|Scenario||Type of update|
|You are performing a fresh installation of the BMC Remedy IT Service Management (ITSM) Suite||Occurs during installation and is transparent to you|
|You are upgrading the BMC Remedy ITSM Suite to a later version, and your environment contains only multi-tenant components||Occurs during upgrade and is transparent to you|
|You are upgrading from an earlier, nonmulti-tenant version of the BMC Remedy ITSM Suite||Handled by an interactive utility|
The interactive multi-tenancy update utility is integrated with the upgrade installer. After the installer upgrades the BMC Remedy ITSM application, it automatically invokes the update utility. Depending upon your multi-tenancy model implementation, you can choose to continue the update during the installation, or perform the update manually after the installation is complete.
The following table describes the method to perform the update based on your multi-tenancy model and preferences.
|No customizations exist on the multi-tenancy model||Occurs automatically during the installation|
|You environment has fewer than 20 million records||Occurs automatically during the installation|
|Customizations exist on the multi-tenancy model||Manual, after the installation is complete|
|Your environment has more than 20 million records, which will require an extended processing time||Manual, after the installation is complete|
You encountered errors during an earlier run of the multi-tenancy update and need to restart the update
|Manual, after the installation is complete|
|You need to apply the multi-tenancy updates to the delta data||Manual, after the installation is complete|
End-to-end steps for manually updating the multi-tenancy model
To update the multi-tenancy model manually, perform the following steps:
|1.||Understand the multi-tenancy model customizations that are overwritten by the multi-tenancy update|
Understand which types of multi-tenancy model customizations on forms and fields are overwritten by the multi-tenancy update, and which are not.
|2.||Reconcile the customizations to the multi-tenancy model||If you have a customized multi-tenancy model, reconcile the customizations before you run the multi-tenancy update, to preserve the customizations.|
|3.||Control which records or fields are processed by the multi-tenancy update|
Use the Application Maintenance console to protect the customizations on specific forms, or on Field ID 60900, from being overwritten by the multi-tenancy update.
|4.||Start the multi-tenancy update utility manually||Use this procedure only in the following situations:|
|5.||Check the status of the multi-tenancy update|
Use the Application Maintenance console to check the status such as which forms are waiting to be processed, which are now being processed, which have already been processed, the number of records being processed, and the data errors that occurred during the multi-tenancy update.
|6.||Investigate the multi-tenancy update processing issues|
If the update utility encounters any data errors while it is processing the update, the utility stops running so that you can troubleshoot and fix the data errors. Use the Application Maintenance console to investigate the data errors.
|7.||Test the Data Fix|
After you investigate and troubleshoot the data errors, use the Application Maintenance console to test the data fix. Keep the following points in mind:
|8.||Perform postinstallation steps for multi-tenancy update|
If you added a new dynamic group field with any of the following characteristics to the forms, you must manually update the forms that are modified by the multi-tenancy update:
|9.||Prepare to process migrated delta data|
If you use the delta data migration process during your upgrade, you must manually rerun the update utility to apply the multi-tenancy updates to the migrated delta data.
|10.||Updating multi-tenancy fields on forms for delta data records|
After you migrate the delta data, return to to the Application Maintenance console to prepare the staging server for applying the multi-tenancy updates.
Depending on the extent of your environment, you might need to process migrated delta data iteratively until the production server and the staging server are synchronized. At that point you can move your staging server into production.