Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/25—Integrating or interfacing systems involving database management systems
  • G06F16/258—Data format conversion from or to a database
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99932—Access augmentation or optimizing
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching
  • Y10S707/99934—Query formulation, input preparation, or translation
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99941—Database schema or data structure
  • Y10S707/99943—Generating database or data structure, e.g. via user interface
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99951—File or database maintenance
  • Y10S707/99952—Coherency, e.g. same view to multiple users
  • Y10S707/99953—Recoverability

Definitions

• the present invention relates to a system and method for translating information, to or from, an hierarchical information system.
• Legacy systems are systems that support business function, many of which have been in use for many years. These systems usually store information, and communicate with each other, using non-hierarchical information systems, such as linear strings (i.e. legacy messages).
• non-hierarchical information systems such as linear strings (i.e. legacy messages).
• Hierarchical system typically store information in a tree structure of objects, each object having specific attributes, and where each object may be linked to other objects.
• MERCATOR for example, could be used if first the object model were translated into a standard, predictable data stream. However, the effort to translate the object model into this intermediate format is similar to the effort required to translate the object model into a form directly usable by the legacy system.
• MERCATOR is implemented as a single-threaded DLL (Dynamic Linked Library) in Windows NT, which may have an adverse impact on overall system performance and throughput.
• a first aspect of the invention is a method for translating to ana ⁇ rom an hierarchical information system, comprising identifying a non-hierarchical information system containing information stored in a non-hierarchical manner; developing a translation map that identifies organizational and content based rules for translating the non-hierarchical information into an hierarchical information system; and translating the non-hierarchical information for storage into the hierarchical information system according to the rules for translating.
• a second aspect of the invention is computerized method for translating to and from an hierarchical information system.
• a third aspect of the invention is a system for translating to and from an hierarchical information system, comprising means for identifying a non- hierarchical information system containing information stored in a non- hierarchical manner; means for developing a translation map that identifies organizational and content based rules for translating the non-hierarchical information into an hierarchical information system; and means for translating the non-hierarchical information for storage into the hierarchical information system according to the rules for translating.
• a fourth aspect of the invention is a system for translating to and from an hierarchical information system, comprising a first computer system having a memory for storing information in an hierarchical information system; an interface coupled to the first computer system, the interface having means for identifying a non-hierarchical information system containing information stored in a non-hierarchical manner, developing a translation map that identifies organizational and content based rules for translating the non-hierarchical information into an hierarchical information system, and translating the non- hierarchical information for storage into the hierarchical information system according to the rules for translating; and a second computer system coupled to the interface, the second computer system having a memory for storing information in a non-hierarchical information system.
• a fifth aspect of the invention is a method for translating to and from an hierarchical information system, comprising translating data from an object model into a legacy message.
• a sixth aspect of the invention is a method for translating to and from an hierarchical information system, comprising translating data from a legacy message model into an object.
• a seventh aspect of the invention is a method for translating to and from an hierarchical information system, comprising identifying an hierarchical information system containing information stored in an hierarchical manner; developing a translation map that identifies organizational and content based rules for translating the hierarchical information into an non-hierarchical information system; and translating the hierarchical information for storage into the non-hierarchical information system according to the rules for translating.
• An eighth aspect of the invention is a computerized method for translating to and from an hierarchical information system, comprising identifying an hierarchical information system containing information stored in an hierarchical manner; developing a translation map that identifies organizational and content based rules for translating the hierarchical information into an non-hierarchical information system; and translating the hierarchical information for storage into the non-hierarchical information system according to the rules for translating.
• a ninth aspect of the invention is a system for translating to and from an hierarchical information system, comprising means for identifying an hierarchical information system containing information stored in an hierarchical manner; means for developing a translation map that identifies organizational and content based rules for translating the hierarchical information into a non-hierarchical information system; and means for translating the hierarchical information for storage into the non-hierarchical information system according to the rules for translating.
• a tenth aspect of the invention is a system for translating to and from an hierarchical information system, comprising a first computer system having a memory for storing information in a non-hierarchical information system; an interface coupled to the first computer system, the interface having means for identifying an hierarchical information system containing information stored in an hierarchical manner, developing a translation map that identifies organizational and content based rules for translating the hierarchical information into a non-hierarchical information system, and translating the hierarchical information for storage into the non-hierarchical information system according to the rules for translating; and a second computer system coupled to the interface, the second computer system having a memory for storing information in an hierarchical information system.
• Figure 1 shows the application architecture and components of an interface.
• Figure 2 shows the application architecture and components of another interface.
• Figure 3 is an illustration showing the transformation of attributes from an hierarchical system to a non-hierarchical system, and the reverse.
• the present invention includes an interface that supports the specific data transformation requirements of translating information from a specific hierarchical system (also referred to as an object model), such as XML data, into a non-hierarchical system, such as linear strings (i.e., custom legacy messages), or into a different specific hierarchical system.
• the interface performs the mapping, lookups and derivations necessary to format legacy messages in a manner consistent with the legacy applications.
• the application architecture and components of the interface are shown in Figure 1.
• the components, and additional optional components, are shown in Figure 2.
• the interface may be software implemented on a general purpose computer, or may be dedicated hardware, or a combination thereof.
• each individual component may be software implemented on a general purpose computer, or may be dedicated hardware, or a combination thereof. All components of the interface are described first, followed by a section describing the application flow. A subsequent section includes a summary of the data transformations supported by the interface.
• the interface 1 includes a coordinator 2, a searcher 4, and a writer 5. Also shown in the figure are a map file 3, a toolkit 7, a technical architecture framework 8, a legacy system
• Figure 2 schematically shows another server 12 that may use a different object model, a toolkit 7' for this different object model, a searcher 4' for this different object model, a second legacy system 9, a ruler 10, and a responder 11.
• the map file defines the attributes that are to be obtained from the object or IDL (interface definition language) structure and used in the construction of legacy messages.
• the map file defines the attribute location (in each object in the object model), the format of the attribute values as they should appear in the legacy message, and the order in which the attribute values should appear in the legacy message.
• the map file may be viewed as a series of commands, which instruct the coordinator on how to construct the legacy message from the objects.
• the coordinator controls the process of reading the map file and using the searcher and optional ruler to obtain information to send to the writer.
• the coordinator orchestrates the translation, resolution, derivation, message construction, and message delivery processes.
• the coordinator includes a map interpreter, which interprets the commands in the map file.
• the coordinator is developed using JAVACC, a SUN MICROSYSTEMS product. Given a grammar that describes the syntax used in the map file, JAVACC can be used to create the coordinator and allow map files to contain commands that access the searcher, ruler and writer.
• the searcher provides an interface that is used by the coordinator and the ruler to obtain attribute information within each object.
• the coordinator uses commands from the map file to translate data (attributes) from an object model to the legacy system attributes.
• the coordinator executes rules as they are read from the map file.
• the coordinator uses the searcher to locate attributes used in a command. For example, if a command requires a calculation using attributes in an object, the coordinator would use the searcher to obtain these attributes and perform the calculation.
• the writer formats attributes passed by the coordinator and uses them to the construct the message that is sent to the legacy system.
• the optional responder returns confirmations from the legacy system to the system that initiated the transaction. If the initiating system is a server, the responder converts the legacy response to an XML message. For example, systems using the IDL interface will receive responses in the form of IDL structures.
• a request is made of the interface via a CORBA IDL interface.
• the interface Upon receipt of the request, the interface creates a new coordinator passing either the XML string or the IDL defined structure, and starts the coordinator.
• the coordinator creates a new searcher, passing in the object model to be searched.
• the coordinator creates a new ruler, passing in the previously created searcher. The ruler will use the searcher if necessary during execution of its rules.
• the coordinator then requests the target system identifier (e.g. legacy system) of the searcher.
• the coordinator will create a new writer, passing the target system identifier.
• the target system identifier is required so that the writer deposits the constructed message on the appropriate legacy queue.
• the coordinator requests the map file of the map loader. If the map loader has the requested map file cached, the memory-resident map file is returned to the coordinator. If the map is not loaded, the map loader loads it and returns it to the coordinator.
• the map loader is an optional component that only carries out this function, and advantageously prevents the need to reload map files that have been previously loaded.
• the coordinator (via the map interpreter) reads the map file and determines that an attribute from an object model is needed.
• the coordinator (via the map interpreter) makes a request of the searcher to get the needed attribute information.
• the searcher finds and returns the requested attribute.
• the coordinator tells the writer to add the obtained attribute information to the message under construction.
• the writer formats the attribute information as defined by the map file and then appends the formatted attribute to the message under construction.
• the coordinator reads the map file and may encounter a command that invokes a rule. In this case, the coordinator makes a request of the ruler to execute the specified rule.
• the ruler makes a request of the searcher to get, if necessary, attribute information needed during execution of the rule.
• the searcher finds and returns the requested attribute.
• the coordinator tells the writer to add the obtained attribute information to the message under construction.
• the writer formats the attribute information as defined by the map file and then appends the formatted attribute to the message under construction.
• the coordinator tells the writer to complete the message under construction and to send it to the appropriate legacy system.
• the writer makes a request of the technical architecture (also referred to as an underlying architecture) to package the message, for example, as a queued message (for IBM MQ Series, or MICROSOFT MSMQ), and deposit it on the appropriate legacy system queue.
• the technical architecture creates a new message using the application-defined message content and deposits the message on the appropriate legacy queue.
• the memory address of each object is retained as a legacy message is constructed, reducing the time necessary for the reading of additional attributes needed to construct the legacy message.
• Figure 3 is an illustration showing the transformation of attributes (data) from an hierarchical system (left) to a non-hierarchical system (right), which in this illustration is a linear string.
• the individual attributes of the objects in the hierarchical system are represented by letters, while attributes in the linear string are represented by numbers.
• the interface can read the attributes of the objects, and translate them (from letters to number in this illustration), and write them into a linear string.
• the linear string may then be passed to a legacy system. As illustrated, the reverse is also possible.
• an optional response is returned to the technical architecture via a message queue.
• the technical architecture retrieves the message from the queue and creates an optional responder.
• the technical architecture passes the data portion of the message to the responder and instructs the responder to execute the process of returning the response.
• the responder creates an object and populates the object with data (attributes) expected by the server.
• This data includes attributes such as a group identifier that is generated by the legacy system, for example group enrollment of an insurance plan.
• the responder creates an XML message.
• the responder queries the Proxy Pool Manager for a secure proxy to the appropriate server.
• the responder uses the secure proxy to send the XML message response to the server.
• the application architecture is designed to handle the following categories of data transformations: simple mapping, constants, code lookups, derived rule, multiple source locations (plan modeling), and rate information fields (when the data contains information relating to a service, such as insurance).
• Simple mapping means mapping fields that can be mapped directly from an object attribute to a legacy message field without any additional mapping logic.
• Constants are fields in the legacy message that are required and are always populated with the same information. For example, a field that describes the type of transaction would always contain an 'E' for electronic since the framework is an electronic means of creating the message.
• Code lookups are fields that require a translation from how an attribute is described in the hierarchical system, and how the same attribute is described in a legacy message.
• a derived rule is a field that is extracted from the object model and translated to the legacy message fields based on rules (such as business rules) as defined in the ruler.
• Source attribute may be located in different areas of the Vendor object model.
• Rate information fields are fields that are a specialized form of derivation rules that use name/value pairs. Unlike basic derived fields that rely on class names to find attributes in the object model, data values are used to search for rate attributes in the object model.
• the map file contains commands, which are defined in the order that the legacy message needs to be constructed.
• the data from hierarchical information system may be sent to the interface from a specific vendor's server, where the vendor may be the same or different from the owner or user of the legacy system. Furthermore, multiple vendors, each having one or more servers, each containing data in one or more hierarchical systems, may send data to the interface.
• the interface may translate the data into a non-hierarchical system, such as a legacy system, or a different hierarchical system. Examples of hierarchical systems include XML and ChannelPoint (CP XML). Specifically, the interface may carry out one or more of the following:
• a toolkit is used to interpret the hierarchical system data exported from a server to the interface.
• Each toolkit may be specific to each hierarchical system, for example the MICROSOFT XML toolkit is specific to XML.
• the toolkit On receipt of the exported hierarchical system data stream, the toolkit creates a copy of the original object (or objects). Data is then read out of this object (or objects) for translation into a custom legacy message.
• This class is instantiated upon a Vendor call to
• a Searcher object is created that will be used to browse the Vendor object model.
• a Writer object is created that will construct the translated message for the target legacy system.
• a static MapLoader object is used to load and parse the appropriate map file that contains the legacy system translation.
• VInterpreter object (Visitor) is created to perform that actual interpretation of the loaded map file.
• a flavor of the Searcher class is instantiated based on whether the "UHCSearcher" switch has been set, either on the command-line or within the configuration INI file. If the switch has been set to 'on', a UHCSearcher object is instantiated; otherwise, a CPSearcher object is instantiated.
• the target legacy system is determined. That value is used to retrieve information on the appropriate queue to which the legacy system message will eventually be written.
• the fully-formatted header of the legacy message is constructed and passed as a parameter to a new instantiation of a Writer object.
• a Ruler object is instantiated, receiving a reference to the searcher object as a parameter.
• the appropriate map filename that will be used for message translation is retrieved from
• ConfigurationManager dpararn xmlDoc_bytes XML document that will be passed to the searcher.
• dparairt Exception Exception is thrown if a SearchException or Throwable is encountered on an attempt to instantiate the searcher object or determine the target legacy system.
• An Exception is also thrown if a FormatException is encountered during construction of the legacy system message header, if a WriterException is encountered on an attempt to instantiate the
• ⁇ targetSystem m_searcher .getTargetSystem( ) ,- // Build message header from (String.] Jheaderlnfo using Formatter ob ect
• Formatter f new Formatter () ;
• a value for the max number of interpretation errors allowed is retrieved from ConfigurationManager .
• a VInterpreter visitor object is instantiated with the filename of the map file being used for interpretation, references to the searcher, writer, and ruler objects, and a value for the max number of interpretation errors allowed passed in as parameters.
• the root node of the AST constructed from the map file is retrieved from the MapLoader object.
• the root node receives the visitor object and the legacy system message is constructed. If interpretation was completely successful, the legacy system message is deposited on the appropriate outgoing queue via the writer object.
• Exception is thrown if a VisitorException is encountered during the visitor object's traversal of the AST. Exception is also thrown if a
• log ( "VInterpreter was accepted by the AST" , ogController . DEBUG3 ) ; if (m_writer . sendMsg( ) ) m_logger. log ( "Legacy message was successfully placed on queue” , ogController. DEBUG3 ) ; else m_logger. log ( "Legacy message could not be placed on queue” , LogController .DEBUG3) ; ⁇ catch (VisitorException e) ⁇ m_logger.log (e. getDetailMessages () , LogController . ERR0R3 ); // multiple messages m_logger. log ( "Leaving Coordinator: : run” , LogController.
• BENCHMARK3 throw new Exception ( e. getDetailMessages () ) ; ⁇ catch (Exception e) ⁇ m_logger.log( e, LogController . ERR0R3 ); m_logger.log ("Leaving Coordinator: :run” , LogController. BENCHMARK3) ; throw new Exception ( e. getMessage ( ) ) ,- ⁇ catch (Throwable t) ( m_logger.log( t, LogController .ERR0R3 ) ; m_logger. log ( "Leaving Coordinator: -.run” , LogController.BENCHMARK3) ; throw new Exception ( t .getMessage ( ) ) ; ⁇ m_logger. log ( "Leaving Coordinator: : run", LogController.BENCHMARK3) ;
• This class is an implementation of the abstract Searcher class. It performs searches of the Vendor object model (as defined by the XML document passed to the constructor) through utilization of the Vendor Toolkit.
• Root objects of the Vendor object model as defined by the XML document. */ private Vector _rootObjects null;
• AttributeContainer _currAC null
• a byte array representing an XML document is converted to a String and then parsed by the Vendor toolkit, resulting in a Vendor object model.
• the reference to the object model's root objects is set.
• _rootObjects _xmlin.getRootObjects ( ) ; // It would be nice of XMLload took a byte[].
• long loadEnd System. currentTimeMillis () ;
• ⁇ retStr findAttribute (str) ,- ⁇ return retStr; ⁇ //$DEBUG_END
• the cache is checked to see if an ⁇ code>AttributeContainer ⁇ /code> object exists for the given object path. If so, the object is retrieved and the value from its ⁇ code>AttributeDescription ⁇ /code> is returned. Otherwise, the object path is tokenized on the period (.) character.
• Each token is checked to see if it is an occurrence. If it is an indexed occurrence, the number of ⁇ code>AttributeContainers ⁇ code> in the collection is returned. For a non- indexed occurrence, the i ⁇ th
• ⁇ code>AttributeContainer ⁇ /code> is set to the current node. Otherwise, the reference value contained within the current node ( ⁇ code>AttributeContainer ⁇ /code>) is set to the current node .
• Vendor object model This attribute can be in one of the two following forms : ⁇ ul>
• ⁇ li>'n' is the element number in the collection to reference.
• ⁇ li>"LastName is the attribute to obtain (for the nth element of the collection) in the Vendor object model.
• Nested collections would look like "Case.Member [n] .Dependant [n ' ] .Age"
• I l l should be getting a well formed string, so it shouldn't matter.
• Vector v (Vector) _currAC . getAttribute ( occurrenceName ) ; // Vector of member variables
• currObject AttributeDescription ad _currAC.getAttributeDescription (currClassName) ;
• Types typeString(ad. getTypef ) ) ) ) ;
• the ⁇ code>AttributeDescription ⁇ /code> object is retrived from the current ⁇ code>AttributeDescription ⁇ /code> object. Based on the type of the description object, its value is converted to a string (if necessary) and returned as a string.
• This class takes the value and the format type of an attribute and returns a formatted string.
• String type values are padded with spaces and numerical type values (i.e. float and integer) are padded with zeros.
• Non-padded string type values i.e. "n" are not padded at all, regardless of the &ltwidth&gt specifier. ⁇ p>
• This method formats the attribute as defined by format specifier.
• This method validates the format specifier. It verifies that the format complies with the format specification definition. Flags for value type, forced-uppercase, and justification are set. For string and integer types, the width value is set and for the float type, the width values of the integer and decimal sides are set.
• This method formats a string type using the justification and width of the format specifier as set in ⁇ code>validateFormatStructure ( ) ⁇ /code> . If the format specifier was set to force all letters to uppercase, the letter contents of the return value are all set to uppercase.
• This method formats an integer type using the width of the format specifier as set in ⁇ code>validateFormatStructure () ⁇ /code>. If the string to format represents a negative number, the negative sign is not considered in width padding.
• This method formats a float type using the width and precision of the format specifier as set in ⁇ code>validateFormatStructure ( ) ⁇ /code>. If the string to format represents a negative number, the negative sign is not considered in width padding.
• This method formats the string and does not add any padding characters . If the format specifier was set to force all letters to uppercase, the letter contents of the return value are all set to uppercase.
• This method performs finalization on the Formatter Object
• Class represents an exception thrown by the lexer.
• curLexState lexical state in which this error occured
• This class is responsible for loading, retaining, and handing out the abstract syntax trees constructed from various translation maps.
• the fully-qualified filename of a map file is used as the key in checking whether an AST already exists for the specified map file. If found in the collection, the root node of the AST is returned. Otherwise, the MapParser class is reinitialized using an input stream based on the map file.
• a VInterpreter visitor object is instantiated and its syntax check mode is set to ⁇ code> true ⁇ /code>. The visitor object then visits the root node of the AST resulting from the initialization of the MapParser object. If no parser or surface-level syntax errors are encountered by the visitor, the AST is added to the AST collection and the root node of the
• VInterpreter v new VInterpreter (mapFile,null, null,null,maxErrors) ; // check the syntax v.setSyntaxCheckMode (true) ; m_logger. log( "MapLoader: : getMap interpreting map for syntax BEGIN” , LogController. BENCHMARK3) ; root . j tAccept (v, null); m_logger. log( "MapLoader: : getMap interpreting map for syntax END" , LogController. BENCHMARK3) ; ⁇ catch (ParseException e) ⁇ m_logger. log( e, LogController. ERR0R3 ); m_logger.
• This class contains translation rules that could not be done using the map.
• ⁇ m_searcher aSearcher
• This method begins the execution of a custom rule identified by a rule name. First, it verifies the name of the rule is not empty, then it calls the method to execute the rule.
• This method executes a custom rule identified by a rule name.
• the rule name must match one of the names in the list of rules declared in the Ruler class. If the rule does not exist, it throws the RulerException.
• avg_age sum_age / dep_count
• avg_age_str String.valueOf (avg_age)
• return avg_age_str ⁇ private String rule2 ( ) ⁇ return null; ⁇
• This method performs finalization on the Ruler Object
• This class represents an exception thrown by the Ruler.
• This abstract class defines the interface for an XML searcher class.
• log "Searcher is about to get garbage collected. LogController. DEBUG3) ;
• This class represents an exception thrown by the Searcher object.
• JJTree Do not edit this line. SimpleNode. Java */ package com.uhc . iframework. runtime .mapping;
• This class acts as the parent class for all node classes comprising the AST object model.
• SimpleNode is actually a class generated by JJTree. This particular SimpleNode class has been slightly modified for use with the VInterpreter object.
• Node c [ ] new Node [i + 1] ;
• Class represents an exception thrown by the token manager.
• curLexState lexical state in which this error occured
• This class is an implementation of the abstract Searcher class. It performs searches of the MS XML object model (as defined by the XML document passed to the constructor) through utilization of the MS XML library.
• An input stream is created from the byte array parameter and used to populate the object model container.
• Method iterates through the object model, beginning with the root node, by tokenizing on the dot (.) character. For each iteration, the token is checked for whether it is an occurrence.
• the object identifier is a count object identifier, the number of children nodes is returned, otherwise the i ⁇ th child node becomes the current node, as specified by the occurrence index.
• StringTokenizer st new StringTokenizer (path, ":") ; if (s . countTokens ( ) > 0) ⁇ // Get path to object model attribute
• ⁇ rootObject objPath .nextToken ( ) . trim( ) . replace ('/','.');
• This class represents a Visitor object for the abstract syntax trees constructed by MapLoader. It acts as the interpreter for the mapping files and coordinates between the Searcher object. Ruler object, and the Writer object to build a String-based message that will be sent to a legacy system via the technical architecture. ⁇ p>
• VisitorException Sets the map file name and initializes the VisitorException collection.
• the collection will use the VisitorException' s default value for the max number of exceptions it will contain.
• the collection will contain a max number of exception as specified by the ⁇ code>maxErrors ⁇ /code> parameter.
• the associated primitive value is returned.
• VisitorException is thrown if the value contained by the Object cannot be converted to an integer primitive.
• This method is called in lieu of an operation on the Format object when the visitor' s reference to the Format object is ⁇ code>null ⁇ /code> .
• This method is called in lieu of an operation on the Ruler object when the visitor' s reference to the Ruler object is ⁇ code>null ⁇ /code>.
• This method is called in lieu of the Searcher: : getCollectionCount ( ) method when the visitor's reference to the Searcher object is ⁇ code>null ⁇ /code> .
• This method is called in lieu of the Searcher: : findAttribute ( ) method when the visitors' s reference to the Searcher object is ⁇ code>null ⁇ /code> .
• This method is called when a Visitor object is accepted into an ASTCompilationUnit object. All children nodes are asked to accept the Visitor object.
• ⁇ exception VisitorException is thrown if, during the traversal of the AST, at least one syntax or runtime error was encountered.
• ⁇ data node. childrenAccept (this, data) ;
• This method is called when the Visitor object is interpreting a variable declaration.
• the identifier is added to the symbol table for future reference, along with its value.
• This method is called when the visitor is interpreting a variable assignment.
• the symbol table is updated accordingly.
• This method is called when the visitor is interpreting a logical OR expression.
• ⁇ boolean vail fetchBool (node. jjtGetChild(O) .jjtAccept (this, data),
• This method is called when the visitor is interpreting a logical AND expression.
• Boolean object public Object visit (ASTAndNode node. Object data) throws VisitorException
• ⁇ boolean vail fetchBool (node. j jtGetChild(O) .jjtAccept (this, data),
• ⁇ code>fetchInt () ⁇ /code> or ⁇ code>fetchBoolean ⁇ /code> is called to get integer values or boolean values for both of the node's children, depending on whether integers or booleans are being compared, resectively. The result of the equality operation is returned.
• Object objVall node, jjtGetChild(O) .jjtAccept (this, data)
• This method is called when the visitor is interpreting a logical non- equality expression.
• ⁇ code>fetchInt ( ) ⁇ /code> or ⁇ code>fetchBoolean ⁇ /code> is called to get integer values or boolean values for both of the node's children, depending on whether integers or booleans are being compared, resectively. The result of the non-equality operation is returned.
• ⁇ param node ASTNENode object reference ⁇ param data Arbitrary data contained in an Object.
• Object objVall node. jjtGetChild(O) .jjtAccept (this, data) ;
• ⁇ boolean vail fetchBool (node . j j tGetChild( O) . j j tAccept ( this , data)
• This method is called when the visitor is interpreting a less-than expression.
• This method is called when the visitor is interpreting a greater-than expression.
• This method is called when the visitor is interpreting a less-than-or- equal expression.
• This method is called when the visitor is interpreting a greater-than-or- equal expression.
• This method is called when the visitor is interpreting an integer addition expression.
• This method is called when the visitor is interpreting an integer subtraction expression.
• This method is called when the visitor is interpreting an integer multiplication expression.
• This method is called when the visitor is interpreting an integer division expression.

Landscapes

• Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Theoretical Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Information Transfer Between Computers (AREA)
• Computer And Data Communications (AREA)
• Document Processing Apparatus (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (2)

Family

ID=23905662

Family Applications (1)

Country Status (6)

Cited By (1)

Families Citing this family (75)

Citations (8)

Family Cites Families (7)

• 2000
  • 2000-01-07 US US09/479,840 patent/US6523042B2/en not_active Expired - Lifetime
  • 2000-12-29 JP JP2001552216A patent/JP2003523004A/ja active Pending
  • 2000-12-29 EP EP00990967A patent/EP1257916A4/en not_active Ceased
  • 2000-12-29 AU AU30772/01A patent/AU779817B2/en not_active Expired
  • 2000-12-29 WO PCT/US2000/035673 patent/WO2001052063A1/en not_active Ceased
  • 2000-12-29 CA CA2396263A patent/CA2396263C/en not_active Expired - Lifetime
• 2002
  • 2002-12-20 US US10/327,622 patent/US7072903B2/en not_active Expired - Lifetime

Patent Citations (8)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events