VPA Use Case: Using a Hard Partition

In some cases, deployments want to keep some data very reliably separated even though this data is used by many users in a complex way. Equipment is an example. Suppose that different customers create self-managed Equipment in a shared environment hosted by their service provider.

Suppose both the Boston Surgical Center (BSC) and the Boston Wellness Hospital (BWH) each create Equipment records in the same database hosted by their service provider, Service Industries (SIE).

Approach

• Add a customer ID (a "legal entity ID" or "Legal ID") to key tables (such as, eq, bl, and probtype) to keep customer data separate using simplified restrictions.
• Add an SQL Default to all Legal ID fields to give them an initial UNASSIGNED value.
• Add a data change event to fill in this Legal ID on new entities to match the user's assigned Legal ID if the Legal ID is UNASSIGNED.
• Use the Numeric ID feature to display customer information neatly (while the pkey -- e.g. bl_id -- is unique for all customers) so that customers can hide the "legal ID" prefix where needed.

Legal IDs table (afm_legal)

Enter a Legal ID for each organization with a separate legal identity (that is to say, each institution, corporate customer, service provider, and so on).

Archibus Users table (afm_users)

When granting users access, enter this Legal ID in each User record.

Applications can refer to the current user's Legal ID using the server-side binding macro: ${user.legalId}.

VPA Groups to Legal IDs Mapping table (vpa_legal)

Add VPA groups to roles such as Customer Service Representatives who must see data for more than one Legal ID.

Data Change Event

When any form or workflow rule uses a datasource to update a table, and that table has a legal_id field, a data-change event checks the Legal ID of each record that is added.

If that equipment record's Legal ID is blank or is the UASSIGNED default value, the data change event edits that value to be the user's ${user.legalId}.

This event operates in the core account, not the user account, so the user does not need access to the Legal ID field as a Calculated or Edit Group.

(Connectors use the DataSource API to import data into the database so that imported data will be assigned to the user account that executes the Connector.)

Edit Forms

Customers with self-managed equipment have forms that:

• reject any new Equipment Code entry that is too long (the program needs 4 characters to prefix the Legal ID, if the user did not themselves type in the Legal ID).
• add a prefix to the Equipment Code with their Legal ID (that is to say, turn Equipment Code "001" into "BSC-001").

The Legal ID might be different from the user's Legal ID, such as in cases in which the service provider is editing data on behalf of a customer. The deployment has specialized edit forms on the Equipment table. Service provider administrators have edit forms that allow them to choose a particular Legal ID so they can enter Equipment information on behalf of different customers. (In this scenario, Service Providers need Security Group access to edit the Legal ID fields.)

SQL Default Value

The Equipment's Legal ID (eq.legal_id) field has a NOT NULL constraint and an SQL default value of UNASSIGNED. No Legal ID matches this default value. In this way, even if an Equipment record is created via an SQL INSERT or via a data import that bypasses the data change event; the Equipment record cannot be seen by users who are not authorized to do so.

(SQL Default values in Archibus metadata have the effect of a "trigger" on any new record, ensuring that they have this value if the INSERT statement that creates the record does not provide one.)

Equipment table (eq)

Equipment records in the table appear like this.

eq_id	bl_id	fl_id	rm_id	eq_std	legal_id
BSC-01	BSC-001	01	200	MRI	BSC
BSC-02	BSC-001	01	201	MRI	BSC
BWH-01	BWH-001	01	200	MRI	BWH
BWH-02	BWH-001	01	200	MRI	BWH

VPA Restriction table (vpa_rest)

The service provider administrator creates a VPA Restriction on the Legal table and on all table that validate against the Legal table (such as, Equipment, Buildings).

The restriction allows users to see data for their own organization (for their own Legal ID) or for any organization that the VPA Mapping Table for Legal IDs (vpa_legal) explicitly list to give access to their VPA Group.

Validating Table	Type	Subquery
legal	Explicit Query	( ${sql.mainTable}.legal_id=${user.legal_id} OR ${getVpaGroupsRestrictionForBridgeTable( "legal", ${sql.mainTable} )} )

VPA Restriction (vpa_rest) tor work requests

In this scenario, the Work Requests (wr) table does not have a Legal ID and the program does not apply the restriction above. An alternative restriction is below.

Applies to Table	Type	Subquery
wr	Explicit Query	EXISTS( SELECT 1 FROM eq WHERE ( eq.eq_id=${sql.mainTable}.eq_id AND eq.legal_id=${user.legal_id} ) OR ${getVpaGroupsRestrictionForBridgeTable( "legal", "eq" )} )

This also applies to tables that validate on wr, such as the the Work Request - Parts (wrpt) table.