Using the API for the Synchronization of AWM Elements

Since AWM elements are typically 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, requiring you to manually execute modeled actions to refresh corresponding element lists. To avoid this requirement, 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 specify a linked element type for every type of element it is able to refresh. See Linked Element Type for more information.
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 specified by the function package.

Example:

The Eclipse function package specifies 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 specify 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.