TransacXML Other Uses

Introduction    Implementing    Other Uses    Parts    Tutorial    Glossary

Exporting Data From a Database

When exporting data from a database into an XML document the structure of the XML document is modeled in Plex using the WsyXml objects XmlElement, XmlRepeatingElement, ElementField, RepeatingElementField, and AttributeField. The XML structure defined in Plex is called a model of the XML document.
Please refer to Implementing Import and Export of XML Document in the tutorial for further details.

The data from the database are represented in the model with fields inheriting from either ElementField, RepeatingElementField, or AttributeField. However, in some situations it is preferable to reuse the existing database fields for the XML document model in Plex, e.g. when the database is very complex and contains many fields. This way a very close relation is maintained between the database model in Plex and the XML structure.

To use database fields in the XML structure model for a specific element (MyXmlElement) enter the following triples in the Plex model:

If the database field names does not follow the XML Standard (e.g. if a name contains spaces) use the option UseImplementationNameForFields. Then the field implementation name will be used as the element name instead of the field name.

Performing Other Data Processing

In real world applications there is not always an one-to-one match between the elements defined in the XML document structure and the data structure of the application database.  Often, processing needs to be defined which walks through the data being read. For instance, the values of certain fields in the application database might depend on other data read from the XML document. 

In some cases it is best to resolve any derived database field values on-the-fly as data is being read from the XML document. In other situations the best approach is first to populate the application database with as many data as possible, and then resolve the values of the rest of the database fields in subsequent processing.

Inheriting from Untyped Abstract Fields 

When modeling the XML structure into triples and objects in the CA Plex model, the fields thus created inherit from either of the abstract fields AttributeField, ElementField, or RepeatingElementField. These three abstract fields in turn indirectly inherit from the XmlDataString. This way, all fields created as part of the  Implementation process will have the common ancestor XmlDataString, which by inheritance has the field type Character. 

In some cases it is desirable to avoid inheritance from XmlDataString. This is the case when fields in the model created via the implementation guide should have the same types as their application database counterparts. 

Three extra abstract fields AttributeFieldUT, ElementFieldUT, and RepeatingElementFieldUT have been provided. These three fields, which are ancestors of AttributeField, ElementField, and RepeatingElementField respectively, do not inherit from XmlDataString. Therefore, fields inheriting from either AttributeFieldUT,  ElementFieldUT, or RepeatingElementField have no field type.

A field being created as part of the modeling  process should inherit from either the appropriate un-typed abstract field (e.g. AttributeFieldUT) or the appropriate typed abstract field (e.g. AttributeField), depending on the application being built.

When a field inherits from the un-typed fields, remember to specify a type for the inheriting field.

Special case: Using comma as decimal separator

The XML standard only allows the use of a point (".") as decimal separator. This can give problems when coding for a locale where a comma is used as the decimal separator when inheriting from ElementFieldUT and a numeric database field which has a non-zero value for the decimal places triple (e.g. the Plex Price field).

The problem is that:

• The SingleFetch will Cast the value containing the decimal point to a field that expects a comma as decimal separator.
• The InsertRowDangling/InsertRow functions will cast a numeric field containing a decimal comma to a the value that will be written to the XML document. This means that a numeric value in the document will contain a comma, which is invalid and will lead to an error in any schema validation that might be done on the resulting document.

This means that you must handle the conversions between decimal commas and decimal points in the case where your database fields contains commas as decimal separators.

The example model shows a simple implementation of how you can handle this situation. The relevant changes can be found in the functions SingleFetch and InsertRowDangling under the Test XMLElement entity.

Note that a special version of the abstract Replace function is used (function name: DomReplace). This function has the standard Replace functionality - but by letting the function inherit from DomServerExternal, you ensure that it follows the programming language of the SingleFetch and InsertRowDangling functions.

Type Conversion

Transferring data from fields created as part of the modeling process into their application database counterparts may in some situations be non-trivial.

For instance, when retrieving a date from an XML document into a corresponding date field, the string format of the date might not be the same as that of the corresponding database date field. In this case, type casting by means of the Cast statement is not feasible. 

In such cases of non-trivial type casting, the Websydian developer should add the code necessary to carry out the appropriate type casting, instead of using Cast.

Long Names

TransacXML uses entities and fields to reflect XML elements and attributes in the CA Plex model. The name of the entity or field reflecting either an element or attribute in the XML document is the same as that of the XML element/attribute. However, in CA Plex the maximum length of an object name is 32 characters. Therefore, when the DTD of the XML document to be read contains elements or attributes with names longer than 32 characters, extra inheritance triples have to be added as part of the modeling process. 

Letting entities corresponding to XML elements inherit from the abstract LongName entity yields a source code object LongName scoped to the inheriting entity. Similarly, letting fields corresponding to XML elements and attributes inherit from the abstract LongName field yields a source code object LongName. 

The real (long) name of the entity/field can now be specified in the large property of the LongName source code object. For details on how exactly to specify the long name, refer to either the section about long name entities or the section about long name fields in the Implementation Guide.

Defining Null Value Literals

The SingleFetch and FlatView functions will return null values in the fields whose corresponding elements/attributes are not present in the XML document being read. This is useful when attributes or simple elements are optional.

Through their (indirect) inheritance from NullValue, the fields reflecting XML simple elements or attributes scope a value Null which by inheritance contains the empty string as its literal.

The inherited Null value literal of a field can be overridden by a new literal. When the corresponding element/attribute is not found in the XML document being read, the SingleFetch and FlatView functions will return the specified null value string in the relevant field. For further information, refer to the section about null values in the Implementation Guide.

Simple Element with Attributes

An example of the structure that is sometimes termed "simple element with attribute":

<MyValue Currency="USD">1000</MyValue>

As of Websydian version 6.1, you can model this using the ComplexValue field.

Create Document Definitions

When designing XML documents it is often a requirement to describe the structure of the XML document using either DTDs or schemas.

With TransacXML it is easy to create a DTD or schema representation of the XML model in CA Plex. The only requirement is that all of the XMLElement entities in the document must inherit from the XMLElementWithServiceFunctions entity to be able to create a schema for the document.

For more details concerning the creation of DTDs see CreateDTD.

For more details concerning the creation of schemas see the Create Schema Guide.

Load Document from String