GRM and its subclasses

A GRM is a Generalized Record Manager which can be created, accessed and destroyed by the Java API programmer. It provides a means to make use of the parsing facilities of the system, and set or retrieve fields within a message using logical names.

The supported subclasses of GRM are:

  • FrlM

    A Fixed Record Layout Manager that permits fields within a record to be set or retrieved by name. Similar to other GRM objects, an FrlM can be constructed from a Message and a new Message can be created from an FrlM.

  • VrlM

    A Variable Length Record Layout Manager that permits fields within a record to be set or retrieved by name. Similar to other GRM objects, a VrlM can be constructed from a Message and a new Message can be created from a VrlM.

  • HrlM

    An HRL Record Layout Manager that permits fields within a record to be set or retrieved by name. Similar to other GRM objects, an HrlM can be constructed from a Message and a new Message can be created from an HrlM.

  • Hl7M

    An HL7 Record Layout Manager that permits fields within a record to be set or retrieved by name. Similar to other GRM objects, an Hl7M can be constructed from a Message and a new Message can be created from an Hl7M.

  • XmlM

    An XML Document Layout Manager that permits tags within a document to be set or retrieved by name. Similar to other GRM objects, an XmlM can be constructed from a Message and a new Message can be created from an XmlM.

  • EdifactM

    An Edifact Layout Manager that permits fields within a message to be set or retrieved by name. Similar to other GRM objects, an EdifactM can be constructed from a Message and a new Message can be created from an EdifactM.

  • X12M

    An X12 Layout Manager that permits fields within a transaction set to be set or retrieved by name. Similar to other GRM objects, an X12M can be constructed from a Message and a new Message can be created from an X12M.

As with a message, a GRM represents a reference to resources which are managed by the engine. A GRM which is created should always be destroyed at manually.

As with message instances, GRM references can be remembered and shared among code, for example, using static variables. The programmer must be aware that the life cycle of the underlying generalized record manager is not connected with Java reference counting.

For example, a TPS has called Destroy on a GRM. Subsequent references from another TPS which had a reference to the Java GRM object would raise exceptions.

The CloverEnv class provides standard methods which permit the API programmer to request new, empty GRM instances to be created by the system engine.

The Message class includes standard methods to create instances of GRM subclasses based on a message. Conversely the GRM class also provides a standard method to create a new message based on a GRM instance.