UX APIs

Calling it UX APIs might be the most ambiguous part of this. We never really figured out the naming, "New generation APIs", "Version 2 APIs", "WebAPIs", "UX APIs".

Anyway, how it works is - all UX/perceptive apps built on TRIRIGA make rest calls to TRIRIGA based on how we have them configured in the UX Designer components.These components allow you to query, create, modify and even delete records, and call state transitions and workflows.

For example, opening the workplace services perceptive app makes the following calls -

On selecting the currentUser request, we see this response -

There are other requests being made too, for whatever is needed for the app to function. The new implementation basically makes these calls without a front end and multiple such requests are stitched together to make a functioning API. Essentially, an alternate to the OSLC approach for integrations. The reason for an alternate approach was performance and documentation.

Performance

I worked on the performance analysis for OSLC vs UX APIs vs servlets for integrations for weeks. The conclusion was that, there were hundreds of validations performed for each OSLC request. This, although necessary most times, took a lot of valuable transaction time. The UX APIs did not do this. Any check that was done by the OSLC layer had to be manually configured in workflows when implementing the same in the new approach, which allowed us to pick and choose the necessary validtions. This meant the development effort was higher but helped us cut down the transaction cost by some percentage.

Documentation

These APIs weren't always fully functional. They had to be built in ways corresponding to the functionality. For example, a room booking process isn't just that. There's checking availability for rooms for the selected time slot, checking if the requested person has access to the listed rooms, hold room to make sure concurrent bookings are not made, proceed to book rooms. So, the APIs had to be split into microservices that does each of these operations because of limitations that we have with TRIRIGA.

We then stitch them together with an API Manager (like API Connect↗). And when it is exposed, it's just POST /reserve to make a booking. This helped us document the API with the latest openAPI standards.

The development did take a lot of effort though. A lot of workflows had to be redone just for these integrations. And breaking down the functionality into microservices was the most difficult part. For example, the reservation API had the following requests -

Each of them would have a request and a payload at times -

All of these would be performed one after the other by the API Manager.

We ended up building APIs for Service Requests, Worktasks, Assets, Location Portfolio, HR Portfolio and some miscellaneous standard services that were going to be used by kiosks and mobile devices.