Adaption of old AMLEgine

Select the appropriate migration strategy

At first, the suitable migration strategy has to be decided. There are two possible migration strategies. The selection of the appropriate migration strategy depends on the code to be migrated. If there are large dependencies on the underlying memory model of the Altova Engine, which is based on the .NET System.Xml namespace, it might be better to use the adaption features, provided in the new Aml.Engine.Adapter namespace. If you mainly use the base classes of the CAEX_ClassModel namespace, direct migration can take place without using the special adapter classes, to avoid getting the obsolete warnings during building.

Direct Migration

• The namespaces, defined in the AMLEngine v3.xx have to be replaced: Replace CAEX_ClassModel with Aml.Engine.CAEX and Aml.Engine.CAEX.Extensions. Replace AMLEngineExtensions with Aml.Engine.AmlObjects and Aml.Engine.AmlObjects.Extensions. To use special services like FastAccess Methods, Split and Merge or Document validation the additional namespace Aml.Engine.Services has to be included. The Schema Transformation service, which can be used to transform AutomationML documents from version 2.0 to version 2.10 (based on CAEX3.0) is also provided in the Aml.Engine.Services namespace.

• All Altova namespaces must be removed, because the AMLEngine2.1 is not generated using Altova software anymore. If Altova types are used in your code these types must be replaced manually. The formerly used base class for all CAEX objects was Altova.Xml.TypeBase. This class is replaced with the class CAEXWrapper. Any usages of member element types like MemberElement_InternalElement in iterations or declarations can mostly be replaced by a var declaration or the concrete element type like InternalElementType. The CAEX_ClassModel.xs.anyType has to be replaced with the string type or – in the accessors of AdditonalInformation elements with the object type. The underlying memory model in the Altova based classes depends on the System.Xml namespace. The AMLEngine2.1 is based on the System.Xml.Linq namespace. If there are dependencies in your application code to the System.Xml namespace replace and change these dependencies using the System.Xml.Linq namespace. In most cases, you can try to substitute the classes:

  • XmlNode => XElement

  • XmlAttribute => XAttribute

  • XmlDocument => XDocument

• The old engine always uses classes as wrappers to access XML attributes. In the new engine, attributes like ID or Name are directly accessible as value types. Also XML elements representing single values like Description are accessible as value types. The consequence is, that there exist no member accessors for these CAEX attributes and elements. A formerly coded assignment like element.Name.Value=”IE” has to be replaced by element.Name=”IE”. An existence test like element.Name.Exists() has to be replaced by !string.IsNullOrEmpty(element.Name).

• Access to specific AMLObjects and specific AMLAttributes has been modified. The new engine doesn't mix AMLAttributes with basic CAEX classes. As an example you cannot access a FrameAttribute using a defined property of an InternalElement. To access specific AML Attributes or AML Objects implicit or explicit type conversion methods are provided. The SystemUnitClass defines this implicit type conversion operator: for the ObjectWithAMLAttributes defining all specific Attributes. To access a FrameAttribute of an InternalElement, use a Type cast like: ((ObjectWithAMLAttributes)internalElment).FrameAttribute.