Room Extensions - Run Time

When a room or a room part is created, the constant values as well as the parameter references are copied from the template to the room or room part context. During the lifetime of the room, there is a defined dataflow between context and extension (see Room Extensions - Design Time ).

While an extension point is processed, lots of extensions may be executed. The problem arises that if some of them succeed, but others fail, this may cause an inconsistent context of the room or the room part. For example, a folder for a room part may have been created by extension 1, but extension 2 fails in setting the permissions. Obviously, a mechanism to rollback the extensions is required. Furthermore, if it is known in advance that an extension cannot process, e.g. because a mandatory resource or a configurable is missing, it saves performance to immediately throw an exception instead of starting to process the extensions, then running into the error and rolling back everything.

Extensions implement methods to approach the described transactional behaviour. When an extension point is processed, first the validate method of all extensions is called. If one extension fails, the processing of the extension point terminates on error. If all extensions can validate, the process method is called in a second step. If one extension fails to process, all extensions are rolled back, otherwise all commit.

Description of the methods

Method	Description
Validate method	In this method, the extension takes the input parameters from the context and throws an exception if they are not consistent. Nothing should be processed. Since the input parameters may come from the output of other extensions, which also do not process in this step, they may be missing. The extension therefore should treat all parameters as being optional and validate only the parameters that are present. The validation also may enclose to check the availability of a backend or a required configurable. If an extension does not implement the validate method, it may still work, but cause a high performance effort, because avoidable errors must be rolled back over all extensions involved in an extension point.
Process method	In this method, the extension takes the input parameters from the context, processes them and returns the output parameters as the result. Everything processed in this method must be reversible, e.g. if the extension deletes something, it should copy it to a recycler or create a backup. There is the special case that an extension creates something, e.g. a workspace, and must be enabled to delete it when it is asked to rollback. Since the extension is a singleton, it does not have instance properties were the workspace could be stored for later access. It is also not stored to the context before the extension commits. So how can it be accessed for the roll back? - The extension operates on the context of the room; it writes the parameter there and removes it in the rollback method.
Rollback method	This method is provided with the same context as the process method, but it may be enriched with objects created during the processing. The task of the rollback is to undo everything the process method did. Created objects are deleted, and deleted objects are restored, recycled or recreated.
Commit method	This method finalizes the execution of the extension. It is not allowed to do any processing here; the extension must have fulfilled its purpose, even if commit would not be called. Commit just removes backups provided for the rollback that are no longer useful.