UX APIs

What were they?

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.

Opening the workplace services perceptive app, for example, makes a bunch of calls. There are calls made for currentUser, getting location details, and so on. 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, using the App's react code, to make a functioning feature. 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. The Reserve API had the 25+ individual APIs on TRIRIGA - the API manager then made it to 5 fully serving features.

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.