Archibus REST APIs
We would like to develop a set of REST APIs that allow access to key Archibus data and workflow. This idea is meant to get feedback on which data and workflow elements are most important.
Internal topic on this is: https://serraview.atlassian.net/wiki/spaces/AD/pages/524156999/Platform+REST+APIs. It covers the following priority use cases that we'd like to validate.
Generic get records from a table. As an experienced Archibus system integrator, I would like to have a generic API that allows me access to database table records so that I can respond to customer use cases that are not covered by specific needs. I'd need to specify the table, the fields needed, and a restriction that's applicable to that table. An example is "get all fields in the lease table where the due date is in the next week". Another example is to stream documents into a document management system.
Service Requests managed in Archibus. As an FMer or a systems integrator for the FM customer, I want to allow employees to log service requests in an external system like ServiceNow, and for those requests to route to Archibus to be fulfilled, and I want status changes to be communicated back to the employee, so that I can efficiently utilize two systems together for different purposes.
HR Integration. As an FMer or systems integrator, I want to connect to external system, such as Workday, in order to get accurate and complete employee and organization information into Archibus, so that I can leverage that data for occupancy planning and asset management while maintaining an external system of record. A nightly feed from my HR system is fine. Also, I would like to get out of Archibus the most current employee location assignments, so that I can feel that information back to my HR system. Only seat assignments that have changed since the last time I ran the API should be brought over.
Primary FM tables. As a system integrator, I need to have access to key space data in my FM system so that the data can be used in external systems. Examples include:
Get building information in my portfolio to aid capital planning ESRI in higher ed: Get building information for ESRI/map consumption All buildings at once All active buildings Buildings restricted by site
Drawings. As a system integrator, I want to use an external system for wayfinding, service requests, reservations, and other employee-experience uses while keeping Archibus as the system of record for all floor plans, so that I may leverage all of that floor plan data for my employees.
Financials. As a system integrator, I want to get rent and cost transaction details from Archibus so that I can sync them to my financial system, and in that way I can use Archibus for lease-related costs while making sure all financial information is accurate and in one place.
Service Requests managed in an external system. As an FMer or systems integrator, I want to allow employees to log service requests in Archibus, but for some of those requests to transfer to an external system to be fulfilled, and I want status changes to be communicated back to the employee, so that I can use one system for all employee requests and another system to fulfill certain types of requests, such as move and project requests.
IT tickets go to an IT system Move tickets go to the system that box movers use to execute the move
Leases. As a user of Serraview for space-planning, I would like to see lease information related to the buildings and floors that I'm working with so that I can use that information in my planning and stacking efforts. Applicable information includes lease areas and end dates.

-
js.clisse@aremis.com commented
As discussed in the latest (technical) meeting, here are the elements to complete our requirements :
- In the backend, the process acts as a system user (it's a M2M communication). The "current" user is only a parameter.
- Avoid the need to have a separate Application Server for the API (a unique instance should be able to support a user login and a M2M connection at the same time)
- The services should always be stateless
- The API is versioned and stable (a version should remain the same and be stable even on new releases of WC)
- The usage of a specific path pattern (*/api/*) and a specific SpringFilter chain -
Thomas Fastenakel commented
A few comments on this
* service requests (both ways), FM tables, and drawings are the most relevant use cases on our (AREMIS) markets
* Interacting with DMS is also a good point, is probably worth a use case by itself
* 3 is achieved via connectors exchanging flat files/XML streams for years and works OK with most clients. OF course it might be more challenging with archibus.cloud
Hope this help(Edited by admin) -
AdminFred Kraus (Admin, Eptura) commented
From Jean-Sébastien Clisse:
About the technical aspect of API design, I think this document shows good practices:
https://www.octo.com/wp-content/uploads/2019/04/OCTO-Refcard_API_Design-1.pdf
(> see, for instance, « General concepts » or «URLs »)
These concepts seem to be used very widely. -
Thomas Fastenakel commented
Some best practices when designing REST APIs
-
AdminFred Kraus (Admin, Eptura) commented
What is the specific customer use case for getting lists of sites, buildings, floors, rooms? What fields? What filter criteria? Can you help us write this as a user story?
For workflows, what are the top-of-mind user stories?
For service requests, do you envision the story to be an employee uses an external system to create a service request, and then an FMer uses Archibus to manage that service request through approvals and execution? In that case, is the expectation that the system integrator is responsible for transforming the service request details and calling and Archibus API to post it into Archibus? Or that Archibus calls an API to get the service request from the external system?
-
AdminFred Kraus (Admin, Eptura) commented
From Aremis (Thomas Fastenakel)
- Provide a flexible authentication method implementing various protocols
o Login preauth
o Archibus User/password
o Token-based (OAuth2, OpenID Connect)
NB It should be as independent as possible from the Core API
- Cover various business oriented cases without going too low-level
o Get the list of sites, buildings, floor, employees, assets
o Trigger specific business workflows (on a higher level than workflow rules)
Create a new service request (with or without attached documents) / reservations
Retrieve my service requests / reservations
Update employee or asset location
Approve / Issue / Complete a request
- On the technical side,
o Make sure to be OpenAPI (Swagger) compatible
o REST (+ JSON )(Edited by admin)