The aim of this page is to describe Bonaparte′s system architecture in a nutshell. This means that this page will definitely not provide answers to all the questions you might have, but please feel free to contact us with any.

Bonaparte consists of several parts that interact and can be considered a client-server architecture. The following parts are the bare minimum for running a fully operational Bonaparte system; a server running

• Bonaparte Core
• Bonaparte GUI
• Bonaparte Documentation provider
• SQL database (RDBMS)

and a client machine with a suitable browser.

The core contains all algorithms for matching and data handling. This part communicates with the GUI—which also runs on the server (!). The GUI part builds the graphical user interface and communicates this data to the client′s browser. The core also communicates with the database for data retrieval. These components may reside on different machines. The setup is explained in Figure 1.

The left hand part (on the left of the dashed line) runs on an Apache Tomcat servlet server. An (optional) SSO controller may be configured to use existing authentication services. The right hand side is the user′s computer. Both communicate over http(s) using XML and JSON. All that is needed to run Bonaparte on the client is a webbrowser with ECMAScript (Javascript) enabled. There is absolutely no need for any installation or plugins of any kind. We support at least the following browser and operating system combinations for the client:

Operating System	Firefox	Chrome	Edge	Internet Explorer	Safari
Microsoft Windows	Yes	Yes	Yes	No	No
Apple Macos	Yes	Yes	--	--	Yes

In general we support the last vesion of the browsers. For Microsoft Edge, we support Edge from EdgeHTML 17 and up and the latest Blink based ones.

Bonaparte manages it's own advanced internal database (advanced datamodel running on a RDBMS). This database keeps track of all data modifications (who, what and when), and it keeps all historic records so that it can be restored to any previous point in time.

The "roll back" capability means that a user is able to select a historic version of the database—a view of the database at time t that filters out data created after that time—and work with that database in read only mode. The purpose of this is that (for legal reasons) it might be required to re-confirm old matches or investigate what data was exactly available at what time, e.g. for auditing purposes. This versioning is accomplished by keeping a full edit history of all data.

Bonaparte can easily be integrated into existing infrastructure via the interfaces it provides. For data "synchronisation" there are also web services available that accept profile and pedigree data in XML format. Imported profile data can be protected against modifications if desired, so that the one-way synchronised profiles are guaranteed to remain as they were when they were imported.

Concurrency is implemented through the use of private and public branches. A user can start editing an object by putting it in edit mode and work with this new object. For the rest of the world that object remains as it was before that editing took place. Only when the user chooses to publish his modifications they become visible to the other users as well.