• Overview
• 
• Features
• 
• FAQs
• 
• Levelset History
• 
• Tutorials
• 
• Register
• 
• Download
• 
• Brochure (PDF)

FAQs

Advantage Gen supports the generation of an XML format as an alternative for the proxy interface. This is handy if you want to write your own clients outside of Gen to talk to the proxies. It doesn't help you though if you need to create adhoc transactions in XML format to be sent to external systems, read or written to files for interfacing with legacy or external systems. XML Composer™ enables Gen applications to read and write any kind of data in XML, for any purpose.

DOM and SAX parsers provide two different methods for parsing XML data, each with their own strengths. However, in both cases, the logic which uses these methods for parsing must be written by the developer. With XML Composer™, a dedicated, compiled EAB is generated from design specifications for this task, and no parsing logic needs to be written by the developer.

No, XML Composer™ does not use these parsers in any way, nor does it require that the developer be familiar with them.

Yes, the developer needs basic familiarity with XML in order to work with XML Composer™ effectively. However, the developer does not need to write parsing code.

XML Composer™ can generated XML handler EAB's in either COBOL or C language. Java is not available at this time.

In addition to the well-defined rules of XML, it provides a dictionary for standardization of XML element and attribute names for each Advantage Gen Entity-Attribute combination.

Yes, the product can generate and XML structure from the EAB's views, or the developer can create any XML structure using the editor provided in the tool.

Yes, XML Handler definitions are saved as XML files, and can be easily copied or moved between workstations, and then accessed from another XML Composer™ installation on any other workstation. Or, the XML Handler definition files can be stored on a network drive and accessed from XML Composer™ on any workstation that has access to that drive.

A solution would be to design separate "reader"s to determine the type of document, and call them before calling the actual reader.

There is one rule about matching repeating elements: the parent repeating structure must be mapped before being able to map the sub-elements. In this case the status line displays "Parent repeating struct must be mapped first".

The enabling/disabling of map/unmap toolbar items depends on which pane you clicked last. But still, the enabled status of items on the toolbar and the right click menu must be identical.

If you are runnning a demo version, the code generator produces code for only about 10 xml nodes including element/attribute/text nodes. So it won't read in or write out passed the limit.

The XML buffer can be split accross group view occurences without a specific boundary.
So, for a really long message, you can use an XML_BUFFER attribute of 4000 characters repeating,
for example 100 times...
And then, you can read lines from a file and populate the group view before calling the "reader".

It's possible to create or parse node names with any namespace prefixes. XML Reader expects the namespace prefix to be same as defined in the XML design.

XML Thunder ™ will allow you to specify certain validation rules for the structure of the document and the format of the data. At runtime the XML Reader will verify these rules. For example, you can specify if a node is 'optional' or not. If the reader finds a mandatory node missing, it will throw an exception. Another example is, you can specify if a node is 'extensible'. If the reader finds an undefined node, it will check if parent node is defined as 'extensible'; if not, it will throw an exception, otherwise it will ignore the unknown node.