Application and Workflow Rule Guidelines

The Deployment Packager can migrate any applications that are coded to the Archibus best practice guidelines. For presentation extensions, these best practices include the techniques in the System Management Help reference sections on Web Presentation for View 2.0 Elements, View Commands, JavaScript API, and Binding expressions. For workflow extensions, these include the API described in eventHandlerBase, the dataSource service, the JobManager, and selected Web Services invocations.

Avoid using the Software Engineering techniques, as these are specialized, and may not migrate from release to release without changes.

You can run your Archibus application extensions on later versions of the Archibus core if you follow the application guidelines.

Presentation Layer Guidelines – Features That Migrate Automatically

Your extensions should use features that are part of the documented API in the following System Management Help topics:

  • System Integration – Web Presentation – Reference for View Elements
  • View Commands
  • JavaScript API
  • Binding expressions

These topics cover all of the View 2.0 tags, the standard controls that ship with Archibus, such as the chart and drawing controls, and JavaScript actions.

The APIs listed above isolate your extensions from the underlying HTML, and from other parts of the API that may change from release to release.

Presentation Layer – Features That Do Not Migrate Automatically

In particular, your extensions should avoid techniques that depend on the particular HTML structure, or APIs internal to the controls. More specifically, the guidelines avoid techniques that modify the DOM directly, create your own custom controls, modify the cascading style sheets or .css styles, use XSL-FO, use DWF files, modify files in the \schema\ab-core or \schema\ab-system , or use APIs not documented in the above reference.

There isn’t any functional issue with using such techniques. However, if you do so, be aware that your extensions may need to be altered if you update to a new version of the core. For instance, if you add your own version of the abCascadingStyleSheet.css to match your own corporate branding and graphic conventions, you may need to alter this style sheet if future versions of Archibus alter the HTML rendering format. We. strive to keep these changes to a minimum, but cannot isolate applications from those changes, as there is no API to decouple these features from the implementation details.

Logic Layer Guidelines – Features That Migrate Automatically

For extensions that use Java, use only the API within the supported JDK for Archibus. Within Archibus, use only the documented API in the System Management Help.

For a detailed description of the Archibus Web Central API, use the Index to API topic to access the API.

This Archibus API consists of:

  • eventHandlerBase
  • dataSource service
  • JobManager
  • selected Web Services invocations.

Logic Layer – Features That Do Not Migrate Automatically

Again, there is no functional harm in using any other Java element that works. Archibus operates within the Java Enterprise Edition (JEE) environment and can make full use of any of its components. However, if you use APIs other than those listed above, be aware you may need to alter the Java to make these APIs execute properly in future versions of the core.

Common Workflow Rule Dependencies

Do not change the Workflow Rules that are common to the entire set of domains (for example, ab-products\common ). If you do change the common Workflow Rules, then you can update the Archibus core using the Deployment Packager, but not individual domains. See Upgrading Only Specific Archibus Web Central Domains for more information.