Unit Management

Basics

Multi-client capability means client-specific data separation within a CURSOR instance (=system installation). The multi-client capability allows the operation of several units in the same system environment. This reduces the system resources required per unit and the associated maintenance effort. The separation of the data between the clients can be completely or partially interpreted, depending on the procedure. Partial separation reduces data maintenance for shared data areas. The legal entities (corporations, companies, etc.) as well as company-internal organization unities (business units, brand areas, profit centers, etc.) come into consideration as a unit (client or unit).

Advantages of this solution:

Multi-unit compatibility leads to a reduction in resource requirements (main storage, disk, etc.)
Multi-unit compatibility reduces the need for administration (at installation, configuration, updates and patches)
The relative operating costs per client are reduced in a multi-client environment
The provision of another client requires minimal administration effort (system installation and configuration)
Identical customizing only needs to be performed once for all clients
The separation of business areas, within the same company, is very easy to map (no complex rights concept required)

Single database architecture

A maximum of 63 units are supported.

Unit management

All tables have a units field to assign the data to one (or more) units. All users are assigned to one (or more) units by the system administrator. When accessing the data, the unit ID of the current user is taken into account - at all points. For the organization of the data within the common database, the following procedures are used:

These are described in the following Use Cases.

In the admin console it is possible to maintain the units and assign them to the employees. Separate rights are required for this.
The Lucene index hits are reduced to the "visible" units.
With the login to the system, there is one default unit for each user, other secondary units are allowed with the Joint Units procedure. If secondary units have been assigned, the user also sees their data.

Separated Units

Each table is equipped with one client field (unit). The content of this field determines to which unit a dataset belongs. Only users who work under this unit ID can access the dataset (visible or changeable). New datasets receive their unit assignment from the employee's default unit (MainUnit.Employee).

Use case

An application provider supplies a preconfigured Out-of-the-box solution to a large number of small and independent companies.
Extensions or changes to the system should benefit all service recipients equally

Shared Datasets

The Shared Data Concept allows you to assign a dataset to several units. New datasets get their client assignment from a client template. Within the border of user rights, additional units can be assigned manually to each set.

Use case

In a company, three independently operating brand areas are differentiated. The three brands, however, partly address the same customers.
In this case, the Shared Data Concept allows you to assign the relevant customers to several units.

Joint Units

With the Joint Unit concept, several units can be assigned to the users. New datasets get their client assignment from a client template.

Use case

Two business units A and B within the same company serve different markets (customers, jobs, etc.). The operating business is strictly separated, but the units use the same product base.
In this case, you can set up a further master data unit C in addition to units A and B. This will act as a secondary unit for all users, enabling them to access the product base.

Unit management activation

To activate unit management, the "Unit Management" module must be imported.

The unit management cannot be imported in a module construction system (module "Create partner modules" active)

Initial migration for units

After the module has been imported, a client must be created in the system that is assigned to all users. All existing datasets are also assigned to this unit.

Because all data in the system is migrated, this process can take some time, depending on the amount of data and the performance of the database server. Here no other users are allowed to be logged in. The migration on the CURSOR reference system with an approx. 12 GB database under Oracle took 4 minutes.

Caution

During migration, the ClientNo field in each table is overwritten. Customer-specific data is not allowed in this field.
After the configuration of the unit system has been completed by the administrator, the Lucene Index must be completely rebuilt.

Unit-specific user licenses

The fields "User count" and "App user count" are located on the unit mask.

The administrator must assign at least as many name affixes to an unit as the number of users of the unit already assigned to the app or client license. If no number of licenses is stored, any number of users can be assigned to the licenses, provided that sufficient app or client licenses are available in total.

In the module management in the admin console, the user assignment checks not only the total number of app or client licenses but also the free licenses of the employee's default unit.

The administrator can create additional units in the Permissions area of the administration menu.

Manage units

The description for the unit can be stored in several languages via the internationalization button. The maintenance of units is controlled by the action right "Administrate units" (admin.unit.permission). In the delivery status, the administrator is authorized.

