The Built-in web services contain methods to Create, Read, Update and Delete Record objects (a Record corresponds to one database in one of the dynamic database tables, - or on could say, that a Record is an instance of a configured Form).

The structure of Records is configued by the configurator (and naturally depends on the table). Therefore, the TOPICA Framework does not "know" the number of type of fields in a Record beforehand (at compile time). As a consequence, the Built-in web service methods that work on Records, used (name, value) collections as parameters to pass field values. So passing field values is not "type safe" - it is the responsility of the programmer to pass field names and values of types, that correspond to the configured forms. Some may find this inconvenient to work with.

Remember that TOPICA has information on names and types of fields in the dynamic table stored in the Data Dictionary. Therefore, it is possible to auto-generate CRUD (Create, Read Update, Delete) methods for each dynamic table.

These methods in the auto generated web services are "strongly typed", i.e. they work on data structures, that correspond to the data structure defined in the Data Dictionary. This is in contrast to the CRUD-operations working on records using the built-in web services services that work on (name, value) pairs, because they are generic.

The framework contains user interface to generate these service (as simple as clicking a button - no programming required). In theory these web services could be automatically regenerated each time the Data Dictionary is updated. This would ensure, that the web services always corresponded 100% with the current data structure. However, regenerating web services on each change (even minor changes that do not influence the data structure) could cause problems for any code written to consume these web services.

Conversely, modifying the data structure without regenerating the corresponding auto generated web service, may cause the web service to fail.

• A form X contains fields A and B, and Data Dictionary is generated / updated.

• The auto generated web service for table X is generated. The record structure used in the methods will contain fields A and B.

• A field C is added to the form, and Data Dictionary is updated - but the web service for table X is NOT regenerated.

• The web service for table X is still functioning - but it cannot read nor write the new field C.

• The field B is deleted from the form, and Data Dictionary is updated - but the web service for table X is NOT regenerated.

• The web service for table X will crash, because it still refers to the (now deleted) field B.

Note
It is the responsibility of the configurator and/or application developer to regenerate these webservices after a breaking change to the data structure - and update any consumers of these web services correspondingly!