Maintaining Maintenance Classes for MOs

For a new MO, use the Eclipse plugin to create the skeletal class structure for a new maintenance object class.

For other services not linked to a MO, you will need to write a new maintenance subclass and create the annotation.

To develop an Entity Page Maintenance class, you need to create a hand-coded implementation class. This class must include an annotation providing the metadata that describes the maintenance. In addition, the business entities that "back" the maintenance must already have been created.

Let's take a look at a simple maintenance annotation example to illustrate its properties:

@EntityPageMaintenance ( 
      program = CIPTBTCP,
      service = CILTBTCP,
      entity = batchControl,
      copy = true,
      body = @DataElement (
          contents = {@DataField (DEFAULT_FOR_FLG)
                                , @RowField (name=foo, entity=batchControl)
                                , @ListField(name=BCP, owner=foo, property = parameters)
                           }
             ),
      lists = {@List (name = BCP, size = 50, copy = true,
                               program=CIPTBCPL, constantName="CI-CONST-CT-MAX-FIFTY-COLL",
                               body = @DataElement (contents = {@RowField (batchControlParameter)}))
              }
     )

First, we see that this tag is an EntityPageMaintenance, meaning it is a page maintenance for a single entity root object. Here it is a batch control, but account, person, premise, and so on, would also be examples. The idea here is that, by default, the maintenance framework tries to read, save, and delete the tree of data that starts with an instance of batch control. (Another kind of page maintenance is EntityListPageMaintenance, where you maintain a list of entities without a single root object. It has slightly different attributes than those discussed below.)

Next, we list some attributes of the top-level annotation. The required program attribute gives the equivalent Converted COBOL Program page module name that we are replacing.

The service is the name of the page service that we are implementing. This is required so the Framework knows that it should route requests for this service directly to this Java class.

The required entity property names the entity that this maintenance uses for its root. It should match an entity that is defined within the system, else the maintenance cannot work.

The copy attribute signals that certain copy fields should be defined in the service. Making the framework explicitly aware of these fields is preferable to dumb coding of these fields.

Now we hit the two major structural elements, the body and lists attributes.

The body attribute always resolves to a DataElement, which is simply a way to organize the collection of rows, loose fields, and lists that belong to a particular level in the service data structure. These contents are simply held in the contents array, which here starts with a simple datafield, DEFAULT_​FOR_​FLG. Note that you simply reference the field name, and the generator uses the field metadata to infer its type and size. The next element of the contents array in this example is RowField. This is essentially a way of naming a reference to the properties of a single entity/table, including its language fields, if appropriate. You need to specify its entity and name. Here I use a dummy name, foo.

Finally, we have a ListField, which consists of a reference to a list structure that is defined in a separate tag (lists). Here, we merely name the referenced list by name, provide the owner (which matches the name of the parent row), and the property (which tells the system how to access the list from the parent). We deduce that the getParameters() method on a batch control will yield the desired child list.