Interfacing a Business System to Noah 4



This section provides the business system developer with:

  • detailed information on the Noah 4 architecture

  • a summary of the tasks needed to integrate a business system to Noah 4.

Noah 4 Architecture

The following figure shows a logical view of Noah 4, with the focus placed on the Noah Client side, which will be of particular interest to the business system developer.

                                                 Figure: Noah 4 logical view

The Noah 4 system can be divided into 6 logical groups:

1       Business API

2       Module API

3       NOAH 3 Module Server

4       NOAH 2 Module Server and wrapper

5       Noah 4 Client

6       Noah 4 Server

One of the objectives of Noah 4 is to convert as much as possible from COM to .NET components. However, some COM remains due to the requirements of backwards compatibility. It is also a requirement that the HIMSA development platform should be the latest Visual Studio version.

The Module API

The ModuleAPI is very like the Business API, with both servers implementing almost the same object model for handling the business logic; the difference lies in the methods implemented by each API. The way in which the Module API is embedded into a module and used by Noah 4 modules is the same as for a business system.

NOAH 3 Module Server

NOAH 3 has been provided with complete backwards compatibility. The NoahClientProxy.dll converts all COM traffic from the NOAH 3 Module Server.dll into .NET, which can then be interfaced to Noah client. The NoahClientProxy.dll has support for all NOAH 3 methods.

NOAH 2 Module Server and Wrapper

In the case of NOAH 2 modules the components have been copied from latest NOAH 3.

The blue processes are all copied from NOAH 3 and ensure that the legacy system is in place and working for all NOAH 2 modules. Do note that NOAH 2 modules do not work on 64-bit operating systems, as they use 16 bit components.

Noah Client

Noah Client will normally not be visible to the end user since it is implemented as a Windows service. Noah Client will be responsible for keeping track of registered modules on the workstation and regulating the number of modules that are simultaneously connected to Noah on the same workstation. Furthermore Noah Client will buffer the most used server data in order to reduce network traffic and make faster access to data for the business systems and modules. Noah Client also acts as a communication concentrator between business server/modules and the server i.e. all communication between processes running on the client PC and the server will pass through Noah Client (this is not the whole truth as business systems may access Noah data without going through Noah if they provide their own database interface).

Noah Server

Noah Server has a number of tasks to perform;

  • Database access

  • License evaluation

  • Globob maintenance

  • Event distribution to attached Noah Clients

It is important to notice that Noah Server acts for the attached Noah Clients in the same way as the Noah Clients act for any attached business system or module . Thus, Noah Server distributes events to attached Noah Clients. These events are broadcast to all attached Clients besides the Client originating the event.