Distribute OEM Layer Updates

If you have modified your OEM layer, then the process to distribute that change depends on how the OEM layer was originally distributed. You may also need to restart the application, depending on the type of change made to the OEM layer.

Networked applications

If your application runs on multiple servers, and is based on an OEM layer, then that OEM layer must also be present on each server. It can be difficult to maintain separate server lists for both the primary application and its OEM layer application, especially if the OEM layer is used by more than one application. Fortunately, one server list can work for both the application and the OEM layer at any site, so long as the SyncOEMLayers property is set TRUE, as it is by default. To verify, open the Application Configuration dialog of your application (the top layer application, not the OEM layer) and look for the check beside "Synchronize the configuration of OEM layers via derived applications" in the OEM Layer section of the Other properties tab.

With SyncOEMLayers set to TRUE (1), updates in the OEM layer's configuration will be distributed automatically using the application's server list as soon as those changes are deployed in the OEM layer.

Certain layers supplied by Trihedral will not synchronize automatically under any circumstance. Instructions for deployment are provided with all updates to these layers.

In rare cases, it is possible that you might not want this OEM layer to synchronize automatically. For example, you want to apply ChangeSets individually on each server, perhaps to test changes as you roll them out. Another possibility is that the update will require a full restart, and you want to control when that happens on each server. For these cases, you should add the property DoNotSyncLayer to the OEM layer application. When set, DoNotSyncLayer takes priority over SyncOEMLayers.

DoNoSyncLayer requires a full restart of VTScada, not just the application.

Snapshot Distributions

Snapshot ChangeSets without source code are run-only applications. This is the most common way that OEM layers are distributed from system integrators to clients. (ChangeSets for Distribution) Updates to the OEM layer must made be at a workstation where the OEM layer's source code resides, then distributed to clients via a ChangeSet. If you are also distributing updates to an application and those updates depend on new features in the OEM layer, then it is essential that the OEM layer be distributed first, followed by the dependent application.

Remember that ChangeSet updates can be applied only to applications having the same globally unique identifier.

After an application has been created, its name is only a display property. You can take advantage of this fact to add a version number to the OEM layer's name, and update that number each time you are ready to distribute a new set of features. Some integrators do this to help keep track of which release is installed at a site.
The name property must be updated manually.

Troubleshooting:

  • Changes made to a page or widget in the OEM layer are not showing up in the dependent application.

The OEM layer was distributed with source code. The page or widget was opened in the Idea Studio of the dependent application, causing a local copy to be made.
Use the Idea Studio to delete the local copy in the dependent application.
If it is necessary to have local variations to a page, then the OEM page should be made into a widget that can be added to a local page.

  • The OEM layer has no link to the Idea Studio.

This is by design. The OEM layer was distributed to this workstation (or server in your network) as a Snapshot ChangeSet without code. Pages and widgets within the OEM layer can be edited only on a workstation where the full version, including source code, is kept.