Module Registration

In addition to the Module Deployment where all files required by the module are installed, it is also required that the installed module registers with Noah.
In order for any module to connect to Noah and or be launched by another module or business system, the module must register with Noah. This task is accomplished by using the ‘Himsa.Noah.Modules.Registration’ and ‘Himsa.Noah.Modules.RegistrationData’ classes.

The registration, if successful, is only required once after deployment. Please refer to The Registration Objects to see objects involved in the module registration.

Please consider the following when registering the module:

Does the available Noah framework have the correct version? If this is not the case, it might not make sense to register, or perhaps even deploy the module.
Which data types can the module show and/or create? It all needs to be included in the registration process so Noah will become aware of it.
Does the System Database, Globob.stg, need to be updated with a new manufacturer, new data types or etc.?
See Constant Definitions for information on how to update the System Database.
Ensure proper handling of a failed registration attempt, by catching all exceptions, and react correctly to them (aborting registration, if something went wrong etc.)

It is important when developing your module setup program that it follows standard Windows installation procedures.

The module registration is NOT optional.

The implementation of these standard procedures is a requirement for receiving Noah certification.

Module Registration Information

This section provides an overview of:

the module information that must be registered with Noah
the major classes used for registering module information
two methods that module developers can use to register their module

The Module offers a complete range of objects, which enables a new module to specify all its capabilities. The following table describes some of this registration information.

NOTE: A module registers information using constants defined in the System Database. For more details refer to Constant Definitions.

Information Type	Description
Manufacturer Code	A unique code assigned by HIMSA to each of its Licensees. Refer to Constant Definitions for details of this code.
Local Module Identifier	A unique code that must be assigned to each module by its Manufacturer. This number is used by Noah to distinguish between two or more modules from the same manufacturer. A module number must be between 0 and 65,535.
Module Category	Third party modules are divided into module categories, including fitting, measurement and other. A new module must identify the category to which it belongs. The Module Category allows limiting the number of concurrently running modules in Noah. Additionally the Module Category also allows for a logical grouping of available modules. Refer to Constant Definitions for more info.
DataType	Modules exchange data with Noah by adding and retrieving data through the Session list. Data added by one module may be visualized by another Manufacturer’s module. To make this possible, data is characterized by a DataType object, which holds information about the nature of the data and the format used to represent the data. These standards are described in the Noah data standards documents on HIMSA’s website (www.himsa.com).
IMC Protocol	Modules may exchange data directly with other modules through inter-module communication (IMC). HIMSA defines IMC protocols and assigns each protocol a unique protocol identifier. A module must inform Noah about the protocols and data formats supported using the Protocols collection, which is a collection of Protocol objects.