Version 6 Multiuser Architecture

Multiuser Architecture

Table of Contents

• Why Multiuser?
• What modes of operation does Toolkit offer now?
• What is different when I download and install a local copy?
• Test Session Inheritance
• Test Session Access Permissions
• Creating and selecting Test Sessions
• Test Session Names in multiuser and cas modes
• Transitioning to Version 6 Toolkit
• Other changes in Version 6
• Why isn’t authentication included?

Why Multiuser?

There are a number of motivations.

At Connectathon there is a need to give vendors additional control over their system configurations in Toolkit. This includes adding features not available in the download from Gazelle. This feature will be documented before the April 2018 Connectathon.

During Pre-Connectathon season we have offered the Public Registry for client testing. This summer the Public Registry Internet server will go away. Toolkit, in multiuser mode, will replace it. Public Registry was last updated in 2011 and it does not offer support for many widely used profiles and transactions. Also, it is known for giving out very bad error messages. Since it is no longer in development we have not made any updated/fixes available.

At Connectathon we offer the RED/GREEN/BLUE copies of Public Registry on the test floor. Starting in April 2018 in The Hague we will use Toolkit simulators instead of copies of the Public Registry.

Various testing programs, such as IHE CAS, use toolkit and need to isolate multiple concurrent users.

What modes of operation does Toolkit offer now?

As of Version 6 there are three modes: single-user, multiuser, and cas. As you go from single-user to multiuser to cas more functions require administrator access to perform. These are discussed below.

What is different when I download and install a local copy?

Very little. In toolkit.properties there are new configuration parameters named for multiuser and cas. As delivered these are both set to false. With both of these properties set to false we now refer to this mode of operation as single-user. In single-user mode the operation of the UI is unchanged.

In single-user mode there are changes to the structure of the External Cache. We have to isolate the work of individual users more so than in the past. In the past we have offered a feature called Test Sessions. Creation/deletion/selection of a Test Session (remember - delete is permanent - no undo) is done from the UI. This has been useful to run multiple users/projects from one copy of Toolkit. Now with the need to offer addition separation and additional management functions for that data, the following areas of the External Cache are changed:

• actors directory (system configurations)

• simdb directory (simulator state)

Each of these directories have a new directory level added. So a system configuration that was (in version 5 toolkit and before) in the file External_Cache/actors/prod.xml will now be in External_Cache/actors/default/prod.xml where default is the Test Session name that owns the system.

The change to simdb is the same. A simulator that was in the directory External_Cache/simdb/reg/ would now be in External_Cache/simdb/default/reg assuming it is owned by the Test Session default.

Note that External_Cache/TestLogCache/ has always had the Test Session name as the next directory in the file path and this is unchanged.

Test Session Inheritance

We have added an inheritance mechanism for Test Sessions. This affects what content you can see in the UI in multiuser and cas modes. The inheritance rules are:

• The default Test Session must always exist. On startup Toolkit will create it if necessary. A Test Session "exists" if it is present as a directory name under actors/, simdb/, or TestLogCache/ in the External Cache.

• For backwards compatibility system definitions is the base actors/ directory belong to the default Test Session

• If you are working in a non-default Test Session, say the name is foo, then:

  • System definitions from actors/, actors/default/, and actors/foo are available in the UI

  • Simulators from simdb/default/ and simdb/foo/ are available in the UI

  • Test results from TestLogCache/default/ and TestLogCache/foo/ are available to the Conformance Tool

• All new objects (system definitions, simulators, test logs) are always written to the Test Session (directory) selected.

Test Session Access Permissions

• The contents of default and your current Test Session are always readable

• You can only change the contents of your current Test Session

• In multiuser and cas modes the administrator password is required to select the default Test Session

Creating and selecting Test Sessions

• In single-user mode there are no restrictions

• In multiuser and cas mode you are not allowed to name Test Sessions. Instead Toolkit assigns names.

• In multiuser mode you request (via a button) a new Test Session. The Test Session is created and the name displayed.

• You can delete (remember - permanent delete) the Test Session when you want and enter/re-enter that test session by typing or copy/paste the name in the appropriate box.

• In cas mode the administrator must create Test Sessions. You will be informed of the Test Session you are to use. You do not have permission to create or delete Test Sessions. You can enter any Test Session you own at any time.

• You must keep track of your Test Sessions in multiuser and cas modes. The name must be pasted into a box. It will not be listed for selection.

Test Session Names in multiuser and cas modes

Test Session names are a hex values of between 5 and 31 characters in length. A setting in toolkit.properties governs the length generated. By default the names are 5 characters long. The reason for the obscure names is to make it difficult to guess the names of the Test Sessions created by other users. This provides a degree of privacy.

Test Session names in single-user mode are created by the user and not restricted in size/content (other than constrains necessary because we use them as directory names on your local filesystem).

Transitioning to Version 6 Toolkit

The first time you install Version 6, assuming you have run Version 5 or earlier in the past, you should delete these directories from the External Cache. Without these deletions the UI will produce some very confusing error messages:

• External_Cache/simdb

Other changes in Version 6

Administrator sign-in - in the past administrator sign-in was handled in a very lazy way. The password was asked for when needed. Also, your sign-in status was displayed in a few places. Now your sign-in status and the button to allow you to sign-in as administrator are located in the upper-right corner of the display. Instead of asking you to sign-in at important times you will be told to sign-in and repeat the operation.

Why isn’t authentication included?

Toolkit is installed in various environments were authentication is already provided. So, since we are trying to keep Toolkit installation light-weight and also don’t want to introduce conflicts were have left out authentication - for now. We may re-address this in the future.