Units are transferred using the Customizing Transport.

An employee must always be assigned to a default unit. Further clients can be assigned by the sub area.

Alternative system owner for units

If, for example, unit management is used for hosting, one system owner is no longer sufficient for the entire system. Here you can optionally specify a system owner dataset in the unit. The system owner is then determined for the user via the default unit and used, for example, for the CTI interface.

Unit assignment of datasets

With the new creation of datasets, the dataset is always assigned to the default unit of the current employee. When datasets are loaded, the unit assignment of the dataset and the user is checked and only those datasets are loaded whose unit relationship matches. If Deputy is active, the current user uses the unit configuration of the deputy user.

The user can modify the unit assignment of the dataset using the unit button in the toolbar. Only the units of the current user can be adjusted. At least one client must always be selected, otherwise the user would no longer be able to load the dataset. If the dataset is still assigned to other clients that are not assigned to the user, these are not displayed or changed during editing.

The unit assignment in the person environment differs slightly from this. The assignment cannot be edited for persons, addresses, and communication. This data inherits the unit assignment from the relevant roles such as business partner, contact person, and employee. The person can belong to several units if the assigned business partners belong to different units.

You also cannot make your own unit assignments for quote and contract items; these inherit the assignment from the parent quote or contract.

The maintenance of the unit assignment to datasets is controlled by the action right "Manage units" (manage.unit.permission).

Inheritance of units

For this purpose, an inheritance of the unit assignment for the person-role model was implemented, which ensures the restrictions. The following points were implemented for this purpose:

For the address, the assigned units are always inherited from the higher-level entity Person or Connection Object. The unit assignment cannot be maintained here.
For communication purposes, the unit assignment is always inherited via the higher-level entities business partner, contact person, employee, and person. It is not possible to maintain the client assignment.
The units of the roles business partner, contact person and employee are always assigned to the person additively. It is not possible to maintain the client assignment manually.
The default contact person and their business partner always have the same unit assignment.

Unit inheritance has also been implemented for quote and contract processing for the entities quote and contract item. The items therefore always have the same unit assignment as the quote or contract.

Other dependent data such as activities or documents do not change their unit assignment. If a business partner changes units, the activities and documents remain in the old unit.

Deputy in unit management

If the user works as a deputy of another user, the unit assignment is transferred in addition to the deputy groups. The user works completely in the unit configuration of the deputy, which affects the selection and creation of new datasets.

Administration Unit Management

Excluding entities from unit management

For customer-specific (C2) or partner-specific (C1) entities, the administrator can exclude entities from unit management. You can use the entity properties in the entity configuration to maintain the "Multi-unit compatible" property. If the property is deactivated, unit assignment for these entities is no longer carried out during new creation. Even when searching for datasets, the unit assignment is not checked.

If you subsequently reactivate multi-unit compatibility on an entity, the unit assignment must be made explicitly for existing data by the database.

Multi units Keys

Keys are automatically assigned to all units during migration or new creation. The administrator can also assign keys to specific units only. The user can no longer select these keys if they are assigned to another unit. To do this, the administrator can edit the unit assignment in key maintenance.

Units Counter

The counters in the application are incremented unit-specifically in the application, depending on whether unit management is activated for the entity. A counter is kept in the counter table for the default unit of the user. If counters already existed before unit management was activated, they are copied for each unit and continued separately. If you want a system-wide counter on a multi units entity, new patterns are available in the field properties. See Field properties.

#SYSTEMNO#x	Creates an system-wide x-digit number. The client assignment of the user is ignored.
#SYSTEMNO#KEY(key)x	Creates an system-wide x-digit number for the key. If the client module is activated, a counter is generated for the current default unit of the user.
#SYSTEMSER#x	Creates a system-wide, continuous, x-digit number. The client assignment of the user is ignored. Using these variants may lead to wait states or errors when requesting the number on other clients, because this is determined within a transaction and is also rolled back again when the transaction fails.
#SYSTEMSER#KEY(key)x	Creates a system-wide, continuous, x-digit number for the key. The client assignment of the user is ignored. Using these variants may lead to wait states or errors when requesting the number on other clients, because this is determined within a transaction and is also rolled back again when the transaction fails.

