In the post How to create a LifeTime Plugin, Hélio Dolores has shown how to install LifeTime SDK and create a LifeTime plugin using a template.
In this post, we will continue where Hélio’s left of, digging into the template, namely the APIs already available there. Then, we will take a look at other APIs that are now available with the OutSystems Platform 8.0.
Let’s start our tour with the APIs available in the template.
1) The Plugin API
This simple API consists of two actions to register and unregister your application as a LifeTime plugin. Registering an application as a plugin makes it part of LifeTime, under the “More” menu. There are two things you need to know here. First, you can only have one plugin per module, so be careful when re-using plugins. Second, only the module that registered the plugin can unregister it, which protects your plugin against others.
2) The Layout Block and Security Exceptions
Though we didn’t call it an API, the handy web block Layout_LifeTimeSDK is the default layout block for every screen that you create in the template. It makes your application look like LifeTime since it provides the LifeTime menu bar and placeholders for breadcrumbs, title, subtitle and even an application icon!
Also already available in the template in the sample flow is the Security Exception handler. What does this mean? Good question! It provides the same LifeTime login screen for your application! If any security error occurs (invalid permissions, no login), it will be handled the same way a LifeTime security error would be.
3) The LifeTime Monitoring API
Another simple API, it is just an entity that contains the data of end-user requests collected by LifeTime. With it, you can create cool plugins like Geo Performance! Keep in mind that requests data is only collected when Performance Monitor has monitoring enabled.
4) The LifeTime Metamodel API
Now the juicy stuff! Let me present to you the LifeTime Metamodel API!
This API allows you to access LifeTime information about environments, applications, modules, versions and deployments, and check for permissions for environments and applications. Pretty cool, huh?
As you can see, we made it minimal - only Get and List actions. I’m not going to explain to you every action’s nuances - that would spoil your fun - but I’ll just give you one example: the Application_Get. This action can return the information of an application across all environments of your infrastructure! Now imagine what Application_List can do!
An important part of this API is the security actions. In LifeTime, you can create roles that have permissions for environments and their applications, or you can define a permission for a user to a specific application. The API’s security actions let you check if a user has some permission for an environment or application. Consider, for example, the Security_CheckApplicationPermission.
This action verifies if a user has some permission level for a given application in an environment. It will always return the highest permission it finds for that user. Thus, with these actions, you can make your plugins as safe as LifeTime without having to make complicated queries!
Not present in the plugin template are the next APIs.
6) Client-side Request Info API
6) Asynchronous Logging
A frequent need in enterprise applications is to insert large amounts of data into database tables. This API allows you to do just that asynchronously and in bulk. Records are added to a message queue that is periodically dumped to the database by the Log Server. Learn more here.
So, what can we do with these APIs?
Now some food for thought. Here are some ideas we had while developing these APIs.
1) Change Management Reports: to document all production changes on a given period. With the Metamodel API, you can have access to all deployment information. With the Plugin API, you can make it part of LifeTime!
2) Factory Governance Dashboard: to understand your factory’s architecture and see applications dependencies. With the Metamodel API you can get each module’s public elements and reference elements to determine dependencies between them.
3) Custom monitoring & notifier: to raise alarms for ops when performance degrades below a given threshold. With the Monitoring API, you have access to request times and can deduce performance problems in your applications.
4) Custom performance dashboards: to manage application performance by teams. With the Monitoring API or with Client-side Request Info, you can separate requests from different teams and analyse their performance individually.
5) And much more!
Feel free to ask more information about any API.