VPA Groups: Overview
The Virtual Private Archibus feature enables Archibus deployments to segment their data between users and roles.
The Groups extension to VPA (VPA Groups) provides enhanced features to address several powerful trends in the industry, particularly outsourcing and collaboration between organizations. Customer organizations, such as corporations and institutions, outsource more and more of the work of managing and maintaining real estate, infrastructure and facilities so that they can concentrate on their own business. All organizations – customers and their service providers alike – use Archibus as a common operating environment and a unified enterprise information model to share data about the facility and transmit information about task to be performed and work processes. Yet each organization wants to share data selectively. Two "service provider" patterns are:
- VPA for multiple providers. Customers who host Archibus and invite a number of service providers want service providers to see only the data for their function. For instance, a hospital chain that outsources CAD and BIM data development for their site in Boston may want a provider to see only the space inventory data and within that set of data to see only the data for that city.
- VPA for multiple customers. Similarly, service providers who host Archibus may wish to partition data between their customers. For instance, a service provider who maintains high-end medical diagnostic equipment may host the data for many different hospital networks, and they wish each customer to see only the data for their machinery, work requests, and preventive maintenance schedules.
To manage these and other deployment patterns, the VPA Groups feature provides data partitioning. The feature includes the following elements.
- VPA Groups. VPA restrictions can be specified by referring to VPA Groups, which are flexible VPA restrictions describing groups of records.
- VPA Restrictions Table. The VPA Restrictions table (
vpa_rest) holds a centralized registry of all VPA restrictions. The table uses a syntax that makes these VPAs generic and able to be reused within multiple roles to greatly reduce the number of restrictions needed. The VPA Restrictions can refer to VPA Groups to succinctly specify groups of data. - Mapping Tables. Rather than using features like VPA Building Code List and the VPA Site Code List in the
afm_userstable, the VPA Groups feature uses separate mapping tables for lists of buildings and sites as well as other lists of entities to which the user has access permissions, such as division, departments, problemt types, customer IDs or legal IDs. In this way, different restrictions, roles, and user accounts can share the same, central permissions lists. Archibus Administrators can maintain these lists just by editing the tables in the Smart Client. - Legal ID. Deployment scenarios often involve sharing data selectively between legally distinct institutions or organizations. The Archibus Users table has a field for recording the user's Legal ID – the ID of the institution or business to which the user belongs. Add-in managers also can add a Legal ID field to building, equipment, work request, and other tables that contain data that is selectively shared. Using a macro representing the current user's Legal ID, add-in managers can create simple VPA restrictions for partitioning data between institutions and businesses without needing deep joins.
The advantages of the VPA Groups feature is that restrictions are:
- Centralized. They are a single registry of restrictions that can be applied uniformly to all roles, so central management of restrictions is easy.
- Expression-oriented. They can use binding expressions (macros) for the current user, the current VPA table, and the list of VPA groups, allowing fewer, more generalized restriction expressions to address all users and roles.
- Easy to administrate. They obviate the need for maintaining VPA Option1, VPA Option2, etc. fields in the Users table, since these values can be placed in reusable VPA Groups. They enable you to re-use and combine lists of restriction parameters, reducing the number of separate access lists you need to maintain or edits to individual user roles and accounts you need to make. Fewer restrictions and centrally controlled access lists make VPA easy to administrate.
- Easy to combine. You can combine roles, users, and VPA groups in flexible combinations, greatly reducing the number of roles and restrictions you need to define to address the security needs of complex deployments, often from hundreds of roles to tens of roles. This quality also results in easier administration and sites that are more secure because their security policies are clearer and more straightforward.
VPA Groups and VPA building and site lists
The VPA Groups features require that the Archibus administrator turns on the AbSystemAdministration-UseVpaGroups application preference.
Therefore, if you have Building Code Lists, Site Code Lists, or existing VPA Restrictions in roles, the system ignores these if you implement VPA groups.
Key VPA tables and their relationships
The VPA Restrictions table (vpa_rest) describe how the program assembles restrictions to apply to the current user and role.
Most of these restrictions use mapping tables to map the current user and role to groups of records. The mapping tables list these groups of records and identify each group with a VPA Group name.
These are the key tables used by the VPA Groups feature. You can review and edit these tables by loading them with the Views tab of the Archibus Smart Client.
| View | Main Table |
|---|---|
| VPA Groups to Roles Mapping Table | vpa_groups |
| VPA Groups to Roles Mapping Table | vpa_groupstoroles |
| VPA Groups to Users Mapping Table | vpa_groupstousers |
| VPA Groups to Buildings Mapping Table | vpa_bl |
| VPA Groups to Sites Mapping Table | vpa_site |
| Legal IDs | legal |
| VPA Groups to legal IDs | vpa_legal |
| VPA Restrictions | vpa_rest |
See also