Juhuuu search

If the unit management is activated, then the Lucene Index for the Juhuuu search must be created again, so that the unit number is considered correctly.

Client management enhancement (empty, delete, clone)

The client management has been extended by these functions:

Empty clients
Delete clients
Clone clients

.

Figure: Actions with Clients

Empty clients

The action can be started in the toolbar of the client entity

This triggers a function that deletes all transaction data (business tables, no C1, C2, CT tables).

The following data remains:

Employees and delegated data
Agency/system owner of the client and delegated data
Key tables (S_KeyTab, street, ...)
Configuration of the DataCleaner, e.g. not to delete a C2 entity

If datasets are assigned to more than one client, the client assignment is removed except for full client tables. Open processes with user actions must be deleted so that they do not run into an error. Open jobs of the mass data server must be removed (including processes).

The deletion is made by selecting the exact client number

All transaction data is deleted directly from the database, not via the deletion client.

Delete clients

The action can be started in the toolbar of the client entity.

The switch triggers a function that deletes the following data from the client:

All transaction data
Employees and delegated data
Agency/system owner of the client and delegated data
Key and all C2 data assigned only to this client

If several clients are assigned to a dataset, the client assignment is removed. This client number must always be set in full client tables. Relation data are subsequently adjusted. It is possible to delete several clients at once. A deleted client is attached to the customizing package. There may be only one open package.

Clone clients

The action can be started in the toolbar of the client entity.

The switch triggers a function, which takes the user to a selection dialog where he/she can select a source client. All Customizing settings from this client are also assigned to the new client. All full client tables are also handled. Transaction data is not changed. The main user (TECH_USER & list of PKs in the PropertyMapper of employees, new PropertyMapper + PropertyConfig entry, type de.cursor.StringList) gets the new client. User data of the new client is created by a main user (logged on as new client) via XML import.

Only the new client is created during the customizing transport. The changed customizings are not attached to the package. Cloning and the associated creation of customizings takes place automatically in the data target when the customizing package is transported.

Only one open package may exist, otherwise the client assignment of keys, for example, can diverge. When the package is imported, the client is cloned before client-related data is imported (for example, keys). Cloning and deleting clients cannot be done within the same customizing package.

"Cloning clients" and "Deleting clients" cannot be on one package.

Database interfaces in client management

SQL interfaces

The ClientNo field must be filled for multi units entities. Analogous to the authorizations (Bitright table), the units are stored bit-encrypted in the ClientNo field. A unique number (0-62) is defined for each unit when it is created. The unit assignment is then calculated with 2^UnitNo.Unit and written into the ClientNo field. If several units are to be assigned, the values must be totaled.

For entities that have been excluded from unit management by the entity properties, the value null must be entered in the ClientNo field. This also applies in general if the unit management module is not activated.

The value 0 in the ClientNo field is intended for the delete unit and must not be used in interfaces.

If the ClientNo field is changed, the Lucene index for the Juhuuu search must be updated. Here, the dataset must be included in the UnindexedEntity table.

Caution

The rules for the inheritance of units in the person-role model and the position entities must be observed.

Employee interface

For each employee, the default unit must be entered in the double persistent MainUnit.Employee field. This must be linked analogously in the table rEmUn and the Flag DefaultUnit.rEmUn set to 1. Further units can be linked with the DefaultUnit.rEmUn Flag = 0.

Key

If interfaces create keys, the value "9223372036854775807" (=2^63) should be written into the ClientNo field. Since this number cannot be set directly by SQL, you must switch to the following database functions.

MSSQL:
(POWER (cast(2 as bigint), 62) -1) + POWER (cast(2 as bigint), 62)
or
cast(9223372036854775807 as bigint)
ORACLE:
(POWER (cast(2 as DOUBLE PRECISION), 62) -1) + POWER (cast(2 as DOUBLE PRECISION), 62)

