All subsystems will use the archive as a persistent store for the entities they have
under control. Entities will be created, updated, retrieved and queried but usually not
deleted. All activities have to be permitted. The 'update' activity is used to update an
existingentity in the archive.
Goal: Update existing entity
Contact Author: A.Wicenec
Role(s)/Actor(s):
Primary: Any ALMA subsystem
Secondary: Executive, UserAdmin
Priority: Critical
Performance: Seconds (depending
on the size of the entity).
Frequency: 1 Hz
Preconditions:
- Database is running
- User/Subsystem got authenticated
- Subsystem has (updated) entity in 'hand' and knows UID.
Basic Course:
- Subsystem establishes connection to archive, for a human user there is an
user interface which acts as a subsystem. The subsystem is required to choose the correct
interface, i.e. XMLStore, MonitorStore or BulkStore. This is not critical, because only a
fewsubsystems will need to use the MonitorStore and the BulkStore.
Alternate Course: none
Exception Course: Connection can't be established: try again until timeout.
Postcondition: Connection established.
- Send entity to archive: Use the defined interface to send the entity to the
archive.
Alternate Course: none
Exception Course: not authorized: Subsystem is not authorized to update
this entity.
Exception Course: other: try again until timeout.
Postcondition: Updated entity stored in archive.
Postconditions:
- Updated entity stored in archive (Verification by using DB browser on the
history tree of that entity).
- Retrieval using the UID will result in updated entity.
Issues to be Determined or
Resolved:
The communication of the user ID and the associated
permissions have to be clarified. The required level of granularity for permissions has to
be specified by SSR and operational requirements. How do we control (or don't we care at
all) that updates are done on the 'correct' entity only, i.e. has the correct UID been
used for the update request.
Last modified: Thu Sep 25 15:24:38 CEST 2003