Using the API for the Synchronization of AWM Elements

Since AWM elements are usually representations of objects stored in an external database, changes to objects can occur that are not caused or handled by a modelled AWM action. In these cases, AWM elements can get out of sync with the database and you must manually execute modeled actions to refresh corresponding element lists. To avoid this problem, AWM provides a programming interface to dynamically refresh AWM elements.

A plug-in must fulfil two conditions to be able to dynamically refresh AWM elements:

It must define a linked element type for every type of element it is able to refresh (see Linked Element Type).
It must call the method TaurusUtility#refreshLinkedElement(...) of the AWM plug-in com.microfocus.awm.core in order to refresh a particular element. The ID(s) of the supported linked element type(s) is one of the method's parameters (see JavaDoc for more information).

In addition, corresponding AWM models must use the linked element types that support being refreshed, and those element types must have an ID definition as it is proposed by the function package.

Example:

The Eclipse function package defines the linked element type "Eclipse Resource", which represents any resource of the Eclipse file system.

The function package also contains a synchronizer Java class, which listens for Eclipse workspace changes. This synchronizer calls TaurusUtility#refreshLinkedElement(...) every time a change is detected in the workspace, keeping AWM elements of the linked element type "Eclipse Resource" synchronized with the workspace.

AWM models which want to benefit from the synchronizer need to define Eclipse resources representing element types as "Eclipse Resource" linked element types, which need to have an ID definition with exactly one property, which must contain the complete Eclipse resource path.