In order to keep the unit assignment, the old value of the ClientNo field must be transferred when deleting and creating new keys.

XML import

During XML import, the client assignment can be specified via the ClientNo field. The import user must be assigned to all affected units, otherwise the import terminates with an error. If no unit assignment is specified, the datasets are assigned to the default unit of the import user. The ClientNo can also be transferred for keys. If this is omitted, the keys are assigned to all units (ClientNo=9223372036854775807).

Mass data jobs

All actions that are transferred to the mass data server in the form of mass data jobs (CSV export, reports and BPM mass data) are executed under the client that the user who initiated the job had set via client switch at that time.

Customizing transport

Activating unit management in the production system

If the Customizing transport is active in the system, a Customizing package is created when unit management is activated in the development system. This must first be imported into the production system or an intermediate QA system before the unit management license can also be activated in the production system.

A new Customizing package is always created. Once the package has been confirmed, the unit is created and all data in the system is migrated. When the package is transported, the units are created in the data target. When importing the module license, all data is migrated.

Transport of units

If units are created or changed, the changes are appended to a Customizing package. The changes can then be transferred to the other systems.

Transport of keys

When keys are transported, the unit assignment is also transferred automatically. This also applies to new units which have not yet been transferred. If unit management is not activated in the data target, the unit assignment is deleted during import.

Employee synchronization

During employee synchronization, the default unit of the user is transferred to the other systems.

System owner synchronization for unit management

The "System owner" field in the client can only be maintained in production if the employee synchronization is active. For this purpose, the entry and also the business partner behind it are automatically transported from the employee synchronization to the other systems.

The transported data is determined by the "C0SYSTEM_OWNERS_TO_MERGE” search.

Unit management in BPM

The unit assignment of datasets can be edited in BPM scripts via the UnitUtils.

Client switch

In a multi-client system, users with multiple client assignments can change the main client at runtime.

Two professional application scenarios:

A call center agent works for many clients. Depending on the incoming call, he/she wants to switch to the relevant client and then only wants to see the data of this client (exclusive client switch).
A company operates two business units. Certain users have access to the data of both units. If you create new data (for example, quotations), it must be assigned to a specific unit on a case-by-case basis. For this purpose, the user wants to be able to change the currently valid main client at runtime without losing visibility to the data of the subclient (including client change).

Exclusive and inclusive multi-client mode

There are two different modes for user-specific multi-client operation:

Inclusive mode: If a user has access authorization to several clients, the data for all clients is displayed. The main client only affects the creation of new data.
Exclusive mode: If a user has access authorization to several clients, only the data of the current main client is displayed at runtime.

Changing the main client at runtime

The currently valid main client can be seen in the branding bar of the application:

Windows Client

Web Client

A drop-down box allows you to change the main client. The box contains all secondary units of the logged in user.

When changing the main client and the user is in multi-client mode, please note:

Inclusive mode: The data of all user clients remains visible. The new main client determines the client assignment for new datasets.
Exclusive mode: When you change the main client, only the data of the new client is visible

Settings

The call center mode can be activated via user settings.

Windows Client

Web Client

If this is activated, the user can select the active client via a combo box in the main toolbar.

Windows Client:

In the Web Client, the user can always change the client.

or the call center mode

New datasets are entered for the active client. The user still has access to all his/her assigned clients.

In exclusive mode, the user only has exclusive access to the selected client. All open levels must be closed before switching. MyCRM and Favorites will be updated. Client management on datasets is deactivated here because only the selected client can be used in this mode.

Representation on the surface

The placement of the client switch can be controlled via an application setting. In the "Standard" mode the switch is not in the header of the application.

Windows Client

In the Windows Client it can be reached via the menu Options > Client change. This opens a submenu with the available clients. The currently selected main client is highlighted in the menu (by activating the corresponding control field). If you click on an entry in this submenu, the main client changes.

Web Client

In the Web Client, the main client is changed via a menu in the Branding Bar. The currently selected main client is highlighted in the menu (by activating the corresponding control field). The tooltip of the button contains the currently selected client.