How does Archibus work?

How does Archibus work?


Hello and welcome again to another blog by me, todays will be a relatively short blog, but I wanted to go over how Archibus technically works in a simple and easy to follow way.


A while ago I wrote a blog talking about the code languages that are utilised by Archibus to run, but never really went through how this all relates to each other, so this could be considered the long awaited follow up.


The start of this blog will be going over the components of the Archibus structure, and I imagine that this is fairly well known. At the core of the product sits the database, this is either a Microsoft SQL Server database or an Oracle database. From here the next main component is Web Central, which utilises the most common browsers to allow users to interact with their data in the database. Finally, there are the secondary input/output (I/O) devices, which are your Smart Client and mobile apps.


The core part of Archibus is the database, which is a collection of tables (much like a series of spreadsheets) linked together by shared fields within the tables. An easy example of this would be the space based tables for Buildings, Floors and Rooms.


At the highest level you have the Buildings table (bl) with it’s primary key of Building ID (bl_id), this then gets linked to the Floors table (fl) by a foreign key and a two-part primary key within the fl table that is made up of bl_id and Floor ID (fl_id). This of course gets even more complicated when you add the Rooms (rm) table and its three-part primary key made up of bl_id, fl_id and Room ID (rm_id                                                                                                                                

                                                                                                                                           Figure 1: Primary Key Example

There are many other linking keys between the other tables in the database, which is what allows for an assurance of data integrity, after all changes can’t be made to a record until the changes are matched in the other tables down the chain.

From the core database we now link to the Primary I/O of users, which is Web Central. This is connected to one another by something called a JDBC connection, which looks at the server address of the database and then connects to the database utilising the afm SQL users credentials.


Figure 2: Database server connection

In one of my previous blogs I went through how Web Central utilises Java, Javascript and XML to create an interface for the normal user, to go into further detail, the backend of the web pages will allow for Java to create arrays of data in a table layout so that the string of information can be pushed into a SQL string that the database understands, thus updating the database.

The two secondary I/O methods utilise the same JDBC connection that is designed for Web Central, but then have other links to the Web Central and database structure.


The Smart Client is in essence a tool that allows you to see the database structure, without having to have a knowledge in either SQL Server or Oracle database management systems, and this connects by a two-part process. The first connection is a utilisation of the Web Central JDBC connection, talked about above, and the second is a SOAP service that allows for data to be pushed and pulled in to the database from the Smart Client. These are a connection type that utilises specific java calls to push and pull data within the system.




                                                                                                                                Figure 3: Smart Client SOAP Services


The final I/O method for users is the mobile structure. Once again you link to the system through the Web Central address, which then utilises the JDBC connection to match to the database. However for the sake of data integrity, the mobile device has been designed to work with sync tables, which holds temporary data that requires a workflow rule to push the data from the sync tables, into the main tables themselves. I went though the way that workflow rules work in the last blog, so I won’t go into detail here, but in brief java is used to generate a series of arrays that collect data from I/O to the database and vice versa.



Figure 4: Example of Sync Tables


I hope that this blog has been informative, if a bit brief on details, and that you enjoyed reading it.

Until next time, have a lovely day.


For more information, call MASS on 0118 977 8560 or email us at


Written by Callum Doyle


Space Console improvements - Archibus Web Central V26.1 09/06/2021

In this Blog we give a brief overview of some of the improvements to the Space Console in the new version of Web Central 26.1.
read more view all blog posts