The swArchitect client is a specialized SystemWeaver client which supports the creation and modification of the meta model of a SystemWeaver server. SystemWeaver servers, in turn, use the meta model to control the creation and modification of model data. Both the SystemWeaver meta model and the user model are maintained together in the database.
The SystemWeaver collaborative properties apply to the meta model of a SystemWeaver server as well which means that changes to the meta model are accessible in real time to any connected swExplorer client.
When to Complete Meta Model Modifications
It is recommended that modifications to a meta model only be made when there are no users logged in to the SystemWeaver server. You can view this on the Logged On tab in the swAdmin2 client.
Even though there may be modifications that are safe to do while users are logged in, best practice is to only make modifications when there are no active sessions.
Tip: To ensure that no users are logged in to the SystemWeaver server, shut down the server prior to the modifications and then start the server using an irregular port that is not available outside the server computer, as set up by the server firewall.
Taking a Backup First
As a general rule, you should create a complete database backup copy when you are going to make modifications to the meta model. Some modifications are easily revoked while others may not be. As a general rule, you should always make sure there is a backup copy of the complete database before any modifications are made to the meta model. A complete copy means the complete database files including both meta model and user model.
When Meta Model Changes Take Affect
All changes to the meta model that are done in the swArchitect become effective immediately in the SystemWeaver server. However, the changes may not become effective in other connected client instances until the next log in of that client. Since the recommendation is that no users should be logged in when the meta model is modified, the changes will be seen upon the next log in. There may, however, be cases when a change needs to be done during normal operation, with users logged in, and for those cases the following table indicates when such changes will become effective in the standard swExplorer client. Some changes require changes to be made in views:
| Required User Actions, Model Refactoring and Client Modifications | ||||
|---|---|---|---|---|
| Modification | Generic Views (e.g., tree view) | Specific Views (e.g., Graphical views) | User Model Data, general | Notes |
| Extending the meta model | Possible even without stopping or restarting server. | |||
| Adding object subtype, specialization | No action required | No action required | No action required | |
| Adding part type | No action required | Redesign/reconfiguration of client view (I) | No action required | |
| Adding attribute type based on standard (II) data types (i.e., not "Custom") | No action required | Redesign/reconfiguration of client view (I) | No action required | |
| Adding attribute type based on new custom(III) data types | Redesign of client view | Redesign/reconfiguration of client view (I) | No action required | |
| Restricting the meta model | Possible even without stopping or restarting server. | |||
| Restricting attribute value domain | No action required | No action required | Refactoring(IV) | |
| Changing item types for part types | No action required | Redesign/reconfiguration of client view (I) | Refactoring(IV) | |
| Disabling of item type or part types | No action required | Redesign/reconfiguration of client view | No action required | |
| Deletion (VI) of item or part types | No action required | Redesign/reconfiguration of client view | ||
(I) In case relevant to view
(II) Integer, Float, Boolean, Date, String, Text, RVF, Enumeration, XML, User, External Reference, Computed, Identity (single/multi dimension, set)
(III) Generally using XML representation but opaque/blob possible. Plug in option for custom attribute editors.
(IV) Re-factoring either manually, by using built-in re-factoring tools or scripting. Deviation from meta model is highlighted in GUI.
(V) Plug in option for custom view plug in. Deviation highlighted in GUI.
(VI) Delete not possible unless prior re-factoring and elimination of instances.
Tracking Meta Model Changes
There is no built-in versioning of SystemWeaver meta models. This means that you should keep track of meta model modifications in some other way.
How to Track Changes
- Keep a change log document that describes all modifications.
- Use the Info field of SystemWeaver Items, Parts and Attributes to document modifications
- Use the SystemWeaver CMS (Change Management System)
- Export the meta model on a regular basis, e.g., daily, weekly, using the swXmlExport tool. Example command line to only export the meta model:
What To Include
The documentation should typically include the following information:
- When the change was done
- Who did the change
- Why the change was done, preferably with some reference to a complete documentation of the change