How It Works

Technical business objects typically form a hierarchy of objects on several levels. Keeping track of all changes made to all individual components belonging to a technical object would generate an overwhelming amount of data bearing little meaningful information. That is why the crucial question here is at which level changes should be logged.

Example: A workflow consists of a number of workflow nodes, the actual function of the workflow is determined by the function and interaction of its nodes. As the nodes cannot "live on their own" outside the workflow, logging all changes made to all of the nodes would not provide much meaningful information whic means we have to log the changes at the workflow level. (Note that by "workflow" in this example we actually mean "workflow definition", i.e. we should have used the terms metaworkflow, metanode, metatransition etc.)
Similarly, a view consists of a number of elements (view of reference list, view of attribute, view of reference etc.) Again, registering changes made to individual view elements would not make for much meaningful information and we need to log the changes at the view level.

The "meaningful level of information" problem is solved by propagating information about element changes upward to the "root" object (represented by workflow and view in the examples above) and logging the consequential changes in these root objects.

• Propagating information about changes to the root object

  Every technical object (i.e. object based on AMT table) has protocol fields where the following information is stored:

  • Date Created - date and time when the object was created
  • User Created - user which created the object (userID and user domain, if applicable)
  • Date Changed - date and time when the object was last changed
  • User Changed - user which last changed the object (userID and user domain, if applicable)

  An internal mechanism ensures that if the above mentioned information changes in a component technical object, this change is propagated to its root object. (This means that, for example, when a workflow node is modified, created or deleted, its root workflow is also registered as modified.)

• Logging root object changes into a special table and adding information about the purpose of the change

  In addition to being propagated from component technical objects to their root objects, the information about the changes also gets registered in a special table AMT Log represented by the Log catalog. The catalog also contains a Comment column which contains information about the purpose of the change. See below for more information on the catalog and using the comment.

What is meant by "root" objects? There is no explicit definition for the term "root" object. We use it here to signify that an object, which is usually (but not always) composed of other "component" objects, can - unlike its components - exist on its own. It means that it makes sense to, for example, import/export such object. Consequently, the list of object types in the Export Metamodel window could be considered a list of "root" objects.